电商秒杀系统

【业务背景】

你作为一个电商创业公司的架构师，负责设计 6.18 大促秒杀系统的设计，你们的业务模式如下：1. 你们挑选选品各大电商平台上畅销和好评的商品进行销售，每个品类不超过 20 个商品，目前做了 10 个品类；2. 本次 6.18 秒杀选择了 1000 个充电宝，10 台 iPhone 12 作为秒杀商品；3. 正常的日活大约 100 万用户；4. 老板要求万无一失。

【技术背景】1. 技术团队以 Java 为主，已经落地了微服务架构；2. 主要渠道是自有的 App（包括 iOS 和 Android）和微信小程序，为了促进用户转化为 App 用户，只有下载 App 才能参加秒杀活动；3. 目前只有单机房。

【毕设要求】1. 设计完整的架构，例如存储、负载均衡、缓存、高可用、可扩展等；2. 大约 10 页以内的 PPT，每页 PPT 说明一项设计，包括架构设计和设计理由，无需详细解释备选方案。

【提示】1. 分析考虑要全面，但并不意味着架构设计要面面俱到，如果分析后认为某些设计点可以不做，就在作业最后统一说明原因即可；2. 如果没有思路，请对照模块 9 的 IM 案例；3. 如果有的信息觉得不够全或者不够细，可以做出一定的假设，但不能天马行空，需要对照已有的业务背景和技术背景进行合理推断。

分析：

10 个品类 × 20 个商品 = 200 促销销售商品数量

1000 个充电宝 + 10 台 Iphone 整点秒杀

1       存储性能需求计算

1.1       用户行为模型：

日活 100 万用户，假设有 20%用户参与整点秒杀活动，平均每人参与 5 次秒杀

1.2       分析和计算过程示例

1.2.1    假设用户总数是 500 万，则用户数据存储量是 500 万

1.2.2    日活 100 万，每次用户上线都需要访问用户数据一次，秒杀用户数据读取次数：100 * 1 * 5 = 500 万

1.2.3    日活 100 万，假设 20%的用户参与秒杀活动，假设 6 时至 24 时是秒杀流量集中时段，共 18 小时，每人平均参与 5 次秒杀，每次刷新 10 次页面，集中在秒杀的 1 分钟时段内，QPS = 1000000 *20% *5 * 10 / 18 / 60 = 9260

1.3       存储架构图

2       负载均衡

2.1       业务特性分析

2.2       现有业务的冲击

秒杀是营销活动中的一种，如果和其他营销活动应用部署在同一服务器上，肯定会对现有的其他活动造成冲击，极端情况下可能导致整个电商系统服务宕机

2.3       直接下订单

下单页面是一个正常的 URL 地址，需要控制在秒杀开始前，不能下订单，只能浏览对应活动商品的信息。简单来说，需要 Disable 订单按钮

2.4       页面流量突增

秒杀活动开始前后，会有很多用户请求对应商品页面，会造成后台服务器的流量突增，同时对应的网络带宽增加，需要控制商品页面的流量不会对后台服务器、DB、Redis 等组件造成过大的压力

3       缓存架构模式

秒杀系统的瓶颈主要体现在下订单、扣减库存流程中。在这些流程中主要用到 OLTP 的数据库，类似 MySQL、SQLServer、Oracle。由于数据库底层采用 B+ 树的储存结构，对应我们随机写入与读取的效率，相对较低。如果我们把部分业务逻辑迁移到内存缓存或者 Redis 中，会极大的提高并发效率.

按照秒杀业务的模式，读多写少，日活数量，以及业务背景的分析，采用四级缓存架构如下：

4       服务端高可用

采用消息队列缓存请求：既然服务层知道库存只有 100 台手机，那完全没有必要把 100W 个请求都传递到数据库啊，那么可以先把这些请求都写到消息队列缓存一下，数据库层订阅消息减库存，减库存成功的请求返回秒杀成功，失败的返回秒杀结束。

数据库层是最脆弱的一层，一般在应用设计时在上游就需要把请求拦截掉，数据库层只承担“能力范围内”的访问请求。所以，上面通过在服务层引入队列和缓存，让最底层的数据库高枕无忧。

5       异地多活架构

6      总结

        核心思想：层层过滤

       尽量将请求拦截在上游，降低下游的压力

       充分利用缓存与消息队列，提高请求处理速度以及削峰填谷的作用