前言

本文所设计的架构用于电商秒杀系统，那么我们假定电商系统已经是在线运营的状态，基本的用户登录注册、下单、支付、物流等系统为稳定运营状态。由于秒杀业务的特殊性，秒杀时峰值 qps 是日常 qps 峰值的 n 倍，日常系统未必可以支撑，瞬间的大量请求可能会造成系统崩溃，基于这样的一个前提和需求，我们设计了这次的秒杀架构。

词汇表

暂无

1. 业务背景

需求分析：

1. 秒杀系统的唯一诉求：支撑瞬间大量流量，同时商品不超卖，用户长时间卡顿。

2. 流量分析：假设日活 100 万用户的话，在大促优惠的刺激下，我们假设这 100 万用户都会参与秒杀，那么大促 qps=100W。

3. 商品不超卖：通过消息队列方式限流，可使用令牌桶模式，保障商品不会超卖。

4. 降级：只有 app 参与活动，那么认为微信小程序的请求在秒杀流量高峰时是可以降级的。

5. 降级：秒杀时认为用户基本处于已登录状态，除了秒杀相关商品详情页、下单、支付等，其他例如登录、注册、修改用户设置等均可降级。

6. 高可用：为保障秒杀系统高可用，系统应该有限流和快速扩容的方案，限流时可提示用户重试，如果系统流量触发了限流，可通过快速扩容满足用户下单需求。

2. 约束和限制

1. 用户流量商品不卡顿。

2. 用户下单支付不卡顿超过 3s。

3. 商品不能超卖。

4. 支付金额不能计算错误。

5. 优惠券计算不能错误。

6. 支付跳转延迟不超过 3s。

7. 要求 5 月 15 日完成部署上线。

8. 要求 5.20、5.30、6.10 号至少完成 3 次大促前压测。

3. 总体架构

3.1 架构分析

高可用：

• 基于消息队列设计防超卖。

• 基于限流与降级保障系统稳定性。

高性能：

• 负载均衡保障高 qps 处理性能。

• CDN 缓存 &APP 缓存保障提前预热商品信息。

• 运维平台提供快速扩容能力，保障系统整体处理性能。

可扩展：

• 由于只后续双十一，或者明年大促更大的量，基于限流平台、降级平台、运维平台等可提供稳定的大促保障方案。

• 压测平台可酌情考虑。

成本 &安全：

• 成本上来说，瞬间峰值当天过后，扩容的机器均可下线以节约成本。

• 安全上大促暂不涉及，认为日常的运营已经考虑到。

3.2 总体架构

• 由于原有架构已经是微服务架构，那么在原本已有的微服务架构上，强化负载均衡的能力，提高负载均衡的负载能力，可通过扩容集群等方式实现。

• 由于秒杀商品已知，CDN 缓存和 APP 缓存可通过提前预热的方式，降低系统查询请求量。

• 提供限流平台，保障系统不被瞬间峰值压垮，造成雪崩等故障。

• 提供降级平台，关键时刻降级非核心链路请求。

• 提供运维平台，提供快速扩容能力，保障服务 qps 请求超出时提供扩容能力，由于当前售卖品类比较少，认为秒杀时间不会太持久，限流足够保障系统稳定性，那么可以预估流量，不需要紧急扩容，提前部署好足够机器即可。

• 数据库前使用缓存和消息队列控流量，保障数据库稳定性。

• 提供监控平台，监控系统实施负载水位，及时响应。

4. 详细设计

4.1 核心功能

1）缓存：主动提前预热，保障大促时查询请求能直接打到缓存上。

2）降级限流：保障主链路稳定性。

3）消息队列：削峰填谷，保障系统流量稳定。

4.2 设计规范

1. 缓存系统需要提供提前主动预热能力。

2. 缓存设计避免击穿风险，需要提供默认值，异步从数据库中同步。

3. 核心链路数据库必须在前面设计消息队列或缓存，避免直接流量打到数据库。

5. 质量设计

• 可测试性：对核心链路进行压测演练，要求 5.20、5.30、6.05、6.10 完成 4 次大促前压测，并且后两次需要无故障一次性通过。

• 可维护性：限流平台、降级平台可实时调整配置。

• 可观测性：提供监控平台，实时监控压测时系统水位与大促时系统水位。

• 成本：暂不需要考虑

6. 演进规划

为以后双十一和明年大促保障，大促后进行以下升级：

• 开发升级运维平台提供扩容支持

• 开发升级压测平台提供压测能力