前言

词汇表

Redis Cluster: Redis 缓存服务器集群模式

Nginx: 高性能代理、Web 服务器

RocketMQ：分布式消息中间件

1. 业务背景

作为创业电商公司，迫切希望在 6.18 大促推出秒杀活动，一方面回馈老客户长期对本公司的支持，另一方面获取新的客户并增加客户转化和留存率，但是现有的电商系统难以应对秒杀带来的高并发流量，因此需要在现有的架构基础上进行秒杀系统设计和实现，以确保当天秒杀活动顺利进行，当前业务状况及秒杀活动相关需求如下：

1) 参与秒杀商品和数量：1000 个充电宝，10 台 iPhone12；

2) 当前日活 100 万；

2. 约束和限制

2.1 技术限制

1) 技术团队以 java 为主，且已落地了电商微服务架构；

2) 当前主要渠道有 App(包括 iOS 和 Android) 和微信小程序，但为了促进用户转化为 App 用户，只有下载 App 才能参加秒杀活动；

3) 当前系统只有但机房，当前也不会为了秒杀系统投入大量成本新增机房实现异地多活。

2.2 成本要求

1) 主要利用当前团队人力资源实现该秒杀系统，若有必要也可以适当增加少量人员；

2) 最大限度利用当前软硬件资源，可以酌情采用新技术以应对秒杀业务带来的技术挑战。

2.3 质量要求

1) 老板要求秒杀万无一失，即实现当天秒杀服务和现有服务，以及数据存储高可用和高性能；

2) 需要具备良好的可观测性，能实时监控大促当天计算服务、存储系统、服务器运行状况，并且对于用户业务请求以及相关异常日志进行完整清晰记录，支持全链路日志分析和故障诊断；

3) 需要对秒杀请求进行限流和排队，以避免影响其他正常的业务请求，必要时可进行限流、熔断或降级。

2.4 项目时间要求

1) 6.18 大促在际，必须要大促之前完成系统上线和业务数据缓存预热，线上秒杀活动预演，故障演练，以确保系统质量和用户体验。

3. 总体架构

3.1 架构分析

3.1.1 关键用户和系统行为

3.1.2 存储和计算性能估算

【查询商品】

存储充电宝和 iPhone 商品信息各一条，数据大小 1KB, 每个商品大概 3 张图片，每张大小 120KB，总共 2x3x120KB = 720KB

当前 100 万日活用户，假设有 20%的额用户参与秒杀，并且有大概 10 万新增用户参与秒杀，且 80%的用户集中在秒杀活动开始的前 10 秒钟查看商品，所以商品数据读取峰值 QPS：（100 万 x 20% + 10 万)/ 10 ≈ 3 万/s，

【发起秒杀】

秒杀开始后的 1 秒之内，所有参与秒杀的用户开始触发秒杀请求，但是最多只能有 1000+10 个秒杀请求可以下单并支付成功，因此采用 APP 端随机限流只允许 30%的流量通过，被限制客户需要在 2 分钟后才能再次发起秒杀请求。因此，秒杀峰值请求 TPS：(100 万 x 20% + 10 万) x 10% ≈ 3 万/s，秒杀时需要查询当前是否有库存以及秒杀活动是否已结束，因此 QPS：≈3 万/s。秒杀请求数量大约 3-5 万条, 每条大概 10KB，总共 5 万 x10KB ≈ 500MB，而秒杀成功产生的订单数据为 1010 条，秒杀请求数据具有有效期，有效期到后需要清除出。而订单数据需要持久化存放。

【系统处理秒杀请求】

收到秒杀请求后，秒杀服务需要完成以下主要任务：

• 检查账户状态

• 是否已参与该商品秒杀

• 是否还有库存

• 记录秒杀处理结果

• 请求订单服务创建订单

账户状态检查需要调用已有用户微服务，其峰值 QPS：≈3 万/s；

