什么是 速率限制？
速率限制是一种控制客户端在指定时间窗口内可向 API 或服务发起请求数量的技术，保护系统免受过载和滥用，并确保所有消费者之间的资源公平分配。
快速了解
| 全称 | 速率限制（API 限流） |
|---|---|
| 创建时间 | 概念在互联网早期确立，标准化响应头于 2021 年通过 IETF 提案 |
| 规范文档 | 官方规范 |
工作原理
速率限制是一种关键的 API 管理策略，限制客户端在定义的时间窗口内可以发起的请求数量（如每分钟 100 次请求）。当客户端超出其允许配额时，后续请求将被拒绝——通常返回 HTTP 429（请求过多）状态码——直到窗口重置。这保护后端服务免受过量流量的冲击，无论来源是合法的高流量用户、有缺陷的客户端，还是试图进行拒绝服务攻击的恶意行为者。常见算法包括固定窗口（每个时间窗口的简单计数器）、滑动窗口（更平滑的速率执行）、令牌桶（允许受控突发）和漏桶（强制恒定输出速率）。速率限制通常通过响应头传达：X-RateLimit-Limit（总允许数）、X-RateLimit-Remaining（剩余请求数）和 X-RateLimit-Reset（窗口重置时间）。实现可在多个层面进行：应用代码、API 网关、负载均衡器或基于 Redis 的专用中间件。
主要特点
- 在可配置的时间窗口内控制每个客户端的请求频率
- 超出限制时返回 HTTP 429 状态码
- 通过标准响应头传达限制信息（X-RateLimit-Limit、Remaining、Reset）
- 提供多种算法：固定窗口、滑动窗口、令牌桶、漏桶
- 可按用户、IP、API 密钥或端点粒度应用
- 可在应用层、网关层、负载均衡器层或 CDN 层实现
常见用途
- DDoS 防护：通过限制请求量来缓解拒绝服务攻击
- 公平使用执行：确保单个客户端不会垄断共享资源
- 成本控制：防止失控的 API 消耗导致意外账单
- 服务稳定性：保护后端服务免受流量峰值和级联故障的影响
- 分层定价：为免费版、专业版和企业版执行不同的请求配额
- 合规性：通过为优先客户预留容量来满足 SLA 承诺
示例
Loading code...常见问题
限流（Rate Limiting）和流控（Throttling）有什么区别？
限流（Rate Limiting）通常直接拒绝超出阈值的请求（返回 HTTP 429），属于硬拒绝策略；而流控（Throttling）则是对超量请求进行排队或降速处理，属于柔性降级策略。实际工程中两个术语经常混用，但严格来说：限流侧重于'拒'，流控侧重于'缓'。许多系统会将两者结合——先流控排队，队列溢出后再硬性限流。
常见的速率限制算法有哪些？
四种主要算法是：固定窗口（固定间隔重置的简单计数器，窗口边界可能有突发问题）、滑动窗口（当前和前一个窗口的加权组合，更平滑的限制）、令牌桶（令牌以固定速率累积，允许受控突发）和漏桶（以恒定速率处理请求，超出的排队或拒绝）。令牌桶因其在简单性和突发友好性之间的平衡而最受欢迎。
客户端收到 429 限流错误后应如何处理？
最佳实践包括：读取 Retry-After 或 X-RateLimit-Reset 响应头了解何时可以重试、实现带抖动的指数退避避免惊群效应、缓存响应以减少不必要的请求、尽可能将多个操作批量合并为单个请求，以及主动监控使用量以保持在限制阈值以下。
速率限制应该在哪一层实现？
速率限制可在多个层面实现：在 API 网关层（最常见，集中执行）、在应用层（对每个端点进行细粒度限制）、在负载均衡器或 CDN 边缘层（用于 DDoS 防护），或使用 Redis 等分布式存储（跨多个服务器实例实现一致的限制）。纵深防御建议在多层实现。
如何选择合适的速率限制阈值？
首先分析后端容量和典型使用模式。根据基础设施可持续处理的能力设定限制，并预留突发空间。为不同用户等级考虑不同层级。监控 429 响应率——如果合法用户频繁触发限制，说明设置过紧；如果后端仍然被压垮，说明设置过松。使用渐进式上线并根据实际流量数据调整。