熔断冷却结束的一瞬间，怎样防止所有等待请求一起探测

熔断冷却期结束，十个等待请求同时看到“可以试探”，若没有原子许可证，就可能全部进入上游。本文把半开准入单独做成参考状态机，在同一逻辑时刻投递十项，检查最多只让一个探测进行；不把示例上限当作产品默认值。

状态转换与许可证一起定义

CLOSED允许正常请求，OPEN在冷却期内拒绝，HALF_OPEN只接受有限探测。附件上限是一。冷却到点只是允许竞争探测资格，不是宣布上游已经恢复。无锁反例让十个请求都先读到空闲，再各自通过；顺序原子参考器先检查再占位，只有第一项获得许可，其他九项等待或拒绝。

“原子”在本实验中是一个不可插入其他事件的参考步骤，并没有实际启动十个线程，也没有验证分布式锁。它把竞态需要防止的结果写清，方便目标实现增加并发屏障测试。若真实产品允许多探测，应该用其实际上限和计数对象替换，而不是改掉断言让所有结果都能通过。

成功、失败、取消分别走清理路径

探测成功后转CLOSED，失败后回OPEN并开始新冷却，取消则保留HALF_OPEN但释放许可，让后续请求可再竞争。这是本文选择的三种迁移，实际实现可能对取消有不同策略，应明确写出。不能把取消默认当成功恢复，也不能让取消留下一个永久占用的许可证。

运行器分别执行成功、失败与抛出合成取消异常三条路径，各自取得一个许可，再在finally释放，保存每条路径从一到零的观测，而不是统一填一个零。三条路径结束时许可证占用都应为零。对于超时或异常退出，还要能清理失联探测，否则一个上游早已恢复，网关仍可能永远认为探测忙。多副本实现通常需要处理许可租约、重复完成和旧探测结果迟到，单进程变量不会自动解决这些问题。

用同刻输入检查边界而非真实施压

附件十个请求只是事件列表，没有向真实模型发探测。集成时可让回环假上游把首个探测挂住，在它结束前同时提交其余请求，观察上游计数是否始终不超过上限；再分别触发三种结果，核对状态和许可。只有保留并发时序证据，才能说真实闸门已验证。

Azure熔断模式资料解释半开状态的有限试探，LiteLLM可靠性文档提供产品配置背景，二者都不意味着本文代码就是产品内部算法。当前通过结果只证明参考迁移符合声明的十进一出和清理约定。把半开入口、许可占用、结果归属和新冷却起点分别记录，可以避免“冷却已经结束”被误当成“所有等待请求都应该立刻恢复”。

配套样本与复核入口

下载本篇独立合成输入和实验运行器。上述文件放在同一目录后运行 python run_lab.py C032。完整运行需要全部四十四份输入及相关配置。结果中的method区分离线计算、静态参考检查与回环实测，不能把前两者当成真实网关已通过。

资料核对日期：2026-10-24。官方依据1；官方依据2；官方依据3。

与本站相关基础教程的区别：旧文介绍熔断器三态；本文专门验收半开时的探测许可证和竞争准入，用状态序列证明并发闸门，不扩写通用容灾。