【业务背景】

• 电商商城，10 个类目，约 200 个在售商品。

• 日活用户 100 万。

【业务分析】

6.18 当天上线两个秒杀商品：

• 1000 个充电宝

• 10 台 iPhone

秒杀只能在 APP 上进行

【性能估算】

秒杀涉及的主要操作流程有：

用户登录、浏览秒杀活动页、浏览秒杀商品、下单秒杀商品、支付订单、查看订单

假设：

在活动预热期，100w 的日活用户都看到了秒杀活动，80%的用户对秒杀商品感兴趣。最后其中 50%的用户在活动当日进入秒杀页参与秒杀。则参与活动的用户数约 100w X 0.8 X 0.5 = 40w 人

1. 用户登录

• 商城用户成功登录后，获得长有效期的 token。用户通常不会在一天内频繁登录。

• 秒杀活动会提前开始预热宣传。新用户注册高峰在秒杀活动开始之前。评估认为，当前商城系统能够支持日活 100w 的用户登录。

• 用户登录流程，不在秒杀子系统的设计范围内，由当前商城系统承担。

2. 浏览秒杀活动页

在活动当天，活动开始前用户会在活动页和商品页之前来回切换，且用户会在活动开始前 5 分钟内涌入活动页。假设 90%的活动页查询，命中多级缓存，实际请求到服务器的查询：

测算高峰期的 QPS = 40w X 0.1 / ( 5 X 60) = 133

3. 浏览秒杀商品

在秒杀活动开始前，秒杀商品页的访问频率和活动页基本持平，但是在秒杀活动开始前 1 分钟到秒杀活动开始后 3 分钟，所有积极参与活动的用户会频繁刷新商品页，等待秒杀开始，直到商品售罄。哪怕商品售罄，用户也会尝试刷新页面，等待捡漏。

活动开始前，可以通过缓存的方式，减少对服务器的请求。请求量可以按活动页的请求量算 133

活动开始后，商品页需要向服务器询问是否还有剩余商品，无法完全使用缓存减少请求量。

假设，秒杀活动开始后，所有进入商品页的用户，没有刷到下单按钮的用户继续点击刷新页面，APP 对频繁刷新进行拦截，每 10 秒放开用户请求一次剩余库存。

剩余库存 QPS = 40w / 10 = 4w

4. 下单秒杀商品

由于活动开始后，APP 对频繁刷新进行了拦截。秒杀开始前 2 秒刷到商品的用户是有机会进入下单队列的。用户输入验证码大概需要 1-5 秒。验证码可以用客户端校验，减少与服务端的通讯量。

验证码通过验证后，会再次查询库存量，假设 1/5 的用户会进入下单页，并在 2 秒内提交订单

下单 TPS = 1.6W / 5 * 2 = 1600

5. 支付订单、查看订单

在秒杀时段，秒杀系统产生 1010 个支付订单。其中 90%的用户会在 1 分钟内完成付款。

TPS = 1010 * 0.9 / 60 = 15

【架构设计】

架构设计需要保证秒杀活动的顺利进行，系统需要支持高性能（高并发）。日活用户 100w，用户量上千万。但由于商城对库存、余额的强一致性要求。依然继续维持单机房方案。

1. 存储设计

商品、订单信息在主系统架构内已有相关服务。秒杀服务只需要存储商品、库存、下单的排队队列状态的缓存信息。

• 使用 Redis 存储库存、秒杀商品信息

• 缓存的主要请求压力来自库存查询。秒杀商品只有两个。使用一主一从的方案即可保证查询

2. 负载均衡

• 秒杀商品类目已决定，且只能再 APP 上进行，可以通过缓存+多级负载均衡减少对商品页的请求。

• 用户下单前，使用验证码缓冲秒杀开始的请求量

• 使用消息队列缓存下单请求，通过排队的方式消峰订单创建和库存扣除。

1. 服务器数量估算

按照一个服务每秒处理 500 来估算。剩余库存查询需要 80 台服务器，订单排队系统需要 4 台服务器支撑，共 84 台服务器。

【系统架构图】