API 速率限制完全指南

若对 API 开放无限访问，等于把王国钥匙拱手让人。不限流会降低价值、限制商业成功。API 所有者通常以每秒事务数（TPS）衡量处理上限，也常对请求数量或客户端可消费的数据量设限，这叫应用级限流。

用户发太多请求时，限流可以节流（throttle）而非立即断开，让客户仍能用服务、同时保护 API。当然，请求超时与开放连接本身也放大了 DoS 风险。

• 性能：不限流，所有使用者都会遭遇慢性能。
• 安全：限流是互联网安全的关键组成，DoS 攻击可用无限请求冲垮服务器。
• 可扩展性：API 爆红时会出现意外流量高峰，限流避免严重卡顿。

GitHub：按请求类型区分限流，通常每个用户令牌或 OAuth 应用每小时上限 5000 次；还提供 /rate_limit 接口让程序查询额度、已用与剩余，帮助开发者避免超限或决定升级。

LinkedIn：分应用级（应用每天总调用）与成员级（单个用户每天总调用），限额因端点而异；限额不写在通用文档，而在开发者后台 Analytics 标签页以可视化方式呈现。

Bitly：分平台级（每小时/每分钟/每 IP）与套餐级（免费到企业），可程序化查询 /v4/user/platform_limits 与 /v4/organizations/{guid}/plan_limits。

限制方式很多。若受限 API 经由后端进程访问，用后端代码限流最易——例如限定每秒 20 请求。Node.js 可用 bottleneck 包（限并发与最小间隔），Ruby/Sidekiq 可用 sidekiq-throttled 等插件。每种语言都有各自的限流库。

• 请求队列：成熟的队列库（如 Android 的 Volley、AWS 的 SQS）近乎开箱即用；也可用 request-rate-limiter 之类库自动排队。
• 节流（Throttling）：通过临时状态控制使用，超限时断连或降带宽；可在应用/API/用户层实施。
• 限流算法：用算法实现可扩展限流，见下节。

• 漏桶（Leaky Bucket）：把请求转成 FIFO 队列，以固定速率处理，平滑流量突发，单服务器/负载均衡上好实现，内存小。
• 固定窗口（Fixed Window）：用简单计数器在固定窗口（如 3600 秒）内计次，超量丢弃；简单但窗口刷新瞬间可能被冲垮。
• 滑动日志（Sliding Log）：按时间戳日志计请求，无窗口刷新突袭问题，但存全量日志成本高、跨服务器计算贵。
• 滑动窗口（Sliding Window）：结合固定窗口与滑动日志优点，用累计计数器并参考上一窗口平滑突发，数据点少、轻量快速，最常用。

Dimensional Research 研究显示，80% 的应用用户遇到问题只会尝试三次就卸载；36% 因性能问题对企业产生负面印象。无限流的请求还会拖慢网页加载，损害 SEO 与品牌——Google 越来越把页面速度计入排名。在移动流量主导的今天，限流是开发者必备技能：它在安全、商业与效率上全面增益。