电商秒杀系统设计

1.业务背景

该系统的业务背景概括如下：

• 日活 100 万

• 20 个商品，10 个品类，共 200 个商品

• 秒杀商品有限，1000 个充电宝，10 台 iphone 12

• 团队以 java 为主，现有系统采用微服务架构

• 只有 app 才能秒杀

• 当前采用单机房设计

• 只限于秒杀系统设计

2.基本场景

该系统的基本业务场景如下：

基本场景包括注册、登录、浏览商品、下单、支付场景。其中：

• 注册 &登录场景

百万注册用户，每天活跃用户 40%，登录时读取用户信息是每天 40 万 QPS；

• 浏览商品

共 20 个秒杀商品，商品数量忽略不计；

每月活跃用户约 40%。秒杀活动前会有推广活动，活跃用户会有提升，以 60%计算，约有 60 万用户同时在线浏览商品，tps 数为 600K；

• 下单

订单数量，秒杀商品共 1010 个，那么订单总数也为 1010 个，要求在 1s 内完成处理，因此 tps 为 1010；

• 支付

支付一般在 5 分钟内完成。tps 约为 1010/300=4tps，可忽略不计。

3.重点场景分析

3.1.浏览秒杀商品

• 业务特征分析

典型读场景，由于订单下了后仅有少量修改，因此适合用缓存架构

• 架构分析

1）用户量过百万，应用用多级负载均衡架构；

2）请求量 60 万，应该用多级缓存架构，考虑用三级缓存架构，app 缓存+web 容器缓存+分布式缓存，不用 CDN，因为业务量没那么大；分布式缓存用 redis，支持持久化，可以避免丢失订单。

• 架构设计

登录状态保存在分布式缓存中，请求发送给任意服务器都可以，选择轮询或者随机算法

• 业务服务器数量估算

由于浏览秒杀商品的处理逻辑比较简单，主要是读缓存系统，因此假设单台业务服务器处理能力是 1000/s，则机器数量为 60 台，按照 20%的预留量，最终机器数量为 75 台。

3.2.下单

• 业务特征分析

典型写操作，不能用缓存，用负载均衡

• 架构分析

用户量 60 万，选用多级负载均衡架构。选择 LVS，支持 60 万+性能

• 架构设计

1）负载均衡算法选择

下单的时候依赖登录状态，登录状态一般都是保存在分布式缓存中，因此下单的时候，讲请求发送给任意服务器都可以，选择轮询或者随机算法

2）业务服务器数量估算

按照一个服务每秒处理 500 来估算，支持 1010 个订单处理，需要三台服务器。

4.存储架构设计

5.计算架构设计

5.1.负载均衡

5.2.多级缓存

6.高可用设计

• 业务特征分析

1）下单

商品数量有限，下单会在 1s 内下单

2）浏览商品

商品数量有限，100w 用户同时浏览 2 个秒杀商品

• 架构设计分析

1）下单

下单性能要求比较高，可以考虑对“非秒杀订单”限流，由于非秒杀订单也是收入来源，因此不能丢弃请求，采用漏桶算法。

2）浏览商品

存在缓存热点问题，使用“多缓存副本”。

7.可扩展设计

将商品服务和订单服务拆分出来，支持秒杀活动，其中商品服务支持商品、浏览记录查询，浏览等操作；订单服务支持下单，订单查询等服务。拆分后的微服务架构如下：

8.高可用架构设计

当前系统月活已经到达 100 万，还只是单机房设计，远远不能满足系统稳定运行要求；同时通过秒杀活动会拉新业务量会进一步增长。为保障业务未来一段时间平稳运行，需要将当单机房扩建为同城双中心，时间允许的情况下，跳过灾备方式，直接从单机房升级为双活架构，确保秒杀业务万无一失。