脉冲流量是什么意思？我先说结论：它不是“流量多”，而是“流量来得猛、走得快”
我第一次听到“脉冲流量”这个词，是在一个做抖音团购券的朋友办公室。那天晚上8点15分，达人直播间突然爆了，5分钟进来1.8万UV，后台订单从每分钟20单跳到400多单。我们那台2C4G、5Mbps带宽的阿里云轻量服务器，CPU直接100%，负载冲到12，MySQL连接数顶到默认的151，Nginx开始吐502。我当时第一反应是加带宽，从5M加到20M，结果还是502。后来才发现，带宽没满，数据库连接池先炸了。HikariCP当时maximumPoolSize只给了20，API峰值420 QPS，一堆请求堵在连接池外面。这个坑我记到现在：脉冲流量先杀死的往往不是带宽，而是连接池、锁和慢查询。
所以我把脉冲流量定义成：在很短时间窗口里，请求量、用户量或订单量突然拉到平时10倍甚至100倍，然后又快速回落的流量形态。它和持续流量的差别，不是总量，而是“斜率”。持续流量50 QPS跑8小时，总请求144万；脉冲流量1000 QPS跑3分钟，总请求18万。后者总量小得多，但对系统瞬时容量、队列、超时、幂等的要求狠得多。你要是只按总请求买服务器，肯定翻车。
脉冲流量适合谁，不适合谁，我踩过3次才分清
第一次踩坑是2022年做私域社群，我以为群里发个红包就能复刻脉冲。结果300人的群，峰值也就40人在线，持续10分钟，连200 QPS都没碰到，大家该干嘛干嘛。第二次是2023年做视频号直播预约，提前买了10台4C8G，结果直播延迟，流量没来，钱白花。第三次才是抖音团购券那次，真脉冲来了，但承接没做好，前5分钟转化率4.2%，峰后30分钟掉到0.8%。我现在的观点很直接：脉冲流量适合新品冷启动、直播秒杀、热点蹭搜、限时券包，不适合SaaS试用、B2B长决策、私域慢运营。前者要的是瞬时爆点，后者要的是持续触达。你把脉冲当增长引擎，容易上瘾；把它当压力测试和钩子验证，才不容易亏。
另外，别迷信“脉冲越大越好”。抖音直播间进来的泛流量，可能60%只停留8秒。你服务器扛住了，转化不一定扛得住。我后来看数据，1.8万UV里，真正点进商品详情的是6200左右，提交订单756单，支付成功682单。支付成功率90.2%，但退款率11%。这说明脉冲流量会放大你的客服、退款、售后问题。峰值不是终点，峰后30分钟才是。
一套7步承接法：从算峰值到峰后30分钟
第1步，先算峰值，不要拍脑袋。公式：峰值 QPS =（预计 UV × 人均请求数 × 前60秒占比）/ 60 × 安全系数。比如1.8万UV，人均12个请求，前60秒占40%，就是18000×12×0.4/60=1440 QPS，安全系数取2，预留2880 QPS。你要是按5分钟平均算，只有720 QPS，实际会死得很惨。
第2步，压测。我们用 wrk：wrk -t4 -c200 -d60s --latency https://api.example.com/activity。目标别定太高，小团队先保 P95 < 500ms、错误率 < 0.1%。当时压到800 QPS时P95已经2.8秒，后来加Redis缓存和异步下单，才降到420ms。
第3步，边缘限流。Nginx配置我贴一下，别照抄，按自己业务改：
limit_req_zone $binary_remote_addr zone=req_ip:10m rate=8r/s;
limit_conn_zone $binary_remote_addr zone=conn_ip:10m;
limit_req zone=req_ip burst=16 nodelay;
limit_conn conn_ip 8;
这组参数的意思是单IP每秒8个请求，突发16个，单IP最多8个并发连接。直播场景别把rate设太低，否则NAT后面的用户会误伤。
第4步，业务层令牌桶。Redis + Lua，桶容量200，补充速率100/s，队列最多5000，超时800ms。超过就返回“活动太火爆，稍后再试”，别让请求堆在Tomcat线程池里。Tomcat默认maxThreads 200，你堆2000个请求，只会一起超时。
第5步，降级。非核心功能先关：推荐流、评论、销量动画、排行榜。核心链路只留下单、支付、库存扣减。我们那次把商品详情页的“猜你喜欢”接口关掉后，数据库QPS从3800降到1900，直接少一半。
第6步，扩容和预热。K8s HPA设CPU 60%，min 3，max 12，但默认缩容稳定窗口是5分钟，扩容也有15秒同步周期。直播前10分钟先手动把pod拉到8个，别等HPA。JVM服务启动要40秒，你不预热，流量来了还在加载类。
第7步，峰后30分钟承接。这是我最想强调的独立观点：脉冲流量的价值不在峰值那一刻，而在峰后30分钟。直播结束后，我们给未支付用户发了一张5元券，短信+服务通知触达4100人，回收186单，转化率从0.8%拉回2.1%。如果只看峰值，你会觉得脉冲很爽；看峰后，你才知道它是不是真订单。
监控看什么：别只盯CPU，这6个指标更早报警
我们后来固定看6个指标：1）入口QPS，Prometheus里 sum(rate(nginx_http_requests_total[1m]))；2）P95延迟，超过500ms就预警；3）5xx比例，超过1%持续30秒就打电话；4）MySQL连接数，超过120就准备扩容，因为默认max_connections=151；5）Redis命中率，低于85%说明缓存设计有问题；6）队列长度，超过2000就降级。这些比CPU更早暴露问题。CPU到100%时，用户已经卡了20秒。
最后说句可能不太中听的：小团队做脉冲流量，最该练的不是“扛住10万QPS”，而是“在2000 QPS时不慌”。你先把限流、缓存、幂等、降级、峰后触达这5件事做顺，再去想大促。脉冲流量像心跳，偶尔冲一下是好事，一直冲就是病。你要做的是让它在可控范围里跳，而不是把心电图拉成直线。