收官：秒杀架构全景复盘

回到崩掉的那一晚

用重建后的系统重放开篇的事故：晚上八点，10 万请求涌入。CDN 扛下页面与静态资源，源站只见到下单请求；端上防抖与错峰把同一秒的洪峰摊成缓坡；网关按压测容量放行两万，超出的进排队页；风控拦下可疑脚本，黑名单设备直接出局；Redis 十个分桶原子预扣，五十个资格几毫秒内名花有主，售罄后本地缓存快速失败；二百个预扣成功的请求进 MQ，消费端按数据库的节奏匀速落库，幂等与唯一索引双重保险；未支付的十五分钟后延迟消息触发关单回补；活动结束对账恒等式分毫不差——同样的 10 万人，这次数据库的 CPU 最高只到了 20%。

漏斗全景

演进路线：不是一步到位

全套装齐要几十个组件，务实团队是三步走：第一版——Redis 预扣加幂等加 MQ 异步，解决超卖与数据库崩塌两个生死问题，其余从简；第二版——加上风控、分桶、关单回补与对账，覆盖真实对抗与数据闭环；第三版——降级预案、全链路压测、候补池、平台化对账，走向"优雅"。每一版都独立可用、独立验证，跳过第一版直接堆第三版，是秒杀架构最常见的事故来源——组件越多，没人真正理解的环节越多。

克制：不是每场秒杀都需要全套装

一个提醒压轴：如果你的秒杀峰值只有几千 QPS——Redis 单桶加一个限流加一个唯一索引就够，风控可以用规则引擎替代、分桶可以不做、影子压测可以省略。过度设计与设计不足同样是事故：十个人抢 5 件商品的活动，套上十万 QPS 的架构，复杂度本身就会制造故障。容量决定架构，架构服务于业务，这个顺序在任何场景都不能反。

系列合流

这条漏斗上没有一件新武器：限流与熔断的算法、缓存预热的姿势、MQ 削峰的幂等、注册网关的配置、分库分表的数据底盘——前面几个系列各自打磨的能力，在这里合成了同一件兵器。秒杀是这些知识最好的考场：单点都会，合起来才是系统。十五篇收官，从崩掉的三层系统到体面的有损服务，希望下次你的开抢三秒钟，安静得像什么都没发生。整个后端进阶系列到此告一段落，祝实战顺利。