毕业设计 - 设计电商秒杀系统

1.背景知识

1.1 业务背景

你作为一个电商创业公司的架构师，负责设计 6.18 大促秒杀系统的设计，你们的业务模式如下：

• 你们挑选选品各大电商平台上畅销和好评的商品进行销售，每个品类不超过 20 个商品，目前做了 10 个品类；

• 本次 6.18 秒杀选择了 1000 个充电宝，10 台 iPhone 12 作为秒杀商品；

• 正常的日活大约 100 万

• 老板要求万无一失

1.2 技术背景

• 技术团队以 Java 为主，已经落地了微服务架构；

• 主要渠道是自有的 App（包括 iOS 和 Android）和微信小程序，为了促进用户转化为 App 用户，只有下载 App 才能参加秒杀活动；

• 目前只有单机房

2.业务背景分析

• 秒杀业务流程图

秒杀业务流程图

• 参考材料：【手把手带你搭建秒杀系统-佘志东】

• 复杂度分析

• 高可用：在秒杀过程中，不能因为高并发查询导致数据库宕机或者数据不一致

• 高性能：在进行秒杀过程中，应该及时返回秒杀结果，不能因为高并发导致用户体验差；同时，秒杀成功的商品应该可以快速进行下单支付

• 设计思路

• 针对高并发流程，要提前预防限流、快速失败，不能让其直接打到后端服务器

• 针对高并发读和写的场景，需要采用 Redis 集群保证数据的一致性

• 秒杀系统与正常的电商业务系统，独立开发部署，避免秒杀场景对整体业务产生影响

• 性能分析

• 由于该 APP 平常日均活跃大约 100 万，假设在秒杀期间 100 万用户中 60%的用户会参与秒杀，即 60 万用户

• 60 万用户会在秒杀前 5 分钟，进入秒杀页面查询商品详情，并在秒杀开启时进行下单，则由此可以推算出查询商品详情的 QPS 大约为：2000/s

• 预计在秒杀开始后 10 秒内秒杀商品(1000 个充电宝+10 个 iPhone12)全部售罄，则可估算下单的 TPS：100/s

3.存储架构

秒杀存储架构

• 由于本次 6.18 秒杀选择了 1000 个充电宝，10 台 iPhone 12 作为秒杀商品；只会产生总订单量为 1010 个，所以采用 MySQL 主备架构进行存储即可，当主机出现宕机时，可以迅速切换为备机，防止服务不可用

• 在秒杀准备时，需要将秒杀商品详情信息和库存上架信息存储在 MySQL 数据库中；在秒杀活动开始前期，将商品详情以及库存信息缓存到 Redis 集群中；

• 根据上述分析，QPS 为 2000/s，采用 Redis 集群即可抗住读压力

• 依据 Redis 的单线程特性，可以通过内嵌 Lua 脚本判断并进行库存扣减

• 对象存储，用来存储商品图片

4.计算架构

4.1 计算架构之负载均衡

秒杀-计算架构之负载均衡

• 防刷单：由于在秒杀期间，存在机器刷单情况，可以在 Nginx 层进行控制，若某用户 ID 在近 30s 内，访问次数超过一定次数，则直接返回“亲，您未抢 XX，请再接再厉！”

• 设置服务实例个数：根据第二章节分析可知，真正促成下单的 TPS：100/s，假设秒杀服务的 TPS 为 100/s，则这里部署三个实例（做冗余，防止服务不可用）

• 路由 Hash：服务网关根据商品 ID（提前将上架商品进行一一编号）通过 Hash 的方式路由到指定的服务实例

4.2 计算架构之 5 级缓存

秒杀-计算架构之5级缓存

• 采用 5 级缓存架构，在秒杀活动开始前，可以根据通过预热的方式，将商品信息缓存在 App 上

• 将商品图片信息缓存到 CDN 上，可以就近拉取数据

• 分布式缓存用来存储商品库存信息以及商品详情

4.3 计算架构之接口高可用

• 根据上述的流程图和负载均衡架构，我们可以每一层做限流处理，防止突发流量将系统压垮

• 针对秒杀订单的处理过程，我们采用排队机制，来对突发流量做整形，具体流程如下:

排队机制

5.疑问

• 上针对秒杀系统做了存储架构和计算架构的分析，其中针对 QPS 和 TPS 的估算是否准确，需要老师能够指导一下