一句话答案活动型洪峰的根因不是服务器不够而是容量、节奏、预案三个环节的错配。活动流量与日常流量是两个物种量级差几十倍、时间挤在开场 1-2 小时、渠道被规则强制收窄。要把系统接住得分别算清容量账、削峰账、预案账——技术解决前两本组织解决第三本。一、先复盘一次买一送一崩在哪一步2026 年 10 月 11 日某头部茶饮品牌借代言人夺冠的热度官宣次日全品类限时买一送一。第二天上午的情况公开报道里写得很清楚8 点开门门店40 分钟排了 200 多杯小程序被冲爆用户点门店自取看到茶友们太热情啦请稍后再试点外卖点单看到前方 407 杯制作中济南有门店线上订单积压 300 余杯部分门店临时叫停了到店点单有店员因为做不过来开始劝退排队消费者相关话题当天冲上微博热搜前两位。品牌致歉的原话是小程序一时有点扛不住。而关于退单补偿口径是暂无其他补偿方案。一位产业分析师的评价是面对瞬时涌入的巨大流量品牌没有做好相关预案……还是比较低级的一个失误。这句话的落点在预案不在技术。二、根因不是服务器不够三个错配把这次事故简单归为服务器不够会漏掉真正的工程问题。活动流量和日常流量在三个维度上是错配的① 量级错配。日常峰值可能只有活动峰值的几十分之一。按日常峰值做的容量规划在活动面前等于没有规划。② 时间错配。活动流量极度集中在开场后 1-2 小时。系统容量若是按全天平摊折算的那么它在上午 9 点必然过载。③ 路径错配。这次活动规则是仅限堂食及品牌小程序第三方平台不参与。规则本身就是一个流量漏斗所有想拿优惠的用户被规则赶进了同一个入口。自营通道本来只承接一部分订单那天却要独自吃下全部洪峰。换句话说活动规则的设计等于亲手把水全部导向了一个闸门。三、三本账缺一本都会崩第一本容量账——三个承载量不是一回事票务/景区系统里承载量至少有三层且常常不同源| 指标 | 含义 | 来源 ||---|---|---|| 日最大承载量 | 一天接待上限 | 主管部门核定 || 瞬时最大承载量 | 同时刻容纳上限 | 主管部门核定 ||系统/预约端口承载量| 一秒能处理多少请求 |供应商自测往往无人核定|以某 5A 景区为例日最大承载量 3.5 万人次、瞬时最大承载量 1.4 万人次——但它的线上预约端口在 2026 年元旦背诵名篇免门票活动当天被集中早间抢约的游客直接打到拥堵大量用户提交不上预约。用户感受到的是第三个数主管部门核定的是前两个数。三个数字之间没有强制换算关系这就是最容易塌的地方。第二本削峰账——放票节奏比总票量更重要同样放 1.5 万张票怎么放结果完全不同| 放票策略 | 表现 | 风险 ||---|---|---|| 一次性放票 | 瞬间洪峰、秒光 | 系统易崩、脚本得手、普通用户抢不到 || 分时段投放 | 流量摊平 | 需用户教育、需候补配合 || 排队 候补 定时释放 | 洪峰被队列吸收 | 需透明进度提示 |某免票景区日均预约申请2 万到 2.5 万人实际放票1.5 万张——即便系统完全正常也必然有三成以上的人抢不到。这种情况下如果还零点一次性放票系统崩不崩只是概率问题体验崩是必然的。洪峰不是问题问题是用平峰的水位去修平峰的堤坝。第三本预案账——崩了之后怎么办这本最容易被跳过也最贵。四个必答项1.熔断阈值QPS/在线数到多少自动限流要有数字不能靠人喊2.降级开关能否一键关线上、保现场3.公告口径谁、多久内、说什么4.补偿方案活动失败用户时间成本怎么补一次崩溃赔掉的不是当天订单是用户对下次还敢不敢抢的信心。四、工程实现要点可复用流量不要直接打到数据库API 网关限流 → 令牌桶放行 → 前端排队三层前置拦截。库存扣减必须原子化用 Redis 单线程 Lua 脚本把校验和预扣减压成一个不可分割的内存操作避免超卖。排队要可见明确提示前方还有多少人把等待焦虑变成可控预期。降级要能按下去把关线上保现场做成一个按钮并明确谁有权按。五、上线前必问的 5 个压测问题1. 做过压测吗报告能不能给别只看 demo2. 压测跑的是日常峰值还是活动峰值的 3 倍3. 库存扣减是实时原子扣减还是定时批量同步4. 闸机断网后有没有离线核验5. 多渠道库存是同一份吗六、FAQQ1换一家供应商能解决吗多数活动崩溃的根因不在供应商技术能力而在活动有没有被当作独立场景做过容量设计和预案。换供应商能解决技术解决不了没有预案。Q2临时加服务器够不够有限。加机器缓解吞吐但解决不了超卖和规则漏斗。Q3预算有限先做哪一本先做预案账。写清熔断阈值、留一个降级开关、备一段公告话术和补偿口径——这三件事基本不花钱性价比突出。结语用平峰的思维去准备峰值的活动崩是迟早的事。景区的洪峰比奶茶更可预测——免票日、节假日、明星活动日期都提前定好。可预测的洪峰还接不住就只能怪预案了。*这是《景区数字化这盘棋》第 5 篇。下一篇拆免票日之后——为什么退票比卖票更难做。关注不迷路。*