秒杀系统架构

一、业务基本场景

1、系统首页展示秒杀活动，非秒杀时间段秒杀按钮灰显，用户即使不注册登录也是可以浏览商品列表、商品详情的；

2、在微信小程序上也能看到秒杀活动介绍，但是提示不能参与秒杀，仅能通过商城 App 才能参加活动，浏览秒杀详情可以提示下载 APP；

3、秒杀开始前某个时间到秒杀开始，页面访问量很大，但是都仅能浏览；秒杀开始到秒杀库存清 0，页面访问量最大，后面访问量逐步降低；

4、此次秒杀限量限价不限时，尽可能的为商城引流；而秒杀开始前，商城需要有一系列的活动预热；用户必须先注册登录才可以参与秒杀；

5、秒杀流程越简单越好，但是要安全，先抢单且购买数量只能是一个不可以修改，送货地址和付款方式都使用用户默认设置，没有默认也可以不填，允许等订单提交后修改；

6、每个用户要确保只能秒杀一件商品，只有第一个提交的订单发送给网站的订单子系统；

7、秒杀一般是定时上架，且不能出现“超卖”的问题；

8、最后最重要的一点：秒杀活动只是网站营销的一个附加活动，确保不能影响商城正常的电商购物场景，必须确保商城正常服务高可用 ；

二、存储架构设计

1、存储性能估算

【注册登录】

日活大约 100 万用户，假设实际用户是 500 万，由于秒杀活动引流日活用户，假设增长日活提升 50%，预估有 150 万用户登录，需要存储 150 万用户的登录数据；

【商品信息】

电商平台目前只有 10 个品类，每个品类不超过 20 个商品，需要存储的商品列表是 10*20 = 200 条，每一个商品存储商品详情信息，需要维护 200 条关系数据库；

秒杀当天用户会浏览秒杀商品和其他商品，假设每个用户查看商品列表 8 次，其中集中在秒杀前 1 小时是 5 次，则查看商品信息的 QPS 是 150W*5/60*60 = 1084；查看商品详情请求次数是 150W*8=1200W；

【秒杀】

秒杀商品是 1000 个充电宝、10 台 iPhone 12，秒杀有效订单就是 1010；

【订单】

秒杀活动只是一个电商系统的营销活动，活动当天也或多或少有些促销活动，假设 150W 登录，并且有 30%用户当天平均有 1 条订单且集中在秒杀的 1 小时内，则生成订单的 TPS = 150w*30%/60/60 = 125；要存储的订单数据是 45W 条记录，当天用户平均查询订单 2 次，90W 条请求；

2、存储架构设计

2.1、数据库存储

【存储数据】

1、存储 150 万用户的登录数据；

2、维护 200 条商品信息关系数据库；

3、存储的订单数据是 45W 条记录

2.2、Redis 缓存

【缓存数据】

1、查看商品详情请求次数是 150W*8=1200W；

2、存储的订单数据是 45W 条记录；

三、计算架构设计

1、计算性能预估

【注册登录】

活动当日预估有 150 万用户登录，假设新增注册用户 10W，假设经过活动预热，登录注册的时间集中在秒杀前 2 小时，则注册登录 TPS = 150W/60/60/2= 208;

【商品信息】

秒杀当天用户会浏览秒杀商品和其他商品，假设每个用户查看商品列表 8 次，则查看商品信息的请求量是 1200W；其中集中在秒杀前 1 小时是 5 次，则查看商品信息的 QPS 是 150W*5/60*60 = 2083；

【秒杀】

由于秒杀是限量，假设商品在 10S 内秒杀完成，150 万的登录用户 30%参与秒杀， 10S 每个用户平均请求 5 次，则秒杀请求 TPS = 150 W*30% *5/10 = 22.5W；

【订单】

秒杀商品是 1000 个充电宝、10 台 iPhone 12，秒杀有效订单就是 1010，假设这些订单都是在 5S 内生成，则生成秒杀订单 TPS = 1010/5 = 202；

秒杀活动只是一个电商系统的营销活动，活动当天也或多或少有些促销活动，假设 45W 用户当天平均有 1 条订单且集中在秒杀的 1 小时内，则生成订单的 TPS = 45W/60/60 = 125；

要存储的订单数据是 45W 条记录，当天用户平均查询订单 2 次，查询订单请求量是 90W；假设查询时间集中在秒杀后 2 小时，查询订单 TPS = 45W/60/60/2 = 63；

2、计算架构之负载均衡

【业务特性分析】

秒杀请求 TPS =45 W *5/10 = 22.5W，因此需要采用多级负载均衡架构，覆盖 DNS->F5->Nginx->网关的多级负载均衡；

【架构设计】

秒杀请求依赖登录状态，登录状态一般都是保存在分布式缓存中的，因此发送秒杀请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法。

说明：秒杀请求 22.5W 的 TPS 后面高可用会考虑排队限流方案，此处实际服务集群不会处理这么高的 TPS ，因为秒杀活动是暂时的。

3、计算架构之缓存

【业务特性分析】

查看商品信息的请求量是 1200W ，查询订单请求量是 90W，用多级负载均衡架构；

【架构设计】

游客都可以直接查看商品信息，因此将请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法。

四、高可用架构设计

1、秒杀请求排队架构

【业务特性分析】

秒杀请求 TPS = 22.5W ，收到请求后并不同步处理，而是将请求放入队列，系统根据能力异步处理；

【架构设计】

使用排队服务器，技术本质是：请求缓存+ 同步改异步+ 请求端轮询 。

2、主备级联复制

【业务特性分析】

电商平台库存和商品是最核心的业务，且秒杀不能出现“超卖”的问题，因此库存和商品必须保持强一致性，MySQL、Redis 支持主备级联复制这种模式；

按照目前日活百万量级，人工切换即可，虽然 RTO 比较大；因为自动切换实现复杂，需要实现数据复制、状态检测、故障切换、数据冲突处理等。

五、可扩展架构设计

1、微服务拆分

【微服务拆分】

电商创业公司，直接参考业界实现，目前已经落地了微服务架构；

【微服务基础设施】

产品日活已达百万用户，且技术团队以 Java 为主，选择 Spring Cloud 作为微服务基础框架是非常合适的选择；