设计思路：

1.分析秒杀业务需求与公司现有技术架构

2.结合架构训练营课程体系完善大纲，提出各章节设计问题

3.设计架构，总结与梳理学习中的问题

4.完成设计初版

5.调查市面已有秒杀系统设计，审核初版内容

6.修改完善，提交作业

需求分析

1.背景分析

公司技术背景：电商创业公司，百万规模架构，Java 微服务，自有 App（iOS 和 Android），微信小程序用户规模：日活 100 万用户秒杀产品：6.18 当天秒杀 1000 个充电宝，10 台 iPhone 12业务背景：每个品类不超过 20 个商品，目前做了 10 个品类

2.业务分析

• 万无一失：避免超卖，保持高可用；

• 业务目标：转化为 App 用户；

• 秒杀规则：下载 App 才能秒杀。

主要问题

秒杀设计主要解决以下问题：

• 在公司已有架构基础上，设计秒杀架构；

• 设计秒杀多活高可用架构，保证秒杀业务顺利运行；

• 对业务假设给出负载均衡架构设计、高性能架构设计、缓存架构设计、存储架构设计，满足秒杀业务特点；

• 从电商业务模块拆分，给出秒杀架构需要重点关注的模块；

• 秒杀防止超卖设计；

• 秒杀其他要关注的点，防止“羊毛党”刷单等，从架构设计上给出对应的解决方案。

秒杀架构设计

1.业务架构

电商架构

在秒杀架构设计中，主要涉及到以下业务：

秒杀相关业务

按照重要性从高到低分析如下：

1. 商品：加载秒杀商品页面，秒杀入口；

2. 订单：在秒杀时间能够顺利提交订单；

3. 结算：完成秒杀订单；

4. 支付：在规定时间内完成支付，否则订单内商品可以继续进行秒杀；

5. 风控：防止刷单。

2.存储架构

2.1 秒杀存储性能估算

【订单】

百万日活用户，假设秒杀活动有 10%人参与，秒杀 10 万 QPS。

【商品】

需要获取 10 个品类的商品信息，假设每个品类的商品查看的人数类似，每个品类商品 1 万 QPS。

【支付与结算】

秒杀活动总计 1000 个充电宝，10 台 iPhone 12。实际结算 2K QPS（考虑秒杀活动同时还有其他正常结算）。

2.2 存储架构设计

秒杀存储架构

• MySQL 存储：100 万用户数据，10 万登录请求，20 个品类商品数据，秒杀订单数据；

• Redis 存储：10 万库存读写请求。

3.高性能架构

3.1 秒杀计算性能估算

【订单】

百万日活用户，假设秒杀活动有 10%人参与。

提交订单，大多数用户会集中在秒杀前 1、2 秒开始提交。

假设 2 秒内有 80% 参与秒杀用户成功提交，10 万 * 80% / 2 = 4 万 QPS。

【商品】

秒杀商品前，用户会提前进入秒杀画面，不会等到秒杀最后一秒，高性能需求可以忽略。

【支付与结算】

支付结算仅限于秒杀成功后的订单，并且有一段时间可以进行支付操作，2K QPS。

3.2 秒杀计算架构负载均衡

TPS+QPS大约4万

引入消息队列作为缓冲：实现秒杀销峰。根据团队 Java 背景，选择 RocketMQ。

3.3 秒杀计算架构缓存架构

• 商品信息、库存信息在秒杀开始前进行预热，加载到分布式缓存 Redis；

• 缓存预热方式推荐：灰度发布/预发布触发系统生成缓存。

4. 可扩展架构

4.1 微服务拆分

微服务拆分

秒杀活动主要涉及商品服务、交易服务、支付服务。

微服务拆分时，根据团队实际情况合理运用“三个火枪手”原则。

4.2 微服务基础设施

考虑到技术团队 Java 背景推荐使用 Spring 微服务基础设施：

• Spring Cloud Eureka

• Spring Cloud Ribbon

• Spring Cloud Feign

• Spring Cloud Hystrix

• Spring Cloud Config

• Spring Cloud Zuul 等

具体选择时，结

合团队实际技术架构酌情选择。

5. 高可用架构

同城双中心多活

根据秒杀业务的实际情况，这里采用业务定制型高可用架构设计。

5.1 业务分类

• 访问量：商品>订单>支付

• 核心场景：订单>支付>商品

• 收入来源：支付>订单>商品

5.2 数据分类

• 库存数据唯一、强一致、不可丢失

• 订单数据唯一、强一致、不可丢失

• 商品信息唯一、可恢复

5.3 数据同步

• 读取与扣减需要通过事务完成，避免超卖。推荐用 Redis + lua 实现事务。利用 Redis Cluster 特性保证高可用与数据同步；

• 订单提交后，通过数据同步机制实现数据同步；

• 订单业务部署在同城双中心，实现服务高可用。

5.4 异常处理

出现异常切换时，

• 订单信息可能出现不同步，给出合理地提示，待服务恢复后可正确查看。人工干预给出适当补偿。

• 支付环节出现异常，比如积分与消费券扣除但没有支付成功。人工修正并给出适当补偿。

6. 其他

• 风控系统检测异常刷单，并进行策略处理；

• App 客户端对秒杀页面进行合理设计，避免出现重复提交请求；

• 用户认证合理设计 token 机制，避免非 App 客户端脚本刷单，影响正常业务。