脉冲流量来了网站扛不住怎么办？我踩过坑后总结的 7 步承接方案

先说我的观点：脉冲流量不是“流量”，更像一次信任脉冲。用户不是来慢慢逛的，他可能只给你 3 到 10 秒。你首页再漂亮，只要转圈超过 5 秒，他就走了。更残酷的是，脉冲流量考核的不是你日常 QPS 有多高，而是你从 200 QPS 拉到 2000 QPS 时，P95、5xx 和支付成功率会不会一起崩。别问我怎么知道的，问就是凌晨三点还在看云监控，手里捏着一罐凉了的咖啡。

我去年帮朋友的小程序商城接抖音团购券流量。活动 20:00 开始，10 分钟进来 1.2 万 UV，约等于 20 UV/s，听起来不大。但接口请求不是均摊的，前 90 秒直接冲到 380 QPS，MySQL 连接数从 80 飙到 600，CPU 100%，首页白屏。我们一开始以为加两台机器就行，结果应用层没死，数据库先跪了。后来靠 Redis 缓存热点商品、静态页兜底、Nginx 限流和一个丑但管用的排队页扛过去。最坑的是支付回调没做幂等，重复订单 37 笔，客服第二天被骂惨。这件事之后，我再也不把脉冲流量当成“大促流量”的缩小版。

1. 先分清：你遇到的是真脉冲还是假脉冲

真脉冲通常有明确来源：推荐流爆了、热搜、群裂变、直播口播、广告集中投放。假脉冲可能是爬虫、恶意刷接口、监控探针、或者某个接口被循环调用。两者处理方式完全不同。真脉冲要保核心链路，假脉冲要封。看日志别只看日均 UV，按 5 秒或 1 分钟聚合。Nginx access log 可以用 goaccess 或 awk 粗看，重点看 top IP、top URL、状态码、UA。如果某个 IP 在 10 秒内打了 2000 次 /api/order，那不是流量，是事故。

2. 压测别测首页，要测最窄的那条路

很多人压测只压首页，首页有 CDN 当然好看。真正会崩的是登录、下单、支付回调、优惠券领取。用 k6 做阶梯：50 VU 跑 3 分钟，200 VU 跑 5 分钟，800 VU 跑 5 分钟，2000 VU 跑 5 分钟，5000 VU 看什么时候 P95 超过 1 秒或 5xx 超过 1%。目标不是 5000 VU 全过，而是知道 2000 VU 时哪个服务先冒烟。我们当时测出来，商品详情能扛 2500 QPS，订单创建只能扛 400 QPS，支付回调最弱，只有 120 QPS。那还等什么？先把订单创建丢进 MQ。

3. 缓存要分层，别只加 Redis

CDN 一层，Nginx 本地缓存一层，Redis 一层，应用本地缓存一层。静态资源 Cache-Control 设 max-age=31536000，动态接口可以 s-maxage=30 加 stale-while-revalidate=60。Redis 热点商品 TTL 设 60 到 120 秒，再加 5 秒本地缓存，能挡住同一秒的重复查询。注意热点 key 别设太短，不然缓存刚写进去就被打穿。我们当时把券库存放 Redis，用 Lua 扣减，数据库只做异步落账，QPS 从 380 降到 90 左右。代价是库存有几十毫秒延迟，但总比超卖好。

4. 限流不是丢人，是保命

Nginx 可以这样配：limit_req_zone $binary_remote_addr zone=api:10m rate=20r/s;，在 location 里加 limit_req zone=api burst=100 nodelay;，再加 limit_conn perip 20;。应用层用 Sentinel 或自己写令牌桶，核心接口按用户 ID 限，非核心接口按 IP 限。限流返回别给 500，给 429 加一句“人太多，10 秒后再试”。我试过把排队页做得像抽奖进度条，用户停留反而比直接报错长。别追求接住 100%，脉冲流量能接住 70% 核心用户，剩下 30% 引导到下一场，比全站崩掉强。这个观点可能不主流，但小团队真没必要为了面子烧钱。

5. 队列、降级、幂等，一个不能少

订单创建写 Kafka，topic 开 12 个分区，消费者并发 6，linger.ms=20，batch.size=32768。消费端用唯一键 request_id 做幂等，数据库建唯一索引。降级开关提前埋好：推荐服务超时 200ms 返回兜底榜单，评论关闭，积分任务延迟，排行榜 5 分钟更新一次。监控告警至少设三条：5xx 大于 1% 持续 1 分钟，P95 大于 800ms 持续 2 分钟，队列积压大于 10000。别等用户截图发群里你才知道。我们那次就是支付回调没幂等，重复订单 37 笔，后来加唯一索引和状态机才补上。

6. 复盘：脉冲流量是在帮你做压力测试

活动结束别只看 GMV。把 7 天日志留好，按 1 分钟粒度拉出 QPS、P95、5xx、缓存命中率、队列积压、支付成功率。问三个问题：哪个服务最先崩？哪个开关没用上？哪段代码最耗数据库？我们复盘发现，最该保护的不是首页，而是支付回调。首页白屏用户会重试，支付回调丢了用户会投诉。下一次活动前，我们只做了三件事：静态页兜底、支付回调幂等、Nginx 限流。结果同样 1 万多 UV，P95 从 2.3 秒降到 680ms，5xx 从 4.7% 降到 0.3%。不是架构变高级了，是终于知道该保护什么了。

最后一句，不是总结

如果你问我脉冲流量最怕什么，我会说最怕你把它当日常流量。日常流量拼转化，脉冲流量拼生存。先活下来，再谈增长。至于那些说“加机器就完事”的人，可能没在凌晨三点看过 MySQL 连接数爆表。反正我是不信了。