是否已参与该商品秒杀，需要查询客户秒杀记录，若已参与则放弃，QPS/TPS：≈3 万/s；

需要调用库存微服务是否还有库存，QPS: ≈3 万/s；

最多只有 1010 个订单被创建，其最大理论峰值 TPS: <1010/s, 每个订单大概 10KB，总共 1010 x 10 KB ≈ 10MB;

无论成功与否都需要将秒杀结果记录下来方便用户轮询，峰值 TPS: ≈3 万/s, 数据量有 3-5 万条, 每条大概 10KB，总共 5 万 x10KB ≈ 500MB

【轮询秒杀状态】

秒杀排队成功后，客户端 APP 需要按随机间隔（3-10s）多次轮询秒杀状态，若成功则获取订单发起支付，若失败则根据失败原因要么退出当前页面，要么重新发起秒杀请求。若所有参与秒杀的用户开始时总共发起了 3 万条秒杀请求，那么随机间隔时间的峰值 QPS：3 万 x 1/8 ≈ 4000/s.

【订单支付】

客户查到最终秒杀请求处理结果后，若成功则第一时间发起支付请求，因此支付请求峰值 TPS：1010/s，支付产生的流水为 1010 笔。

3.1.3 存储架构分析

1）商品信息需要提前从当前的 MySQL 数据库预热同步到分布式 Redis 缓存分片集群中，以应对 3 万/s 的 QPS；

2）商品图片缓存到 Nginx 代理服务中；

3）秒杀结果存放到 Redis 集群中，并设置有效期限，到期后自动删除，共计需要 500MB 内存存放该数据，应对 3 万/s QPS。需要 4 个 Redis 分片分担读写请求, 每片 4G，预留多一些空间用以应对分片故障。

4）复用以后的商品服务模块的 MySQL 数据库存放商品和库存信息；

5）服务用已有的文件存储模块存放秒杀商品图片；

6）APP 端可缓存商品信息和客户秒杀信息，避免重复查询给服务器增加负担。

3.1.3 计算架构分析

1）需要上述 Redis 集群缓存商品、秒杀结果和库存等信息；

2）需要 App 端进行随机限流，允许部分请求达到服务端，以确保服务端处理性能和可用性；

3）两台 Nginx 代理服务器采用主备切换架构应对 TPS/QPS：3 万/s 请求，确保高可用和高性能；

4）三台网关服务器，并采用轮询策略进行负载均衡 ；

5）为避免秒杀请求激增拖垮现有的服务，如订单、用户、商品和库存服务，需要引入排队机制，由独立的排队服务进行库存判断和秒杀请求排队，由 MQ 进行请求排队，由独立的秒杀业务服务以恒定的速度进行请求处理，如账户请求、下单、库存扣减等。由于请求排队逻辑简单，依赖于缓存读取和 MQ 吞吐量，因此可估算单台排队服务器处理能力为 1000/s，每台服务器处理秒杀结果查询能力也为 1000/s, 秒杀请求处理服务器能力为 200/s （考虑订单、用户和库存等服务耗时）但是只要在 10s 内处理完成即可，因此，需要 30 台用于请求排队和处理结果查询，15 台用于部署秒杀请求处理服务，总共需要 45 台服务器，可额外增加 5 台应对故障等意外状况。

3.2 总体架构

3.2.1 存储架构设计

订单、支付流水、商品和图片数据复用已有的数据库，但需要缓存商品、库存和秒杀请求处理结果信息，以应对高并发的秒杀请求。

3.2.2 负载均衡架构设计

3.2.3 缓存架构设计

• Nginx 用于缓存商品图片，应对秒杀开始前商品详情查询峰值；

• Redis 用于缓存商品详情、库存和秒杀状态；

• APP 端缓存商品详情。

3.2.3 高可用架构设计

