Python 电路断路器的状态机实现

断路器需用状态机实现，包含closed、open、half_open三状态及严格转换规则；须用枚举定义状态、字典映射事件与目标状态、统一transition入口、显式处理超时与并发锁，避免if-else硬编码和timer不可靠问题。

状态机必须显式定义所有转换，不能靠 if-else 堆出来

断路器不是“开了关了”两个状态的事，closed、open、half_open 之间有严格触发条件和超时约束。用一堆 if state == 'closed': ... elif ... 写，很快就会漏掉重试失败后该回 open 还是回 closed 的分支，更别说并发下状态竞态。

实操建议：

• 用枚举类 CircuitState 固定三个状态值，禁止字符串硬编码
• 每个状态的「可接受事件」和「目标状态」写成字典映射，比如 {CircuitState.CLOSED: {'failure': CircuitState.OPEN, 'success': CircuitState.CLOSED}}
• 状态变更必须走统一入口 transition(Event)，里面做原子更新 + 超时检查（比如 open 状态要记录 opened_at 时间）

half_open 状态不自动降级，得靠定时器或首次调用触发

很多人以为设了 reset_timeout=60，断路器就会在 60 秒后“自动”切到 half_open——不会。python 没有后台线程帮你守着这个时间点。等超时、切状态、允许一次试探调用，这三步得你明确安排。

常见错误现象：open 状态卡死，永远等不来 half_open，下游服务明明恢复了也持续熔断。

立即学习“Python免费学习笔记（深入）”；

实操建议：

• 不要依赖“时间到了就变”，改为「首次请求进入 open 状态时记录 opened_at，每次调用 call() 前先检查是否超时，超时则转 half_open」
• 或者用 threading.Timer 启一个延迟任务，但注意：Timer 不可靠（进程退出、GIL 阻塞都可能让它失效），生产环境慎用
• half_open 下第一次调用成功，才切回 closed；失败则立刻回 open 并重置计时

并发调用下状态读写必须加锁，但锁粒度不能太大

多个线程/协程同时调用 call()，可能同时读到 open 状态、同时判断超时、同时执行 transition('timeout_expired')，结果重复进 half_open，甚至覆盖彼此的状态变更。

性能影响明显：如果整个 call() 流程都用一把大锁，吞吐直接腰斩，尤其 closed 状态本该无阻塞。

实操建议：

• 只对「状态变更相关代码块」加锁，比如 if self._state == OPEN and now > self._opened_at + self.reset_timeout: 这段判断 + 切换动作必须原子
• 读状态（如判断是否允许执行）可以不加锁，但要用 self._state 这种易变属性，别缓存到局部变量里反复用
• 避免用 threading.RLock，普通 threading.Lock 足够，且更易发现死锁

reset_timeout 和 failure_threshold 参数意义完全不同，别混用

failure_threshold=5 是指连续失败 5 次才熔断，而 reset_timeout=60 是指熔断后至少等 60 秒才允许试探。这两个数单位不同、触发时机不同、甚至可以动态调整——但新手常把它们当同一类“阈值”去调。

容易踩的坑：

• 设 failure_threshold=1 以为“一错就断”，结果网络抖动导致频繁误熔断
• 设 reset_timeout=1 以为“快速恢复”，实际让 half_open 变成高频探测，压垮刚恢复的服务
• 没考虑成功率衰减：比如失败率从 10% 爬升到 90%，光看连续失败次数会滞后响应

真实场景中，failure_threshold 更适合配合滑动窗口（如最近 20 次失败率 > 50% 就开），而 reset_timeout 应按下游服务恢复预期时间设，比如数据库主从切换要 30 秒，那就设 45 秒留余量。

状态机里最麻烦的从来不是画那三个圆圈，而是想清楚每个箭头背后的时间、计数、并发和退化逻辑。少一个条件，线上就多一分不可控。