业务背景

你作为一个电商创业公司的架构师，负责设计6.18大促秒杀系统的设计，你们的业务模式如下:

业务基本场景

商品详情 -> 商品结算 -> 发货

秒杀场景和普通购买商品，在流程上确定相同的。不考虑使用预先报名的形式。

存储架构设计

存储性能估算

【商品详情页】

2条商品详细信息

【商品结算】

订单数量只有1010条。

【发货】

发货只有商品数量的个数，1010个发货单数据，忽略不计。

存储架构设计

日活为100w的系统，商品数量和交易单量都较大，都使用了分库分表，并不会因为这里是秒杀场景单独设计存储架构。商品使用了商品ID作为分区key，订单使用orderId+用户id来作为分库key

MySQL

MySQL存储订单，商品，优惠券，和正常商品设计相同，不需要另外设计。

Redis

秒杀活动开始前，将商品，库存存储到redis中，所以这里使用平常使用的redis cluster即可。不使用主从是因为，当后期秒杀这类的运营活动增多，主从模式不利于后期扩展。并且当前日活已经100w，数据缓存数据量较大，所以选择redis cluster。

计算架构设计

计算性能估算

假设：秒杀参加的用户是日活的一倍

【商品详情页】

2个商品详细信息

假设200w用户参加秒杀活动，并且假设50%用户会请求详情页3次，刷新页面看数据

200w*50% + 200*50%*3 = 400w

假设活动前1分钟和活动持续30秒，详情页访问TPS = 400w/90s = 4.5w/s

【商品结算】

商品结算既是抢购的按钮，假设这200w用户都会去请求计算价格，获取优惠后的明细。并且估算30%的用户会多请求3次。

200w*70% + 200w*30%*3 = 320w

假设活动前1分钟和活动持续30秒，详情页访问TPS = 320w/90s = 3.5w/s

真正扣减资源和最终计算，只会处理这1010个商品，所以这里忽略不计。

【发货】

忽略不计

负载均衡

如果考虑到非秒杀的其他商品下单，会选择在Nginx前，使用LVS做一层负载均衡。

计算缓存架构

其它架构设计

可扩展架构

当前百万日活，目前已经是采用的微服务模式。针对秒杀场景的扩展架构，需要将请求接入层，价格计算层单独分模块。也可以使用流程编排，组合普通下单请求和秒杀请求。

微服务使用流量染色，或者dubbo这类的RPC框架，使用group区分隔离秒杀和常规下单请求。

灾备

因为目前是单机房，所以此次设计先不设计多机房。但是MySQL，Redis存储中间件，需要数据持久化，单机房使用从服务器实时备份数据。

高可用架构

使用限流策略，防止大量请求通过后台服务打到数据库。针对秒杀场景，超过一定比例的请求后，后续的请求可以直接降级，返回用户秒杀失败的结果。

针对秒杀场景，秒杀成功可以直接返回用户秒杀成功，将快照数据放到MQ中，下游服务防止因为瞬时大量请求影响正常场景的请求。