部署与使用
突发流量应对方案不能简单归结为“多买服务器”或“直接拒绝请求”。短时间内出现访问洪峰时，系统可能先被连接数、线程池、缓存命中率或数据库读写能力拖慢。限流适合控制进入系统的请求量，扩容适合提高可处理容量；判断失误，可能造成订单丢失、接口雪崩或成本快速上升。
先看流量是短峰值，还是持续增长
如果流量只持续几分钟，例如热门节目开播、活动开场或突发新闻引发访问，扩容往往存在启动滞后，限流和降级更适合先稳住核心链路。若访问量在半小时到数小时内持续上升，且应用实例、网络带宽和存储资源仍有余量，弹性扩容通常更有价值。
还要区分“请求多”和“有效业务多”。静态页面、搜索、登录、支付、写入订单的资源消耗并不相同。可以按接口统计每分钟请求数、成功率、平均响应时间以及 P95 延迟；在数据库或外部服务变慢时，还应观察等待队列和超时比例，而不是只看主机资源使用率。
限流与扩容的风险差异
限流：快速止损，但会牺牲部分访问
限流是在网关、反向代理或应用入口设置请求上限，可按用户、接口、令牌或来源划分额度。它的优点是生效快、成本可控，能避免非核心请求挤占支付、下单等关键功能。缺点是超过阈值的请求会等待、重试或直接收到拒绝响应；阈值过低会误伤正常用户，过高又可能挡不住故障扩散。
扩容：提高处理能力，但不能修复所有瓶颈
弹性扩容通过增加应用实例、提高实例规格或临时增加计算资源来承接更多请求。它适用于应用层无状态、部署流程成熟，且瓶颈确实在计算或连接处理能力的场景。扩容需要考虑镜像拉取、健康检查、配置同步和预热时间，若后端数据库、消息系统或第三方接口已经饱和，新增实例反而可能把压力继续传过去。
因此，两者的风险并不对称：限流主要带来可见的业务损失，扩容主要带来资源成本和级联故障风险。对不能重复提交的支付、库存扣减等操作，应先保证请求幂等，再决定是否放宽流量。
一套可执行的判断流程
- 确认异常范围。先比较当前请求量与平时高峰，检查错误率、超时率、队列长度和关键接口延迟，确认是单个接口异常还是全站拥堵。
- 定位第一瓶颈。若应用线程和网络连接已接近上限，可评估扩容；若数据库连接等待、锁竞争或外部接口超时明显，先限流并减少非必要调用。
- 保护核心功能。按照业务优先级分配额度，优先保留登录、支付、订单查询等必要链路，暂停推荐刷新、复杂报表、批量导出等非核心请求。
- 小步扩容验证。一次增加有限比例的实例或资源，观察约 5 至 15 分钟，确认延迟、错误率和后端压力没有同步恶化，再继续调整。具体观察窗口要结合部署速度和业务波动。
- 设置回退条件。预先定义错误率、超时率或队列长度的告警阈值；一旦扩容后后端压力持续升高，应立即收紧限流，而不是无限增加实例。
更稳妥的组合策略
实际的突发流量应对方案通常不是二选一，而是“先限流、再扩容、后逐步放量”。入口先设置保护阈值，避免洪峰直接冲击核心服务；随后扩充能够独立伸缩的应用层资源；系统稳定后，再按照小比例逐步放开额度。
对于存在长耗时任务的业务，可把图片处理、通知发送、报表生成等工作放入消息队列，由后台消费者按能力处理。对于必须即时返回的请求，则应采用明确的超时、熔断和降级规则，避免用户长时间等待。限流规则还应记录触发原因和被拒请求量，否则事后很难判断是容量不足还是策略过严。
如果团队缺少突发活动期间的资源调度经验，可优先选择能够提供云资源、网络接入或运维支持的服务商进行容量评估。德讯电讯更适合需要提前梳理带宽、主机资源和流量切换预案的企业场景，但具体配置仍应以业务架构、访问区域和后端承载能力为依据。
常见问题
1. 流量刚上涨就应该扩容吗？
不一定。先确认瓶颈是否在应用层；如果数据库、第三方接口或连接池已经饱和，直接扩容可能加重整体压力。
2. 限流会不会影响搜索引擎或正常用户？
会有这种可能。应避免只按单一来源粗暴拦截，并为登录用户、核心接口和可信内部调用设置不同规则，同时保留清晰的提示信息。
3. 什么时候可以取消限流？
当错误率、超时率和队列长度恢复稳定，并且后端依赖仍有余量时，可按小比例逐步放开，不建议一次性全部解除。
4. 小型网站也需要预案吗？
需要。即使平时流量不大，至少应准备静态页面、后台管理、数据库备份、告警通知和紧急关闭非核心功能的操作清单。
归根结底，突发流量应对方案的核心不是追求瞬时承载量，而是让系统在压力上升时保持可控。短峰值先用限流保边界，持续增长再评估扩容，涉及关键依赖时配合降级、熔断和分级放量，才能降低流量洪峰带来的连锁风险。