熔断机制基础概念
在金融压力测试场景中，API 熔断机制是防止级联故障的核心防御模式。当下游服务（如行情网关、风控引擎、清算系统）出现延迟或异常时，熔断器能够快速切断调用链路，避免资源耗尽和雪崩效应。本节从熔断器的本质定义出发，深入解析其三种状态及转换逻辑。
什么是熔断器
熔断器（Circuit Breaker）是一种状态机模式的故障容错组件，其设计灵感来源于电路中的物理熔断器。在分布式金融系统中，熔断器充当调用链路上的“智能开关”，实时监控 API 调用的失败率、超时率或响应时间。当错误指标超过预设阈值时，熔断器自动“跳闸”，阻止后续请求继续发往已故障的下游服务，从而为系统提供自我修复的时间窗口。
核心作用： 熔断器不是修复故障的工具，而是为系统争取恢复时间的“缓冲阀”。在金融交易、实时风控等低延迟场景中，一次熔断可能避免数百万笔交易的连锁失败。
熔断的三种状态
熔断器在运行过程中维护三个核心状态：Closed（关闭）、Open（打开） 和 Half-Open（半开）。这三种状态构成了熔断器的完整生命周期，下表对比了各状态的行为特征与触发条件：
| 状态 | 含义 | 请求处理方式 | 触发条件 | 典型场景 |
|---|---|---|---|---|
| Closed | 熔断器关闭，链路正常 | 所有请求正常通过，同时统计失败率 | 失败率 < 阈值（如 50%） | 行情服务正常响应 |
| Open | 熔断器打开，链路切断 | 所有请求立即失败（快速失败），不调用下游 | 失败率 ≥ 阈值，且达到最小请求数 | 风控引擎超时或返回 5xx |
| Half-Open | 熔断器半开，试探恢复 | 允许少量探测请求通过，其余仍快速失败 | Open 状态持续超时（如 30 秒） | 清算系统重启后试探性调用 |
阈值设计提示： 金融系统中，熔断阈值通常采用滑动窗口统计（如最近 60 秒内的请求），而非全局累计计数。这能更灵敏地反映瞬时流量冲击。
状态转换图
熔断器的三种状态并非静态存在，而是按照严格的规则进行转换。下图展示了完整的闭环状态机：
状态转换的详细规则
熔断器的状态转换并非随意跳转，而是遵循严格的时序与计数规则。以下从金融系统的实际配置角度，拆解每个转换路径的触发条件：
- Closed → Open（关闭到打开）
当滑动窗口内的请求失败率超过阈值（如 50%），且请求总数达到最小统计量（如 10 次）时，熔断器立即跳闸。在金融系统中，此阈值通常设置较低（如 30%），以应对高频交易场景的敏感性。 - Open → Half-Open（打开到半开）
Open 状态持续一段预设的超时时间（如 30 秒）后，熔断器自动进入 Half-Open 状态。这个超时时间被称为“熔断恢复等待期”，目的是给下游服务预留重启或恢复的时间。 - Half-Open → Closed（半开到关闭）
在 Half-Open 状态下，熔断器允许有限数量的探测请求（通常为 1~3 个）通过。如果这些探测请求全部成功，则熔断器认为下游服务已恢复，状态切换回 Closed。 - Half-Open → Open（半开到打开）
如果探测请求中任意一个失败或超时，熔断器判定下游服务仍未恢复，立即回到 Open 状态，并重新计时等待期。
金融场景避坑： 熔断器的超时等待期不宜过短（如 < 5 秒），否则可能导致频繁的状态震荡（Thrashing），使系统在 Open 和 Half-Open 之间反复切换，反而增加开销。建议初始值设为 30~60 秒，并根据实际恢复时间动态调整。
状态转换的补充图示：带计数器的时序流程
为了更直观地展示熔断器在时间轴上的行为，下图以滑动窗口和计数器为核心，呈现一个完整的熔断周期：
实践建议： 在金融压力测试中，建议为熔断器配置独立的监控指标（如 P99 延迟、错误码分布），而非仅依赖失败率。例如，当 P99 延迟超过 500ms 时，即使失败率未达阈值，也应考虑触发熔断，以保护下游资源。