5.3 大促与极端流量实战复盘：把峰值压力变成系统能力

5.3 大促与极端流量实战复盘：把峰值压力变成系统能力

容量规划和故障推演解决了"平时怎么配、出了事怎么应对"，但有一种流量形态是平时遇不到、却最能检验系统成色的——大促和极端峰值。双 11、618、新品发布、营销活动带来的流量，可能在几小时内冲到平时的 10 倍甚至 50 倍。这种流量不是"平时的放大版"，它有自己的特征和陷阱。这一节把我经历过的大促保障经验整理出来，讲清极端流量下该做什么、不该做什么。

我参与过多次大促保障，最深刻的一次是某电商 AI 客服的大促。日常 5 万 QPS，大促峰值冲到 80 万，峰值倍数 16 倍。前一年他们按"平时容量 × 峰值倍数"准备了 80 万的容量，结果大促开场 3 分钟系统就崩了——不是因为容量不够，而是连接预热、缓存失效、重试风暴这些"非容量因素"导致的。这一年我们做了系统性的大促专项治理，平稳扛过了峰值。两者的差距不在算力，在大促专项的工程准备。

大促流量和平时流量的本质差异

理解大促，先要理解它的流量特征和平时完全不同。

峰值倍数极高是第一特征。日常的峰值倍数通常 3 到 5 倍，大促可能到 10 到 20 倍甚至更高。这意味着你不能按峰值常备容量（成本不可承受），必须有"平时精简、大促弹起"的能力——要么能快速扩容，要么能激进降级。

时效性集中是第二特征。大促峰值往往集中在极短的窗口（几小时甚至几十分钟），但这个窗口的"扛不住"代价是全年的口碑和收入。平时慢一点用户能容忍，大促时一个 429 就是流失的订单。所以大促对 SLO 的要求是"零中断"，比平时严格得多。

降级容忍度反而低是第三个反直觉的特征。平时过载可以降级到小模型、缓存兜底，用户感知不强；大促时用户期望最高，任何降级（哪怕是合理降级）都可能被放大成"AI 变笨了"的投诉。所以大促的降级策略要更精细——宁可限流也不要降级质量，因为限流是"等一下"，降级是"变差了"，前者用户能理解，后者会归咎于产品。

大促前的专项准备清单

大促不是"等流量来了再应对"，而是提前数周开始专项准备。我把准备清单分成几个阶段。

容量预热是基础。提前按预期峰值的 1.2 到 1.5 倍准备容量，并完成扩容和压测。不要等大促当天才扩容——扩容本身（拉镜像、预热模型、建连接）要时间，现场扩容往往来不及。连接预热容易被忽视但极关键：网关到推理的连接池、推理节点之间的内部连接，都要在大促前预建好。我见过大促开场瞬间，几万条新连接同时发起 TLS 握手，把网关 CPU 打满导致雪崩——根因就是没预热连接。

缓存预热是第二个重点。语义缓存、KV Cache、各类配置缓存，都要在大促前预热。语义缓存从空开始的话，大促前几分钟全是未命中的请求，全部打到推理，形成"冷启动洪峰"。提前用历史热门 query 把缓存填满，能让大促开场就有可观的命中率，消化大量流量。

降级链路演练是第三个重点。大促时大概率会触发降级，但降级链路如果平时不演练，真用到时往往切不过去——小模型的 prompt 格式没对齐、缓存的响应过期了、回退逻辑有 bug。大促前必须做一次全链路的降级演练，主动注入过载，验证每一条降级路径都能生效。我在每个大促保障项目里都坚持做这个演练，每次都能发现几个"以为能用其实不能用"的降级路径。

监控和告警加固是第四个重点。大促期间要加密监控频率、降低告警阈值（宁可多告警也别漏报）、确保值班链路（电话、IM）畅通。还要准备"大促专用看板"——只盯最关键的几个指标（TTFT、错误率、错误预算消耗），比日常看板更聚焦，让值班在大促高压下能快速判断。

大促进行中的实时应对

大促开始后，值班团队进入战时状态。这个阶段的应对要快、要准、要有章法。

实时盯盘是基础。大促看板的几个关键指标要全程盯：TTFT 是否在 SLO 内、错误率是否上升、错误预算消耗速率、缓存命中率、推理队列长度。任何一个指标异常，都可能是一场事故的前兆。

分级响应要有预案。绿灯（指标正常）按兵不动；黄灯（指标接近阈值）开始准备应急措施，比如提前把备用容量拉起来；红灯（指标超限）立即执行预案——可能是限流、可能是降级、可能是切流。关键是预案要提前定好，红灯时直接执行，而不是现场讨论。

最常见的应急动作是限流。当流量超过系统承载能力时，主动限流是保护系统不雪崩的最后手段。但大促限流要精细——按用户优先级限流，付费用户和核心交易场景优先保障，免费用户和非关键功能先限。粗暴的全局限流会误伤高价值用户，造成商业损失。

大促后的复盘与能力沉淀

大促结束不是终点，复盘才是真正价值所在。每次大促都是一次"极限压力测试"，暴露的每一个问题都是系统改进的宝贵输入。

复盘要回答几个核心问题。容量预判准不准（实际峰值 vs 预期峰值，差距来自哪里）？哪些预案被触发了（触发的原因、效果如何）？有没有意料之外的问题（根因、影响、如何避免）？错误预算消耗了多少（SLO 是否守住）？

把复盘的结论沉淀为系统能力。某个降级路径这次生效了，就把它固化为常态能力（平时也可以用，提升日常韧性）；某个监控盲区这次暴露了，就补上对应的监控；某个应急动作这次有效，就写进 runbook，下次直接执行。每次大促后系统都应该比之前更强——这是大促保障的长期收益。

大促保障的常见误区

最后说几个常见误区，都是我用代价换来的经验。

误区一是"只扩容不做专项治理"。很多团队以为大促就是扩容，结果扩了容还是崩——因为连接、缓存、降级这些非容量因素没准备好。容量是基础，但不是全部。

误区二是"降级策略太激进"。大促时为了保命，把降级开得很激进（大量请求转小模型或缓存），结果用户感知到质量下降，投诉比系统崩溃还多。大促的降级要比平时保守，宁可限流也不要轻易降级质量。

误区三是"不演练就上"。以为平时能用的降级、限流、切流，大促时自然也能用。但大促的流量规模和平时差几十倍，很多平时没问题的机制在极端流量下会暴露隐藏 bug。演练是唯一能提前发现的方式。

误区四是"复盘流于形式"。大促后开个复盘会，说几句"下次注意"就结束了，没有把问题转化为具体的改进任务。这样的复盘等于没做——下次大促同样的问题还会出现。

这一节的关键

大促和极端流量是检验系统成色的最高考场。它的特征是峰值倍数高、时效集中、降级容忍度低。专项准备包括容量和连接预热、缓存预热、降级演练、监控加固。进行中要实时盯盘、分级响应、精细限流。事后复盘的价值在于把极限压力下暴露的问题，转化为系统的常态能力。

至此第五章的实战部分完成。下一节 5.4 从单次大促回到长期视角，讲对话引擎的架构演进路线。