[架构实战营] 模块 9 设计

秒杀系统设计

1.性能估算

• 注册：

• 运营宣传，假设新增 100W 用户秒杀，假设有 80W 用户在秒杀当天 2 个小时前注册。

• 注册接口：800000/10000=80TPS

• 存储数据：新增 100W 条用户数据

• 登录：

• 秒杀前 1 个小时，180W 用户登录

• 登录接口: 180W/3600=500QPS

• 秒杀：

• 秒杀开始，180W 用户同时点击秒杀按钮

• 商品查询：180WQPS

• 秒杀接口: 180WQPS

• 下单：

• 真正到下单环节的请求很少

2. 存储设计

• Mysql:主从复制+读写分离,存储用户+商品+订单数据

• 200W 用户信息

• Redis Cluster

• 200W 登录请求

3. 高性能设计

• 4 级缓存

• APP+CDN+web 容器缓存静态资源

• Redis 缓存某个商品剩余的数量(下单一次，-1)

• Redis 缓存商品信息

• 

4.高可用设计

• 限流：前端 js 文件(秒杀开始时，通过定时任务更新，包含随机数，秒杀地址，权限认证信息)，通过随机数，过滤 9/10 请求

• APP 设定：按钮只能点一次，点击之后跳转到等待页面或者秒杀结束页面

• 服务内部缓存某个商品在当前服务节点下单的数量(超过数量的请求全部放弃)，5 个服务节点

• 1000 个充电宝：每个服务节点，允许扣库存的请求为 1000/5*1.1=220

• 10 台 iPhone:每个服务节点，允许扣库存请求为 10/5+1=3

• 负载均衡：通过前端页面控制，180WQPS，只有 18W 访问服务端

• Nginx 集群，轮询分配

• 不做异地多活

• 

5. 可拓展

• 因为是无状态服务，性能不够机器来凑