设计电商秒杀系统

【业务背景】

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

1.

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

2.

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

3.

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

4.

老板要求万无一失。

【技术背景】

1.

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

2.

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

3.

目前只有单机房。

【毕设要求】

1. 设计完整的架构，例如存储、负载均衡、缓存、高可用、可扩展等；

2. 大约 10 页以内的 PPT，每页 PPT 说明一项设计，包括架构设计和设计理由，无需详细解释备选方案。

【提示】

1.

分析考虑要全面，但并不意味着架构设计要面面俱到，如果分析后认为某些设计点可以不做，就在作业最后统一说明原因即可；

2.

如果没有思路，请对照模块 9 的 IM 案例；

3.

如果有的信息觉得不够全或者不够细，可以做出一定的假设，但不能天马行空，需要对照已有的业务背景和技术背景进行合理推断。

业设计：设计电商秒杀系统

一、分析

1. 秒杀活动的瞬间流量很高，需要用缓存和消息队列，降低后端压力。

2. 日活用户 100 万，在秒杀活动期间，至少会有 3~5 倍的用户参与，架构设计至少参照百万级别架构设计。

3. 老板要求万无一失，那么稳定持续的运行是需要高可用，目前只有一个机房，所以需要申请云资源做多 AZ 部署。

4. 团队已经落地微服务，而秒杀活动的流量很高，所以在原有的 spring Cloud 基础上，单独开一些服务，专门做秒杀，做到业务压力分散。

5. 创业型公司，技术人员不会太多，作为业务重点的秒杀活动，可用根据需求找 12 个人做后端，andorid3 个，ios3 个。

二、业务流图

用户的主要业务流程包括，下载 APP，然后注册/登录；打开首页，查看推荐商品和秒杀商品；抢购商品，抢购时支付前先查询库存，支付后库存自动减 1；最后系统记录用户的购物信息。

三、计算架构设计

1. 注册登录

TPS: 日活用户 100 万人，假定活动当天新增 10 倍用户，一共 1000 万用户，80%登录注册发生在 5 小时内，则 TPS=1000 万*0.8/5/3600=450

1. 热销商品

QPS:10 大类，每类 20 个商品，一共 200 个商品。当天一共 5 倍的人查看，每人查看 3 次，每次查看 5 个商品，且 80%的请求发生在 5 小时内，则 QPS=500 万*3*5*0.8/5/3600=340

1. 秒杀商品

QPS：1000 个充电宝，10 个 iphone，假定当天 5 倍人参与，共 500 万，每个商品每人点击请求 3 次，秒杀请求发生在 1 分钟内。则 TPS=500 万*2*3/60=50 万

1. 支付

TPS 热销商品：点击抢购后，进入支付界面，支付前查询商品剩余数量是否大于 1，支付后商品数量减 1，TPS 为 340。

TPS 秒杀商品：和上面逻辑一致，TPS 为 50 万。

四、存储架构设计

1. 注册登录

假定有 5 倍的用户进行登录注册，存储的用户注册和登录信息 500 万

1. 热销和秒杀商品库存

只有 200 条左右商品，但秒杀开始时，会有高并发库存查询，redis 单机 TPS 为 5~10 万，所以使用 redis cluster，在必要时可以拓展 redis 的读副本来降低压力。

1. 订单

预计登录用户有 50%的购买转化率，每人平均购买 2 件商品。则订单存储量为 500 万*0.5*2=500 万

五、负载均衡设计

初创公司，F5 价格过高，为满足峰值数百万的请求，使用多个 LVS 作为一级负载均衡。有了云之后可以使用 ELB 通过伸缩结构做到无状态业务类的自动拓展（前提是无状态）

六、缓存设计

1. App 缓存+web 容器缓存+分布式缓存

2. 使用 APP 缓存和 WEB 缓存将大量静态页面保存起来，秒杀时静态页面从 APP 或 Web 获取，减轻后端压力。

3. 秒杀开始后，为支持大量库存查询请求，使用 redis 保存库存，分布式缓存使用 redis，为应对大流量，redis 采用 redis cluster 方式部署。

七、高可用设计

为确保在秒杀开启后，大流量冲击下万无一失，确保高可用，除了自建机房，需要购买一定的异地云服务，将数据同步到云中，发生本地宕机情况下，自动切换到云端。同时将请求放入消息队列，以应对高频请求，降低服务端压力。

八、可扩展设计

百万级别的业务，公司可以抽出 20 个左右开展这次秒杀业务，后端 12 个人，根据三个火枪手原则，开 4 个微服务，以后有新的业务可用直接水平扩展。

九、小结

秒杀业务因为高流量高并发，对架构设计要求较高，本文采用了缓存和消息队列来应对。初创公司为降低开发成本，同时不影响原来的业务，在原来微服务架构基础上，直接开 4 个新的服务，完成秒杀业务。本文采用多级负载均衡架构应对高峰值场景，采用云端备份服务方式保证高可用。