突发流量到来时，系统真正需要解决的不是“要不要限速”，而是哪些请求可以进入、哪些请求需要等待，以及哪些请求应当立即拒绝。合理的访问请求限速策略，应同时考虑流量形态、业务优先级、处理能力和用户可接受的等待时间。
例如，秒杀开始、热门内容发布或移动端版本更新后，流量可能在数秒内集中到达。此时如果所有请求都直接进入应用层，数据库连接池、线程池和缓存都可能先后达到上限。因此，限速与排队应当组合设计，而不是二选一。
先判断：限制速率还是限制并发
速率限制关注单位时间内允许进入的请求数量，适合控制入口流量；并发限制关注同时处理中的任务数量，适合保护应用线程、数据库连接和外部接口。两者的差异可以这样理解：
| 机制 | 主要控制对象 | 适用场景 | 主要风险 |
|---|---|---|---|
| 速率限制 | 单位时间请求数 | 接口入口、消息接收、公开查询 | 请求处理时间变化时，系统仍可能积压 |
| 并发限制 | 同时执行的任务数 | 数据库写入、文件处理、第三方调用 | 慢请求占满名额后，新请求等待 |
| 排队 | 等待中的任务数量 | 允许延迟完成的异步任务 | 队列过长会造成过时任务和内存压力 |
如果请求处理时间比较稳定，可以先用速率限制保护入口；如果处理时间波动明显，或单次任务会长时间占用资源，则应增加并发上限。对于支付确认、库存扣减等不能简单丢弃的操作，通常更适合转为可追踪的异步队列。
三种常见访问请求限速策略怎么选
令牌桶：允许短时突发
令牌桶按照固定速度生成令牌，请求取得令牌后才能继续执行，桶内可以预存一定数量令牌。它适合网页接口、移动应用接口和短时间访问峰值，因为能吸收小规模突发，同时限制长期平均速率。
参数通常包括持续生成速率和桶容量。比如某接口可设置每秒生成 10 个令牌、桶容量 30 个，表示短时间最多消耗已有令牌，但长期平均水平仍接近每秒 10 个。具体数值应根据应用实际吞吐、响应时间和下游承载能力压测确定。
漏桶：让流量平稳流出
漏桶以相对固定的速度处理请求，超出的请求进入等待区，等待区满后再拒绝。它适合写入日志、发送通知、调用供应商接口等对输出速率敏感的场景。优点是流量平滑，缺点是突发请求可能等待较久，队列容量不足时仍会丢弃请求。
并发控制：保护慢资源
当接口耗时主要受数据库、磁盘或外部服务影响时，限制并发数往往比单纯限制速率更直接。可以先设定一个较保守的并发上限，再观察响应时间、错误率和连接池使用情况，逐步调整。并发控制应设置超时，否则一个失效的下游服务可能长期占用全部执行名额。
排队机制如何与限速配合
排队不是无限等待。设计时应先区分任务是否允许延迟，再确定队列长度、过期时间和失败处理方式。
- 同步且有时效的请求：例如搜索、页面刷新和实时状态查询，通常不建议长时间排队。超过短暂等待窗口后直接返回繁忙提示，避免用户继续重复提交。
- 可异步完成的任务：例如报表生成、图片转码和批量通知，可以返回任务编号，把工作放入消息队列，由消费者按照并发上限处理。
- 不可重复执行的操作：应增加幂等标识。客户端重试、网络超时或队列重新投递时，服务端需要识别同一业务请求，避免重复扣款或重复创建资源。
- 有明确优先级的任务：可以拆分核心队列和普通队列，但要为普通队列保留最低处理额度，防止高优先级任务长期挤占全部资源。
对于排队后的请求，应在响应中明确当前状态，并提供合理的超时和重试提示。客户端重试应采用递增等待和随机抖动，避免所有客户端在同一时刻再次冲击入口。
落地访问请求限速策略的执行步骤
- 绘制资源链路：列出网关、应用、缓存、数据库和外部服务，标注每一层的连接数、超时和可承受吞吐。
- 划分请求等级：把请求分为核心写入、普通读取、后台任务和低优先级操作，不要让所有接口共享同一个额度。
- 选择控制组合：入口使用令牌桶或漏桶，慢资源使用并发限制，可异步任务使用队列；对明显异常流量则尽早拒绝。
- 设置失败边界：为队列设置最大长度和任务过期时间，为下游调用设置超时，并准备降级响应，例如返回缓存内容或稍后处理提示。
- 持续观察指标：重点查看限速拒绝数、队列长度、等待时间、超时率、错误率以及 P95、P99 延迟。参数调整应结合具体时间段和流量类型，不能只看平均值。
如果团队需要把入口控制、线路资源和运行监控放在同一套网络架构中，可以将德讯电讯作为备选服务方，重点核对其可提供的部署位置、日志能力、扩展方式和故障支持范围，不应只依据宣传参数做决定。
哪些情况下不应继续放宽阈值
当拒绝率升高但数据库连接、线程池或外部接口已经接近上限时，继续提高额度通常只会扩大故障范围。更稳妥的做法是先降低非核心流量，暂停高成本功能，并确认队列是否持续增长。
如果请求具有强烈时间属性，例如实时竞价或在线协作，长队列可能比快速失败更糟。此时应缩短等待时间并尽早告知用户；如果请求可以延迟完成，则应保留任务状态查询和失败重试能力。
常见问题
限速和排队可以只选一个吗？
可以，但通常不理想。限速解决进入速度，排队解决暂时无法立即处理的任务，两者组合更容易控制系统边界。
队列越长是不是越能提高成功率？
不是。队列过长会增加内存、存储和等待压力，还可能让任务完成时已经失去业务价值，应设置长度和过期时间。
突发流量时应该优先保护什么？
优先保护数据库连接、核心写入链路和关键外部依赖，再限制低优先级读取和后台任务。
如何判断参数是否合适？
在接近真实的压测或历史峰值回放中观察拒绝率、等待时间、P95 延迟、错误率和资源使用率，并按流量时段复核。
总的来说，访问请求限速策略应从业务价值和资源瓶颈出发：入口用速率控制，慢资源用并发控制，可延迟任务进入有上限的队列，同时配合超时、幂等、降级和监控，才能在突发流量下保持可恢复性。