由于秒杀请求处理服务需要进行账户状态查验、检查库存、扣减库存、发起订单创建请求，以及超时订单处理和库存回滚等耗时较长的业务处理，因此需要利用 APP 随即限流，并且对秒杀请求进行排队和库存缓存，由独立的多线程秒杀服务按特定的速率异步处理排队请求，避免秒杀激增的流量对已有的电商微服务造成拥塞，甚至拖垮服务，影响其它业务正常进行。

4. 详细设计

4.1 核心功能

4.1.1 秒杀异步处理流程

4.2 关键设计

1）引入消息队列，异步秒杀请求处理，进行流量削峰避免秒杀请求引起现有的商品、订单、支付服务性能下降，甚至发生服务不可用的情况；

2）Redis 采用分片集群，秒杀请求 ID hash 均匀分布在各分片中，应对高并发的读写请求；

3）秒杀排队和处理服务独立开发部署，排队服务主要用于秒杀商品库存和活动有效期检查，以及将请求放入消息队列中。

4）各秒杀处理服务需要各自实现令牌桶算法，令牌生成频率可通过配置中心实时调整，秒杀处理服务按照特定频率获取和处理秒杀请求，避免对现有的其他相关服务照成影响。

4.3 设计规范

1）反向代理服务器使用 Nginx，并缓存静态资源

2）消息队列使用 RocketMQ 集群，消息队列需要设置固定产固定

3）缓存服务器集群部署模式为 Redis Cluster，规划 4 各分片

3）采用 Spring Gateway 做服务网关

4）用 Spring Boot 开发秒杀微服务

5）配置和注册中心采用 Spring Cloud Alibaba Nacos

6）服务熔断降级使用 Spring Cloud Alibaba Sentinel

5. 质量设计

5.1 采用 Jaeger 作为微服务分布式调用链监控系统，可高效、便捷、准确的进行故障排查和分析。

5.2 日志中心采用 ELK，将日志集中存放，方便故障处理和后期对流量请求进行分析，改善服务质量和重构秒杀服务架构。

5.3 Nginx 监控系统采用 ngxtop。

5.4 RocketMQ 监控采用官方 rocketmq-console。

5.5 微服务监控告警系统采用 Prometheus。

6. 演进规划

6.1 秒杀系统一期

1）维持现有电商平台单机房，在已建设的机房中增加微服务所需服务器资源，部署秒杀系统相关微服务、存储服务和基础设施，复用现有的电商微服务；

2）由于秒杀服务要求质量较高需要集成全链路链路追踪和监控报警系统，需要能快速定位问题，诊断故障原因，及时修复故障，也需要关键时刻能对服务进行熔断，避免服务故障级联影响已有的电商微服务；

3）采用日志中心收集日志信息，方便对故障排查和服务质量分析，为秒杀服务升级优化改造提供支撑指标数据；

4）采用配置中心，集中管理配置数据，以便上线后可以根据市场变化快速调整相关生产配置，如调整秒杀处理服务获取消息队列秒杀请求的频率；

5）集成服务发现模块，可实现微服务上线和下线运维管理，节约高效的利用资源。

6.2 秒杀系统二期

1）当日活量激增，并且随着秒杀活动内容的丰富，参与用户越来越多，秒杀活动用户 TPS/QPS 大幅增加，将会逐步将微服务迁移上云，采用云原生架构方案以应对秒杀服务这种需要弹性缩容的计算服务；

2）采用云缓存和云存储等高效、稳定、经济的云厂商服务，更加合理高效利用资源，并且其配套的运维管理平台可帮助团队高效运维；

3）网络负载均衡层面也会采用云厂商负载均衡服务，高性能、高稳定性；

4）采用 CDN 实现网络边缘静态资源缓存；

5）采用异地双活架构方，实现服务高可用的同时确保用户究竟接入，提高服务性能和增强用户体验；

6）建设大数据平台，实现实时大数据分析和离线大数据分析，用以支撑电商平台营销策略制定，帮助公司调整市场战略部署，同时为电商平台服务改善提供数据层面的帮助。