业务背景

1. 正常的日活大约 100 万用户，按照 20%的月活比例，注册用户约为 500 万，是个百万量级用户规模的系统；

2. 每个品类不超过 20 个商品，目前做了 10 个品类，商品总数量只有千级。

性能估算

登录

假设用户集中 12:00~13:00，19:00-22:00 时间段内浏览 app，那么日常登录时读取用户信息的 qps 为 100 万×80% ÷(4×3600)≈56/s。秒杀活动吸引了比平时多 50%的用户进行登录，达到 150 万的日活，其中 80%约 120 万的用户参与了秒杀活动。如果 120 万用户在 1 秒内参与秒杀，qps 将达到 120 万/s。

商品浏览

秒杀前一分钟，用户会不停刷新商品页面，假设每个人至少刷新 10 次，那么 qps 约为 120 万×10÷60=40 万/s。

秒杀

秒杀过程需要对库存进行锁定，假设 120 万用户在 1 秒内参与秒杀，tps 为 120 万×10÷60=40 万/s。

下单支付

秒杀成功才会进行下单支付，本次秒杀的商品只有 1000 多个，考虑一定余量，订单接口只要满足 1500/s 的 tps 即可，支付一般是 10 分钟内完成，tps 只有 2.5/s，要求不高可忽略。

存储架构设计

MySQL

秒杀活动对容量与并发量要求都不高，保留原有系统的存储架构即可，无需调整。使用主从架构并结合自动化切换的 MHA 方案来保证高可用。

Redis

主要存放的数据：

(1)用户登录凭证（需要支持百万用户，假设一个凭证约为 500 个字节，200 万用户约占用 2G 左右的内存）；

(2)可用库存（支持 tps 1500/s 的库存扣减）。

总体来说，对容量要求不高，要支持 120 万/s 的 tps，因此选用主从方案，通过读写分离实现高并发，并使用 sentinel 方案保证高可用。

计算架构设计

负载均衡

秒杀峰值能达到 100 万的量级，因此使用 4 级负载均衡。

缓存架构

秒杀活动一般是提前上架，而且不会有太多变化，因此可以通过预热，使用客户端以及 CDN 提前缓存商品信息，而这部分缓存可以承载 90%的流量。

接口高可用

限流

1. app 端限流：用户点击秒杀按钮后进行置灰。

2. 接入端限流：限制同一 IP 的请求频率，随机抛弃无状态请求，如浏览请求。

排队

收到秒杀请求后，不同步处理，而是将请求放入队列，系统根据能力异步处理。

排队模块：

负责接收用户的抢购请求，将请求以先入先出的方式保存下来。每一个参加秒杀活动的商品保存一个队列，队列的大小可以根据参与秒杀的商品数量（或加点余量）自行定义。

调度模块：

负责排队模块到服务模块的动态调度，不断检查服务模块，一旦处理能力有空闲，就从排队队列头上把用户访问请求调入服务模块。

服务模块：

是负责调用真正业务处理服务，并返回处理结果，并调用排队模块的接口回写业务处理结果。

可扩展

独立出一个秒杀服务，串联核心服务的接口，实现秒杀逻辑，如果秒杀活动的需求及业务形态发生变化，也不会影响到电商的核心业务。此外，秒杀服务可以根据活动的大小进行灵活伸缩，并且秒杀服务内部已经实现限流与排队逻辑，并不会对核心服务进行冲击，可以很好地做到资源合理与故障隔离。

同城