电商秒杀系统架构设计

一、需求背景

1.1 业务背景

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

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

2.本次 6.18 秒杀选择了 1000 个充电宝，10 台 iPhone12 作为秒杀商品；

3.正常的日活大约 100 万用户；

4.老板要求万无一失。

1.2 技术背景

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

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

3.目前只有单机房。

二、总体设计思路

2.1 场景分析

采用 5W 分析法，发现创业公司的电商平台主要是吸引用户下载手机 APP 来参与商品秒杀活动。正常电商平台的日活大约 100 万用户，加上平台秒杀活动推广，结合日活用户可估算秒杀时间峰值用户达到约 500 万。

用户参与商品秒杀活动，关键行为是商品浏览、商品秒杀。

三、存储架构设计

3.1 存储性能预估

3.1.1 商品浏览

已知秒杀活动开始前 60 秒，500 万用户已经登录并开始选择秒杀产品，用户通过持续刷新界面，估算 60 秒内用户会重复刷新 5 次，保证界面秒杀时间倒数正常，由于商品详情页面是静态数据，可以采用 CDN 和静态资源缓存，减少 90%的访问量。

QPS 计算如下：500W*5/60*0.1= 41000/S

商品浏览和刷新无需保存数据，只要保存充电宝和 Iphone2 种商品数据，存储量非常小。

3.1.2 商品秒杀

商品秒杀核心在于层层过滤，逐渐递减瞬时访问压力，减少最终对数据库的冲击，秒杀请求量较大，防止请求直接到达后端服务器，采用请求端限流，比如生成随机数、按钮变灰等手段，由于参与秒杀的商品为 1010 个，我们可以挡掉 90%请求，对用户来说无感

TPS 计算如下：500W * 0.1 = 50W/S

商品秒杀需要存储 1010 个商品订单数据，存储量较小，但是要求性能较高

3.2 存储方案

3.2.1 商品浏览

参与秒杀商品的品种只有 2 类，数据量非常小，可以用原先系统的数据库进行存储，但是对于 500W 用户浏览商品，需要提前将 2 类的商品信息进行缓存在 redis sentinel。

3.2.2 商品秒杀

由于参与商品的总共数量只有 1010 个，只会生成 1010 个订单数据、库存数据，采用 Mysql 主备进行存储。

四、计算架构设计

4.1 业务场景计算性能估算

已知上面计算出商品浏览和商品秒杀的性能

商品浏览 QPS：500W*5/60*0.1= 41000/S

商品秒杀 TPS：500W * 0.1 = 50W/S

4.2 高性能计算架构设计

4.2.1 商品浏览

4.2.1.1 业务特性分析

商品浏览是一个典型的读操作，请求量较大，负载均衡架构和缓存架构都需要。

4.2.1.2 架构分析

由于用户量过 500 万，采用多级负载均衡架构，覆盖 DNS->F5->Nginx->网关的多级负载均衡。

4.2.1.3 架构设计

负载均衡算法选择：所有用户都可以直接看评论，因此将请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法。

业务服务器数量估算：业务服务器数量估算假设 CDN 能够承载 90%的用户流量，那么剩下 10%的商品浏览请求进入系统，则请求 QPS 为 41K/s* 10%=4.1K/s，由于读取微博的处理逻辑比较简单，主要是读缓存系统，因此假设单台业务服务器处理能力是 1000/s，则机器数量为 40 台，按照 20%的预留量，最终机器数量为 50 台。

4.2.1.4 高可用计算架构设计

3.2.2 商品秒杀

3.2.2.1 业务特性分析

商品秒杀是一个典型的写操作，因此不能用缓存，可以用负载均衡。

3.2.2.2 架构分析

由于用户量百万，采用多级负载均衡架构，覆盖 DNS->F5->Nginx->网关的多级负载均衡。

3.2.2.3 架构设计

负载均衡算法选择：由于商品秒杀是依赖用户登录信息，所有商品秒杀的时候可以任意发给服务器处理，这里可采用“轮询”或者“随机”算法

业务服务器数量估算：商品秒杀的 TPS 为 50W/s，由于应用服务器采用微服务架构，目前基本都是基于 TomcatWeb 容器，Linux 的 Tomcat 允许每个进程可支持 1000 个线程数，要完成 50W/S 的 TPS，需要 500 台服务器，加上一定预留量，600 台服务器差不多。

3.2.2.4 高可用计算架构设计

五、其他架构设计

5.1 可扩展架构设计

电商秒杀业务场景是比较独立的业务，为不影响原系统功能，需单独拆封独立秒杀服务。

5.2 高可用架构设计

由于商品秒杀是特殊的独立业务，可以采用业务定制型异地多活，同城双中心即可。