脉冲流量是什么？先别急着升带宽

我第一次听到“脉冲流量”不是在教材里，是去年帮朋友看一个直播带货小站。晚上 8 点秒杀，客服说“卡到进不去”，可 Zabbix 上 5 分钟平均带宽才 120Mbps，CPU 也没红。
我不信，登机器跑 sar -n DEV 1，屏幕每 1 秒刷一次，rxkB/s 从 30000 突然跳到 118000，持续 8 秒又掉回去。
1Gbps 网卡理论 125MB/s，实际能跑 110-117MB/s，那 8 秒基本把 eth0 打满了。
Nginx 日志里 499 从平时 20/min 飙到 1800/min，不是后端慢，是客户端等不及自己断了。
所以我的独立观点：脉冲流量不是“平均流量大”，而是你的监控、限流、扩容、计费窗口全对不上。

我踩过的坑：5 分钟监控为什么骗人

Zabbix 默认 1 分钟，Prometheus node_exporter 默认 15s，很多云监控 5 分钟一个点。
一个 8 秒的脉冲，落在 5 分钟里就是 8/300，平均下来只多了 2.6% 左右，图上几乎平的。
但网卡队列、Nginx 连接数、Redis 热 key、MySQL 连接池不看 5 分钟平均，它们看的是那一秒。
我们当时 Nginx worker_connections 10240，backlog 511，脉冲一来 accept 队列直接溢出，内核丢 SYN。
后来把 net.core.somaxconn=65535、net.ipv4.tcp_max_syn_backlog=8192、Nginx backlog=4096 调上去，才没继续丢。
注意，这不是让你无脑调大，调大只是让队列能吞 3-5 秒脉冲，吞不下还是要限流和削峰。

1 秒粒度怎么抓：工具和参数

先上便宜工具：iftop -t -s 1 -n -N 看实时，nload -m 看总量，sar -n DEV 1 60 看历史 1 秒。
要抓包就 tcpdump -i eth0 -w pulse.pcap -G 60 -W 10，每 60 秒切一个文件，只留 10 个，别把盘写满。
Prometheus 想上 1 秒，采集点数量是 15s 的 15 倍，我们 8 核 16G 的机器每天多 6-8GB，保留 15 天得算好盘。
Grafana 图至少看 rate(node_network_receive_bytes_total[1m])，最好用 irate(...[30s])，别只看 5m。
Nginx 开 $request_time、$upstream_response_time、$connection_requests，499 和 503 分开告警。
如果云厂商只给 5 分钟粒度，就在自己机器装 node_exporter 或 telegraf，别拿平均图做容量决策。

削峰不是加带宽：5 个动作按顺序做

第 1 个动作是前端防抖和排队。秒杀按钮 800ms 防抖，接口带幂等 token，用户点 10 次也只发 1 次。
第 2 个动作是 Nginx 限流。limit_req_zone $binary_remote_addr zone=api:10m rate=20r/s;，接口用 burst=200 nodelay，limit_conn addr 20，超了返回 503 别返回 500。
第 3 个动作是 Redis 预扣库存，Lua 脚本原子扣减，别让请求全打到 MySQL；热点 key 加本地缓存 1-3 秒。
第 4 个动作是消息队列削峰，Kafka 6 个分区，消费端 2000 TPS 慢慢落库，前端先返回“排队中”。
第 5 个动作是内核队列和网卡多队列。tc qdisc add dev eth0 root fq_codel，ethtool -l eth0 看 RSS 队列，8 队列就开 irqbalance。
自动扩容别指望，冷却 300s、JVM 预热 90s，8 秒脉冲早结束了；扩容是保底，不是第一道闸。

持续流量 vs 脉冲流量：一张表看清

最后说个反常识的：脉冲流量最贵的地方不是带宽，是“错误重试”和“连接重连”。
我们当时 499 一多，客户端自动重试 3 次，脉冲从 5 万 QPS 变成 15 万 QPS，这才是雪崩。
所以限流要配合退避，前端重试加随机 200-800ms，最多 2 次；核心接口宁可快速失败，也别拖死连接池。
如果你只记一句：把监控窗口、限流窗口、队列窗口都调到 1 秒级，再看 95 计费图，脉冲流量就没那么玄乎了。