毕业项目 -618 秒杀系统

业务背景：

作为电商创业公司架构师，负责设计 618 大促秒杀系统设计，模式如下

1. 挑选各大电商畅销好评的商品进行销售，每个品类 20 个，目前做了 10 个品类

2. 本次 618 秒杀选择了 1000 个充电宝，10 台 iphone12 作为秒杀

3. 正常日活 100 万用户

4. 老板要求万无一失

技术背景：

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

2. 主要渠道是自由的 App 和微信小程序，为了促进用户转化 App 用户，只有下载 App 才能才加秒杀

3. 目前只有单机房

毕设要求：

设计完整的架构，例如存储、负载、缓存、高可用、可扩展，大约 10 页 PPT，每页说明一项设计和理由

业务基本场景：

1. 请求量远大于库存量，只有少部分人能秒杀成功

2. 消息放出会有大量黄牛、抢票软件更有甚者写脚本来获取，为保证公平某个时间段一人只能抢购一次

3. 只有注册 App 用户才可以参与，在倒计时的 5 秒内商品抢购页会被疯狂刷新

4. 抢购期间流量会大量涌入，此时网络较平时需要能够承载更多流量，且只会存在秒杀的时间段

5. 整体流程较简单就是下单、扣减库存，流程图如下👇

负载架构设计

采用 3 级负载均衡策略，由于是创业公司 F5/LVS 成本略高，这里只能放弃

第 1 级 DNS 进行机地理位置和机房级别的负载

第 2 级由 NGNIX 集群来分发，这里可以适当的进行 ip 限流，防止恶意攻击

第 3 级由服务网管集群来负载，网关可以鉴权是否 APP 用户以及控制每个 ID 的访问频率

最终到我们的服务器集群，所以负载架构设计如下👇

缓存架构设计

秒杀流程一般分为以下几个👇

• 商品信息展示

看过的商品信息可缓存在用户 APP

• 用户查询商品

前端：用户会不停的刷新页面，所以页面元素尽量都是是静态，减少动态元素，峰值靠 CDN 缓存来抗

后端：商品相关属性数据可提前预热到内存中，加快 RT 响应，分担数据库压力

• 用户购买商品创建订单

前端：提交订单后提交按钮置灰，防止重复提交

后端：库存 10 台 iphone12,至少会有 100 万的用户请求过来，此时需要将请求写入消息队列，数据库层 订阅消息来处理逻辑是否秒杀成功

• 系统扣减库存

需要用到分布式缓存 Redis 做，最后通过任务把 Redis 结果同步到 DB,防止超卖

• 系统更新订单信息

这里采用 5 级缓存架构👇

存储架构设计

1. 估算性能需求

【注册】 假设 100 万用户有 30 万都是通过小程序使用，那后续新增注册的数据就是 30 万；

【登录】由于现在 APP 基本上是注册即登录且 APP 会为已登录用户保持半个月的登录时效；假设活动前 有 20%的用户登录失效需要重新登录，那么登录的数据为 30+70*20%=42 万；

【商品】10 个品类，每个品类 20 个商品 也就是共 200 个商品数据；

【订单】假设 100 万会有 20%的用户日常购买这 200 个热销商品的 40%的商品，那么订单数据为 100w*20%*200*40%=1600w 的订单数据

【支付】一个订单对应一条支付记录也就是有 1600w 的支付数据

【秒杀】

只会有 1000+12 个幸运儿秒杀成功，对应订单和支付记录也只有 1012 条；

会有秒杀活动表、以及秒杀商品表这些记录可以忽略不计

1. 选择存储系统

存储选择 MySQL 主从切换，因为存储数据单机可满足，写性能也可满足、主库有问题需要自动切换

由于秒杀是读多写少的场景，本质就是争夺库存的扣减，会有大多数请求读取当前的库存数量，mysql 指定扛不住，这里借助 Redis 主从，从来抗大量读请求，真正的扣减库存主来做

1. 设计存储方案

提前将库存数量预热到 Redis 中，库存信息放入 Redis 缓存的时候分为多份放入不同 key 的缓存中，库存为 1000 的充电宝可以分割 5 份分别放入不同 key 的缓存中，这样将数据分散操作可以达到更高的读写性能。例如充电宝的商品 ID:10001,Redis 库存分割设置如下👇

高可用设计

前端就是

• 页面静态化

• 用户提交之后按钮置灰，禁止重复提交

后端

• ip 限流

• id 访问频率

• 消息队列：将请求放入队列，异步处理逻辑

• 缓存预热：库存提前加载到 Redis,由 Redis 扣减库存

• 内存预热：商品信息等热点数据，提前加载到内存中，提高访问性能，减少 db 操作

可扩展设计

扩容，最简单的处理方式，在预算允许的范围内，增加服务器数量

异地多活