做好回源控制，核心是合理设置限速阈值并配备突发处理机制，确保源站流量平稳，避免因瞬间高并发导致源站过载或崩溃。
为什么必须做回源控制？限速与突发处理的必要性
源站服务器通常带宽有限、处理能力固定，当大量用户请求同时回源，尤其是CDN缓存未命中、热点事件爆发或恶意爬虫攻击时，流量会直接冲击源站。没有回源限速，源站CPU、内存、数据库连接数会被瞬间打满，导致响应超时甚至服务中断。
行业共识认为,相当一部分源站故障并非硬件不足，而是缺乏有效的回源流量控制，限速（Rate Limiting）与突发处理（Burst Handling）正是解决这一问题的两大支柱，限速让你定义源站能承受的最大流量阈值，突发处理则允许短暂超出阈值时优雅排队或丢弃，而非直接拒绝或崩溃。
- 限速：设定每秒请求数（RPS）、并发连接数或带宽上限，超过则延迟或拒绝。
- 突发处理：通过令牌桶（Token Bucket）或队列机制，在流量波动时吸收短时峰值，避免源站被瞬间压垮。
两者配合,源站才能在高并发和正常流量间平稳切换。
回源限速怎么设置？速率限制与连接数限制
基于请求速率的限速
最常用的限速方式是按每秒请求数（RPS）或每秒查询数（QPS）限制，配置时需明确“单位时间窗口”和“最大请求数”，例如Nginx的limit_req模块，CDN平台上的“回源速率限制”选项。
实操步骤示例（以Nginx反向代理为例）：
- 定义限速区域：
limit_req_zone $binary_remote_addr zone=one:10m rate=100r/s;（每秒100个请求，共享内存10M） - 应用限速：
limit_req zone=one burst=50 nodelay;（最大突发50个，超出立即返回503）
核心参数：rate（平均速率）、burst（突发大小）、nodelay（是否限速时延迟）。不设置burst时，任何超过rate的请求都会被拒绝，这可能造成正常用户丢包。
基于并发连接数的限速
连接数限速限制同时与源站保持连接的请求数量,适合PHP-FPM、MySQL等有限连接池的场景。较多CDN服务商提供“回源并发连接数”配置项，需根据源站最大连接数设定。
| 限速方式 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 请求速率限速 | 高并发API、静态资源回源 | 精确控制QPS，防突发效果明显 | 对短时波动敏感，需要配合burst |
| 连接数限速 | 后端有连接池限制（如数据库） | 保护源站连接数不过载 | 无法精确控制RPS，需结合其他策略 |
注意：两种限速可同时部署，但阈值需分压测试得出。建议先用压测工具找出源站最大承受能力，再设置80%的告警阈值。
突发处理如何避免源站崩溃？令牌桶与队列缓冲
令牌桶机制原理
突发处理最常见的实现是令牌桶,桶中存放代表“许可”的令牌，以固定速率生成，请求消耗令牌才能通过，桶容量允许一定量的令牌积累，当瞬时请求超过平均速率时，可消耗积累的令牌实现短时突发。
- 平均速率：令牌生成速率，对应限速的
rate。 - 桶容量：可积累的最大令牌数，对应
burst值。 - 请求处理：有令牌则通过，无令牌则排队或拒绝。
实际配置时，桶容量至少要能容纳一次热点事件的最大瞬发请求，例如正常流量1000rps，峰值可能到3000rps持续1秒，burst至少设为3000，但需考虑源站能否承受；若不能，则设置更低的值并让CDN节点缓存或排队。
队列与延迟处理
另一种常见做法是让超限请求排队等待,而非直接拒绝。Nginx的limit_req指令中不设置nodelay时，请求会进入队列以固定速率发出，这会导致后续请求延迟增加，但能保证源站不超载。
选择策略：
- 若源站对延迟敏感且请求可重试（如API返回503），建议使用
nodelay直接拒绝。 - 若源站可接受短暂延迟（如静态资源下载），使用队列方式更友好。
业内专家指出，大多数场景建议同时开启队列和限速拒绝，例如设置队列长度上限，超过则拒绝，避免队列无限堆积导致雪崩。
限速与突发处理的最佳配合策略
分层部署：CDN节点与源站两级控制
多数情况下，回源控制应部署在CDN节点或反向代理层
，而非直接修改源站配置，这样源站本身保持简洁，所有流量控制由边缘层完成。
- 第一层：CDN节点对用户请求限速，降低回源率。
- 第二层：CDN回源时做限速与突发处理，保护源站。
场景举例：某站点使用百度云加速，可在控制台设置“回源QPS限制”为500rps，突发阈值1000，当节点回源请求超过1000rps时，额外请求返回503，源站正常工作。
动态调整阈值：基于机器学习的自适应限速
近年部分CDN服务支持根据源站实时负载（CPU、响应时间）自动调整限速阈值。这种自适应回源限速能避免硬编码阈值不适应流量变化，但需注意，阈值调整频率不宜过快，否则可能触发震荡。
搭配熔断与降级
限速和突发处理无法完全覆盖所有异常,建议配合熔断（Circuit Breaker）机制：当源站连续错误或超时比例超过阈值，直接切断回源流量，返回过时缓存或友好提示。熔断是限速失效后的最后防线。
不同场景下的回源控制配置
CDN节点回源（高并发静态资源）
- 目标：保护图片/视频源站，避免因热点文件导致源站带宽耗尽。
- 配置：在CDN控制台设置“回源带宽限速”为最大带宽的80%，同时开启“突发带宽”为100%。同时设置“回源请求限速”为服务器峰值RPS的70%。
- 操作路径（以某CDN平台为例）：控制台 → 域名管理 → 回源配置 → 限速与突发处理 → 分别填写速率和突发值。
API网关回源（动态接口）
- 目标：保护后端微服务，防止单个API引起雪崩。
- 配置：使用网关的限流插件，设置按IP或API Key限速，并启用Token Bucket。对于关键接口，将burst值设为平均速率的2倍，并开启队列超时。
- 示例：Kong网关的
rate-limiting插件，Platinum方案中可在Consumer级别设置limit和window_size，并启用burst参数。
反向代理回源（内部服务）
- 目标：保护数据库或中间件，避免慢查询堆积。
- 配置：在Nginx/HAProxy中设置
limit_req
limit_conn，同时监控后端连接数。当后端连接数达到80%时，触发限流告警。
常见误区与避坑指南
- 限速阈值设置过高或过低，设置过高失去保护意义，设置过低导致正常用户被限。建议通过压测算出源站稳定处理的RPS，再乘以0.7作为起始阈值。
- 忽略突发上限，只设置平均速率而不设置burst，导致短时正常流量被误杀。burst值至少应等于一次正常业务高峰的最大请求数。
- 限速后没有监控和告警，限速导致大量503时，仍需通知运维介入。配置限速的同时，必须监控回源错误率。
- 所有场景统一使用同一限速策略，不同回源对象（静态、动态、数据库）需分别设置。查询接口和写入接口的限速值应不同。
回源控制不是简单的开关,而是一个需要持续调优的过程。限速与突发处理是源站稳定的基石，结合合理的阈值、监控和熔断机制，才能让源站在高并发下依然可靠工作，每一次配置调整都应基于真实压力和业务特点，而非盲目套用模板。
回源限速与突发处理常见问题（Q&A）
回源限速会增加用户访问延迟吗？
限速本身不直接增加延迟,但突发处理中的队列机制会引入等待时间，如果配置了nodelay，超限请求直接返回错误，用户需要重试。更合理的做法是在CDN节点缓存中直接返回过时内容，避免回源请求到达限速层，用户感知的延迟主要来自源站响应速度，而非限速逻辑。
突发处理设置多大才算合理？
突发值应基于业务短时峰值流量。一般建议取平均速率的1.5到3倍，具体取决于源站能承受的瞬间压力，例如平均1000rps，突然1500rps持续1秒，则burst设为1500，如果源站超载会导致雪崩，则burst值应更低，并配合后端熔断。
免费CDN服务是否支持回源限速与突发处理？
部分免费CDN服务提供基础的回源速率限制,但高级突发处理（如自定义队列、令牌桶参数）通常需要付费。如果你需要精细化控制，建议选择企业级CDN或自建反向代理，免费方案一般只有简单的连接数限制，无法应对突发流量。