活动型流量洪峰的系统设计：从一次"买一送一"崩溃说起

一句话答案：活动型洪峰与日常流量在量级、时间分布、请求路径三个维度上错配。工程上的应对不是"多买机器"，而是分层限流 + 原子扣减 + 排队削峰 + 降级预案四件事的组合。

一、故障复盘

2026 年 10 月 12 日上午，某头部茶饮品牌因"买一送一"活动，自营小程序被瞬时流量打崩：

• 用户侧：提示"请稍后再试"，外卖页显示"前方 407 杯制作中"；
• 门店侧：开门 40 分钟排 200 多杯，部分门店线上积压 300 余杯，临时叫停到店点单；
• 业务侧：活动规则限定"仅限堂食及品牌小程序"，第三方平台不参与。

最后一条是这次故障的关键变量：规则把全部优惠流量收窄到单一入口，自营通道的瞬时并发被放大了数倍。

二、三个错配

| 错配 | 表现 | 工程后果 |

|---|---|---|

| 量级错配 | 活动峰值是日常峰值的几十倍 | 按日常峰值做的容量规划失效 |

| 时间错配 | 流量挤在开场后 1-2 小时 | 按全天平摊折算的容量在峰值时段过载 |

| 路径错配 | 规则收窄到单一渠道 | 单点入口承接全部洪峰 |

不是系统扛不住流量，是预案里根本没把"活动"当成独立的流量场景。

三、四件事的组合拳

1. 分层限流：不要用洪峰去撞数据库

三层前置拦截：

1. API 网关限流：清洗脚本型高频请求（恶意流量占比可以很高，不在网关拦掉，后端扩容是白费）；

2. 令牌桶放行：按数据库合适的承载水位下发令牌，拿不到令牌的请求在内存层直接阻断；

3. 前端排队：超过处理能力时进入虚拟队列，按序放行并提示"前方还有多少人"。

要点：好的高并发系统不是"硬扛"流量，而是"管理"流量。

2. 原子扣减：不超卖是底线

票务场景的资源限额严格。并发扣减若出现冲突，就是超卖，在现场会变成群体性客诉。

• 不要用数据库悲观锁（高并发下性能差）；
• 推荐用 Redis 单线程 + Lua 脚本，把"余量校验"和"库存预扣减"压成一个不可分割的内存操作。

3. 排队削峰：放票节奏是设计参数

| 放票策略 | 表现 |

|---|---|

| 一次性放票 | 瞬间洪峰、秒光 |

| 分时段投放 | 流量摊平 |

| 排队 + 候补 + 定时释放 | 洪峰被队列吸收 |

某免票景区日均申请 2-2.5 万人、实际放票 1.5 万张——系统完全正常也必然有三成以上抢不到。此时放票节奏就是体验设计的一部分。

洪峰不是问题，问题是用平峰的水位去修平峰的堤坝。

4. 降级预案：把"关线上保现场"做成一个按钮

四个必答项：

1. 熔断阈值：QPS/在线数到多少自动限流（要写死数字）；

2. 降级开关：一键关线上、保现场，并明确谁有权按；

3. 公告口径：谁、多久内、说什么；

4. 补偿方案：没有这一条，一次事故会变成一次信任事故。

一次崩溃赔掉的不是当天订单，是用户对"下次还敢不敢抢"的信心。

四、三个"承载量"要对齐

| 指标 | 来源 | 风险 |

|---|---|---|

| 日最大承载量 | 主管部门核定 | 与线上能力脱钩 |

| 瞬时最大承载量 | 主管部门核定 | 同上 |

| 系统端口承载量 | 供应商自测 | 常无人核定 |

某 5A 景区日承载 3.5 万人次、瞬时 1.4 万人次，而线上预约端口在元旦活动当天被打到拥堵。用户感知的是第三个数，核定的是前两个。

五、上线前压测 5 问

1. 做过压测吗？报告能给吗？

2. 压的是日常峰值，还是活动峰值的 3 倍？

3. 库存扣减是原子还是定时同步？

4. 闸机断网后有离线核验吗？

5. 多渠道库存是同一份吗？

---

*这是《景区数字化这盘棋》第 5 篇。下一篇：免票日之后——为什么"退票"比"卖票"更难做。*