1. 限流熔断概述
什么是 API 限流与熔断
在金融系统中，API 网关或微服务架构下，限流（Rate Limiting） 与 熔断（Circuit Breaking） 是保障系统稳定性的两大核心手段。它们的目标一致——防止系统过载，但作用机制与触发条件截然不同。
核心定义：
限流：控制单位时间内允许通过的请求数量，超出阈值的请求被直接拒绝或排队等待。
熔断：当下游服务或资源持续出现故障（如超时、错误率飙升）时，主动切断对该资源的调用链路，避免级联雪崩。
限流：控制单位时间内允许通过的请求数量，超出阈值的请求被直接拒绝或排队等待。
熔断：当下游服务或资源持续出现故障（如超时、错误率飙升）时，主动切断对该资源的调用链路，避免级联雪崩。
限流关注的是“流量入口”的管控，熔断关注的是“故障传播”的阻断。两者在金融系统中缺一不可。
为什么金融系统需要限流熔断
金融系统对可用性、数据一致性、资金安全的要求极高。一次接口雪崩可能导致交易失败、订单丢失甚至资金损失。以下是金融系统必须引入限流熔断的四大原因：
| 风险场景 | 后果 | 限流熔断的作用 |
|---|---|---|
| 突发流量（如秒杀、新股申购） | 数据库连接池耗尽，服务宕机 | 限流：按容量放行，拒绝超额请求 |
| 下游服务故障（如支付网关超时） | 上游线程阻塞，级联雪崩 | 熔断：快速失败，避免资源耗尽 |
| 恶意攻击或爬虫 | 带宽/计算资源被占用，正常用户无法访问 | 限流：基于 IP/Token 的速率限制 |
| 依赖资源降级（如 Redis 主从切换） | 缓存穿透，数据库压力骤增 | 熔断+限流：双重保护数据库 |
⚠️ 金融场景特别提示： 限流熔断不能替代业务幂等性设计。被限流或熔断拒绝的请求，客户端必须实现重试与幂等机制，否则可能产生重复扣款或订单状态不一致。
限流与熔断的区别与联系
限流和熔断虽然经常被一起讨论，但它们的关注点、触发条件和恢复机制有本质区别。下表从多个维度进行对比：
| 对比维度 | 限流 | 熔断 |
|---|---|---|
| 关注点 | 流量速率 | 故障状态 |
| 触发条件 | 请求量超过预设阈值 | 错误率/超时率超过阈值 |
| 作用方向 | 入口→出口（控制上游） | 出口→入口（保护上游） |
| 状态变化 | 持续计算，无状态机 | 关闭→打开→半开→关闭 |
| 恢复方式 | 流量下降后自动恢复 | 半开探测成功后自动恢复 |
| 典型返回码 | 429 Too Many Requests | 503 Service Unavailable |
| 粒度 | 用户/IP/API/全局 | 下游服务/接口/连接池 |
两者的联系体现在：限流是熔断的前置防线，熔断是限流的兜底机制。在实际金融架构中，它们通常组合使用：
- 先限流后熔断：限流挡住大部分异常流量，熔断应对下游持续故障。
- 限流触发熔断：当限流拒绝率过高时，可触发熔断以快速释放资源。
- 熔断期间限流：熔断打开后，对故障服务的请求直接降级，同时限流保护降级逻辑。
💡 最佳实践： 在金融系统中，建议将限流阈值设置为系统容量的 70%~80%，熔断的错误率阈值设置为 50%（5 分钟内）。同时开启限流熔断的监控告警，当限流拒绝率超过 10% 或熔断状态变化时，立即通知运维人员。