广西
一句话答案：大促式活动会把瞬时流量集中到单一入口，而系统的容量通常按日常水位设计。两者的量级差、时间集中度、请求路径三重错配，是"平时正常、一搞活动就崩"的常见原因。应对方式是把活动当作独立场景，分别做容量测算、排队削峰、降级预案。
一、一次典型的瞬时过载
2026 年 10 月 12 日上午，某头部茶饮品牌因推出限时"买一送一"，自营小程序出现瞬时过载：用户端提示"请稍后再试"，外卖页面显示"前方 407 杯制作中"；线下门店开门 40 分钟排队 200 多杯，部分门店线上订单积压 300 余杯，临时叫停到店点单。
从系统角度看，这是一次教科书式的活动型瞬时过载：流量并非全天均匀分布，而是集中在活动开始后的 1-2 小时内爆发。
二、活动流量与日常流量的三个差异
第一，量级差异。 活动峰值可能是日常峰值的几十倍。按日常峰值做的容量规划，在活动面前不成立。
第二，时间集中度差异。 日常流量是"缓坡"，活动流量是"悬崖"。系统容量如果按全天平均折算，那么在峰值时段必然过载。
第三，请求路径差异。 活动规则常限定单一入口（例如"仅限自营小程序"）。规则本身会把所有请求收窄到同一个入口，使该入口的瞬时并发被放大。
三、容量测算：三个"承载量"要对齐
| 指标 | 含义 | 来源 |
|---|---|---|
| 日最大承载量 | 一天可接待上限 | 主管部门核定 |
| 瞬时最大承载量 | 同时刻可容纳上限 | 主管部门核定 |
| 系统端口承载量 | 每秒可成功处理的请求数 | 压测实测 |
这三者之间没有强制换算关系。以某 5A 景区为例：日最大承载量 3.5 万人次、瞬时最大承载量 1.4 万人次，但其线上预约端口在 2026 年元旦"背诵名篇免门票"活动当天被打到拥堵，大量用户提交不上预约。
用户感知到的承载量，是第三个；而核定的，是前两个。
四、排队削峰：把洪峰变成队列
常见做法是三层前置拦截：
1. 入口限流：在网关层按接口/来源维度限速，先清洗高频异常请求；
2. 令牌放行：按后端可承受的写入速率下发令牌，拿不到令牌的请求在内存层阻断，返回排队提示；
3. 前端排队：超过处理能力时进入虚拟队列，按序放行并提示队列位置。
要点是：不是"硬扛"流量，而是"管理"流量。
放票/放量节奏也是一个设计参数：
| 策略 | 表现 |
|---|---|
| 一次性放量 | 瞬间峰值更高 |
| 分时段投放 | 流量摊平 |
| 排队 + 候补 + 定时释放 | 峰值被队列吸收 |
某免票景区日均预约申请 2 万到 2.5 万人、实际放票 1.5 万张——即便系统完全正常，也必然有三成以上的人无法获得名额。这种情况下，放量节奏直接影响体验。
洪峰不是问题，问题是用平峰的水位去修平峰的堤坝。
五、降级预案：崩了之后怎么办
预案需要落到四个具体项：
1. 熔断阈值：并发/在线数到多少自动限流（需有明确数字）
2. 降级开关：能否一键关闭线上入口、保留现场通道
3. 公告口径：谁、多久内、发布什么
4. 补偿方案：活动失败后，用户的时间成本如何补偿
一次过载损失的不只是当天订单，还有用户对"下次还敢不敢参与"的信心。
六、结论
活动型流量的核心命题是：把"活动"当成一个独立的容量场景来设计。
平时扛得住，只是证明了平时的容量；活动扛得住，才证明了系统的容量。
对于景区等客流高度可预测的场景，免票日、节假日的日期都提前确定，属于"可预测的洪峰"——可预测的洪峰若仍接不住，问题通常在预案，而不在运气。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
