如何设计"秒杀"架构支撑百万级并发请求？

大家好，我是二哥呀。从牛哥那里看到一篇非常不错的内容，也是面试场景题中的热门话题 — 秒杀架构如何扛住百万流量。

其实搭建秒杀架构不难，难的是：当瞬时流量远超日常 10-100 倍，如何在快速响应与系统稳定之间找到平衡？

下面就跟随牛哥一起看下 "一个又快又稳的秒杀架构，是怎么搭出来的”。

先拆需求，别上来就谈技术

面试时被问到秒杀架构，面试官第一个想知道的就是：你能不能把模糊的高并发拆解成可落地的具体指标？

其实拆解并不难，我们分成两个维度切入 — 从用户视角拆业务，从技术视角定指标。

1. 从用户视角拆业务

从用户点击 “立即抢购” 到收到成功短信，整个过程能拆成 6 个关键环节：

以上每个环节环环相扣：资格没通过，就不用查库存；库存不够，就不用创建订单。只有把流程拆细了，才能知道哪里该加拦截、哪里该做异步。

2. 从技术视角定指标

聊完用户视角，再来看看技术视角。就像医生看病要测体温，系统设计也得有健康指标：

**2.1 并发能力指标
**

双 11 级别的秒杀，峰值 QPS 得扛住 100 万，核心 TPS 至少得 5 万，不然点击就卡顿。

**2.2 稳定性指标
**

用户点抢购后，99% 的请求得在 200ms 内有回应。而且秒杀这种核心场景，故障恢复时间RTO必须 ≤ 5分钟，毕竟不能让用户干等半小时吧？

**2.3 数据一致性指标
**

库存得 100% 准确，超卖 1 件都可能引发大量投诉。支付和订单状态也得同步快，延迟不能超 10 秒。

**2.4 安全指标
**

防刷量得拦住 99% 以上的脚本，不然黄牛 10 秒就抢光 5000 件库存。黑名单用户必须 100% 拦住，绝对不能让他们再参与。

以上四个指标为秒杀类系统搭建了技术层面的健康衡量标准，后续设计也要以这些量化指标为基准。

架构搭建：秒杀系统的四层骨架

需求明确后，就可以搭架构了。接入层、流量削峰层、业务逻辑层、数据层这四层，每层各司其职，缺一不可。

1. 接入层：先把垃圾流量拦在门外

用户的请求第一个到的就是接入层，这里要是没拦住无效流量，后面的数据库、业务服务很快就会垮。

那该怎么选接入层的技术方案？

通常选用「CDN + APISIX 网关」组合。因为CDN能扛静态资源流量，APISIX 比 Nginx 更灵活，适合秒杀这种需要频繁调整规则的场景。

下面就来拆解这个组合：

**1.1 CDN 加速
**

**首先是静态资源全量加速，**商品图、活动文案、倒计时动画这些静态内容，全扔到阿里云CDN。在北京访问，就从北京的 CDN 节点拿数据，在上海访问，就从上海的 CDN 节点拿数据，就近响应。

其次是设计地域路由，华北用户优先走华北网关、华东用户走华东网关，避免跨地域传输带来的延迟损耗。

除此，还要注意 CDN 缓存的时效性：秒杀开始前 1 小时，先提前将商品详情页等静态页面 “预热” 到全国 CDN 节点，确保活动开启时用户能瞬间加载；活动结束后，立即给页面设置缓存过期，避免用户后续访问时看到旧的库存信息。

**
**

**1.2 APISIX 精细化限流
**

用 APISIX 的令牌桶插件，可根据不同维度精准控制流量，避免 “一刀切” 式限流影响正常用户体验。

比如单 IP 每秒最多发 5 个请求，单用户 1 分钟最多点 10 次，没登录的直接拦住。

2. 流量削峰层：把"流量尖峰"压平

秒杀流量就像海啸，前 10 秒可能集中迸发 80% 的请求，直接打给业务系统，数据库肯定扛不住。

这一层的作用就是「缓冲 + 排队」，把 "10 秒 100 万请求" 变成 "10 分钟 100 万请求"，让系统慢慢处理。

主要通过以下三个手段实现：

2.1 消息队列缓冲：流量的第一道减压阀

用户下单后的请求先丢进 RocketMQ，业务服务按自己的能力慢慢消费。

这里为什么选Rocke...

真诚点赞诚不我欺