先讲个真事：4200 QPS把我从床上炸起来
2024年3月，我帮一个做宠物用品的独立站做运维。 晚上8点12分，手机告警响了：5xx错误率从0.02%飙到37%。 我打开Grafana一看，QPS从平时80冲到4200，持续了7分钟。 服务器是2核4G，Nginx+PHP+MySQL，MySQL连接数直接顶到500，CPU 100%，页面加载从1.2秒变成12秒。 我第一反应是CC攻击，赶紧封IP，结果封了200多个，后来看日志才发现User-Agent正常，referer全是抖音直播间的短链，转化率2.3%，加购率8.7%。 这是典型的脉冲流量，不是攻击。 那次教训很贵：封了真人，丢了订单，还差点把搜索引擎爬虫也封了。 后来我才明白，判断脉冲流量不能只看QPS，要看转化和来源。
脉冲流量到底是什么？和持续流量有什么区别
脉冲流量，英文叫burst traffic，指的是在很短的时间内，通常是30秒到15分钟，流量突然升高到基线水平的5到100倍，然后快速回落。 它和持续流量最大的区别是：持续流量像涨潮，慢慢涨慢慢退，考验的是容量规划；脉冲流量像海啸，上升沿极陡，可能60秒内就到峰值，半衰期不到10分钟，考验的是弹性和缓存。 三个特征：上升沿小于60秒，峰值大于5倍基线，回落半衰期小于10分钟。 常见场景：直播带货挂链接、微博热搜、Reddit首页、大V转发、秒杀活动。 用户搜脉冲流量怎么应对、突发流量服务器扛不住、网站突然很多访问怎么办，其实都是在找同一件事：怎么在几分钟内不让系统崩。
怎么判断是机会还是攻击？看四个指标
第一个指标，转化率。 如果加购、注册、下单数据正常，那就是机会。 第二个指标，来源集中度。 如果80%的referer来自一个短链或一个直播间，大概率是脉冲。 第三个指标，请求分布。 真实脉冲会请求HTML、图片、CSS、API混合，CC攻击往往集中在搜索接口、登录接口。 第四个指标，用户行为。 真人会有停留时长大于3秒、有点击热图、有滚动事件。 我当时的错误是只看QPS，没看转化。 建议在GA4或Matomo里设实时看板，监控每分钟活跃用户和每分钟事件数。 如果转化率是0，但QPS涨了50倍，那就要小心了，可能是恶意刷流量。 别急着封IP，先看日志，再决定。
应急7步：从限流到降级，按顺序做
第一步，别急着封IP。 封IP会误伤真人，而且攻击者可以用代理池。 第二步，开CDN缓存。 Cloudflare的Cache Rules，对 /wp-content/uploads/* 设Edge TTL 1天，Bypass Cookie。 第三步，Nginx限流。 limit_req_zone $binary_remote_addr zone=perip:10m rate=20r/s; 但只对搜索接口限，静态资源不限。 第四步，Redis缓存热点。 商品详情页缓存60秒，库存单独接口，避免缓存穿透。 第五步，数据库读写分离加连接池。 MySQL max_connections从200调到800，前提是内存够，否则会OOM。 第六步，K8s HPA。 CPU大于60%扩容，min 2 max 20，冷却300秒。 第七步，降级。 关闭推荐、评论、积分，保留下单和支付。 这些步骤按顺序做，不要同时改，否则你不知道是哪个生效了。
具体参数：2核4G单机能扛多少QPS
以2核4G单机为例，Nginx worker_processes auto; worker_connections 10240; keepalive_timeout 30; PHP-FPM pm=dynamic，pm.max_children=50，4G内存别超过60。 Redis maxmemory 1GB，maxmemory-policy allkeys-lru。 MySQL innodb_buffer_pool_size=1GB。 如果QPS超过800，单机基本没救，必须上CDN加多实例。 我们那次后来把静态资源全部推CDN，源站QPS从4200降到680，CPU从100%降到45%。 但要注意，CDN缓存命中率如果低于80%，源站还是会被打穿。 所以缓存键要设计好，不要带用户ID和随机参数。 还有一个参数：Nginx的limit_req burst=50 nodelay，可以处理突发，但别设太大，否则限流形同虚设。
深度对比：脉冲流量和持续流量的打法完全不同
脉冲流量考验的是弹性和缓存命中率，持续流量考验的是成本和架构效率。 很多团队用对付持续流量的方法对付脉冲：直接买高配服务器，结果脉冲过去后资源闲置，浪费钱。 正确做法是预留最小资源，用容器或云函数快速扩容，按秒计费。 另一个对比：脉冲流量是短跑，持续流量是马拉松。 短跑要热身，也就是预热缓存，把热点数据提前加载到Redis；马拉松要配速，也就是容量规划，按峰值加30%冗余。 还有一个反直觉的点：脉冲流量不一定都要接住。 如果转化率低于0.5%，或者来源是垃圾联盟，那可能只是无效流量，接住也没用。 要算账：每1000 QPS的带宽成本、服务器成本，对比带来的GMV。
全新独立观点：脉冲流量是免费的全链路压测
我后来专门做了一个脉冲流量复盘表，记录峰值QPS、5xx率、P95延迟、缓存命中率、扩容耗时。 第二次遇到脉冲，我们把5xx控制在0.1%以下，P95从3.2秒降到420毫秒。 我的独立观点是：脉冲流量不是敌人，是免费的压力测试。 每次脉冲都在告诉你系统的瓶颈：是数据库连接数、是缓存穿透、是带宽、还是某个慢SQL。 但我也要说，别为了接脉冲把架构搞得太复杂。 如果一年只来一次脉冲，用云厂商的弹性伸缩组就够，不必上K8s。 技术选型要看频率，不是看酷不酷。 另外，脉冲流量对SEO有影响：如果5xx持续超过2小时，Googlebot会降低抓取频率。 建议在脉冲期间给搜索引擎单独限流，但不要返回5xx，返回200加缓存页面。
常见问题：你可能想问的4件事
Q: 脉冲流量会不会影响SEO？ A: 会，但短期5xx影响不大，持续2小时以上会掉排名。 Q: 用Cloudflare免费版够吗？ A: 小脉冲够，但免费版没有高级限流和自定义缓存规则。 Q: 要不要上Kubernetes？ A: 如果你每月都有脉冲，值得；如果一年一次，用弹性伸缩组更简单。 Q: 怎么监控？ Prometheus加Grafana，关键指标：request_rate、error_rate、latency_p95、cpu_usage、db_connections。 告警阈值：error_rate大于1%持续1分钟，latency_p95大于1秒持续2分钟。 还有一个坑：别在流量峰值时发布新代码，别在峰值时改DNS，别在峰值时重启MySQL。 这三件事我全干过，每次都是事故。
最后说点个人感受
我见过太多团队在脉冲流量来的时候手忙脚乱，事后又忘了复盘。 其实脉冲流量就像突然来了一群客人，你家门不够宽、厕所不够用，不是客人的错。 平时把Nginx缓存、Redis、数据库连接池这些基础设施弄好，脉冲来了就当一次免费的全链路压测。 我现在的习惯是，每次脉冲结束后，花30分钟写复盘，更新到内部的Runbook里。 下次告警响了，直接照着做，不用再拍脑袋。 如果你也在被脉冲流量折磨，欢迎留言说说你的峰值QPS和5xx率，我帮你看看瓶颈在哪。