业务背景

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

1. 你们挑选选品各大电商平台上畅销和好评的商品进行销售，每个品类不超过 20 个商品，目前做了 10 个品类;

2. 本次 6.18 秒杀选择了 1000 个充电宝，10 台 iPhone12 作为秒杀商品; 3. 正常的日活大约 100 万用户;

3. 老板要求万无一失。

业务基本场景

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

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

存储架构设计

存储性能估算

【商品详情页】

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 中，下游服务防止因为瞬时大量请求影响正常场景的请求。