1.业务背景

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

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

2. 本次 6.18 秒杀选择了 1000 个充电宝，10 台 iPhone 12 作为秒杀商品；

3. 正常的日活大约 100 万用户；

4. 老板要求万无一失。

2.技术背景

1. 技术团队以 Java 为主，已经落地了微服务架构；

2. 主要渠道是自有的 App（包括 iOS 和 Android）和微信小程序，为了促进用户转化为 App 用户，只有下载 App 才能参加秒杀活动；

3. 目前只有单机房。

3.设计分析

1. spu 的数量当前为 200 个以内，秒杀活动为 2 个 spu，分别为充电宝和 iPhone 12。这种情况下，秒杀的场景和普通购物的场景，也做好分离。在即使秒杀场景导致服务不可用的时候，也不会影响，主站服务的稳定，用户购买的持续性。

2. 普通的日活为 100 万用户。但是给的业务背景，并没有提到一个很重要的事情是，市场和营销部门有没有投放广告，以及宣传。我们可保守估计，秒杀的用户为这 100 万日活的用户。

3. 购物流程相对比较成熟，核心交付页面也为详情，结算，支付为核心的功能性页面。

4. 下文，会根据计算，存储，高可用等几个方面进行详细的架构设计与说明。

4.流程简化设计

5.存储架构设计

5.1 性能分析

【注册/登陆】

日活百万，我们可以假设，1 成为新注册用户，9 成为已注册登陆用户(并没有过多的说明，新老占比，可做简单假设)。在其中有 4 成人员想要参加秒杀活动，读取用户信息 40 万 QPS。

【交易】

实际购物能产生的订单关系数据不会很多，因为秒杀商品的库存有限，不超买的情况下，最多也就 1010 笔订单及相关记录。无需做过多的设计与说明。

5.2 存储架构设计

1. 关系型数据库

mysql 主备即可

tip: 1.压力主要在前面的流量进入，写入数据异步消峰即可。这也是比较常规的做法

2.非关系型数据库

Redis Cluster

6.计算架构设计

6.1 计算性能估算

【注册】

估算因为秒杀活动及信息传播，有 1 成的增量用户来注册，

【登陆】

百万用户，活跃为 4 成，登陆的时间为秒杀前的半小时，登陆 tps 均值：40W/1800 = 222

【下单】

总共库存为 1010，我们认为 5 秒可以秒杀完，下单的 tps： 1010/5 = 202

【落地页/详情页访问】

40W 的用户，几乎都会在开始的时候，进行页面访问，想要快速购买，然后抢夺库存。所以访问的 QPS 为 40W

6.2 计算架构之负载均衡

简要说明:

1. 其实限流对于整个计算架构的作用很重要，可以让整个服务不崩。满足老板的业务期望。

2. 大部分的页面流量，主要也是靠 cdn 为主。能静态的页面全部静态话，然后放到新的节点服务，毕竟纯静态也没，并无部署压力。也可以直接把页面放到 cdn 中，静态资源也放到 cdn 中。所以，真正到主站的流量，在限流的基础中，是可控的。

6.3 计算架构之缓存架构

简要说明:

1. cdn 和 app 缓存，在整个缓存架构中，其实相当的重要。上述已经做好了对应的说明。

2. 接口中，库存扣减的逻辑是一个重要的点，常规做法，也都是 mysql 的库存逻辑，放入 redis 当中，原子扣减，防止超卖。

3. 
   

7.其他设计

1. 秒杀场景下，几乎所有的业务会在一分钟内开始并结束，无需针对这个特殊场景本身做过多的多活逻辑。

2. 本身是微服务的拆分逻辑，要做好隔离，比如购物车，订单等核心功能服务，做单独的 k8s 集群节点，和电商官网本身做好隔离，这样已保证不同场景的业务稳定，这也是，微服务架构本身的一个好处。