为什么API需要限流熔断降级
API平台面临的三大流量风险：突发流量（活动/热点事件导致调用量瞬间暴增）、恶意攻击（竞争对手恶意刷接口、爬虫过量抓取）、级联故障（一个慢接口拖慢所有调用方，引发雪崩效应）。限流负责「削峰填谷」，熔断负责「快速失败」，降级负责「优雅兜底」。
四大限流算法深度对比
| 算法 | 原理 | 突发处理 | 实现复杂度 | 适用场景 |
|---|---|---|---|---|
| 固定窗口 | 每个时间窗口内固定次数 | 边界突发问题 | 低 | 简单场景 |
| 滑动窗口 | 滑动时间窗口统计 | 平滑控制 | 中 | 精确控制 |
| 漏桶 | 恒定速率处理请求 | 强制平滑 | 低 | 整流场景 |
| 令牌桶 | 固定速率生成令牌 | 允许一定突发 | 中 | 推荐方案 |
令牌桶算法详解与实现
令牌桶算法是最推荐的API限流方案。工作方式：以固定速率（如100个/秒）向桶中放入令牌，桶有最大容量（如200个，允许的最大突发量）。请求到达时先从桶中获取令牌，获取成功则放行，失败则限流。特点：允许一定的突发流量（桶满了可以一次性用完），但长期平均速率受限于令牌生成速率。
漏桶算法详解与实现
漏桶算法的特点是以恒定速率处理请求，多余的请求排队或丢弃。就像一个底部有洞的水桶——不管进水多快，出水速度恒定。适合对流量进行「整流」的场景，但不适合需要处理突发流量的场景。
滑动窗口算法详解与实现
滑动窗口解决了固定窗口的「边界突发」问题——如果在窗口切换的瞬间有大量请求，固定窗口无法检测到。滑动窗口将时间轴细分为小的时间片（如1秒/片），统计最近N个时间片的请求数，实现了平滑的限流效果。Redis的Sorted Set是实现滑动窗口的理想数据结构。
生产级限流架构设计
推荐的限流架构：多维度限流（全局维度+IP维度+用户维度+API维度，多层次防护）、分布式限流（使用Redis实现跨实例的全局精确限流）、分级限流（网关层粗粒度限流 + 服务层细粒度限流）、动态调整（根据系统实时负载动态调整限流阈值）。
熔断与降级策略
熔断：当某个API的失败率/慢调用率超过阈值（如50%），自动熔断该API——后续请求直接返回失败而不实际调用后端服务，避免雪崩。熔断状态：关闭→打开(熔断中)→半开(尝试恢复)→关闭(恢复)。降级：当系统负载过高或依赖服务不可用时，自动切换为降级逻辑（如返回缓存数据、返回默认值）。
大规模API平台的限流实践
对于YesApi Pro这类多租户API平台，需要在多个层面实施限流：租户级（每个企业客户的总QPS上限，如VIP 5000QPS、普通 1000QPS）、API级（单个API接口的QPS上限，防止热接口拖垮系统）、用户级（单个开发者的调用频率限制）。