你知道吗？现在想让一个系统同时跑 Chat、Embedding、Rerank 那些 AI 模型，真的是一件比Zuo饭还麻烦的事。别担心，我这儿有一套好用又贴心的熔断保护方案，帮你把多模型调用变得像打牌一样顺手。

要是你跟我一样，一边写代码一边被各种错误打乱了节奏，那就geng懂我说啥了。每次远程模型返回超时、限流、网络抖动……douNeng让人抓狂。Zui痛苦的是：主模型坏掉后你还得把请求塞到备用上，没办法自动切换，整个流程像老式

熔断其实就是当某个服务连续失败到一定阈值，就主动停止给它发请求，让它有喘息时间。想象一下核电站里的“数字控制棒”，遇到异常就立刻插进去，防止灾难。咱们在 AI 场景里就是把那根棒子放进模型调用链里。

按优先级遍历候选模型
检查当前模型是否允许调用
Ru果正在熔断，跳过
Ru果允许调用，尝试请求
成功返回结果
失败记录并尝试下一个模型

代码简单，但核心是状态管理：CLOSED→OPEN→HALF_OPEN。当状态是 OPEN 时Ru果时间还没到就直接跳；到了则切到 HALF_OPEN，让第一个请求探测。

consecutiveFailures 连续失败次数
openUntil            熔断结束时间
halfOpenInFlight     半开时是否Yi有探测请求
state                当前状态

这些字段足够覆盖大多数场景。记得每次成功就清零失败次数；失败就递增，当达到阈值时转为 OPEN 并记录 openUntil；半开成功恢复为 CLOSED，否则重新进入 OPEN。

Ru果你跑着多个服务实例，它们dou想共享同一个健康状态，那就别把状态保存在本地内存。Zui常见的是放进 Redis 或者其他共享存储。这样，一个实例发现模型坏了就Neng让所有实例dou知道不要再叫它。

SET model-health:chat-model NX PX openDurationMs
# 第一个拿到锁的实例负责探测，其余直接跳过

这样既省去了轮询，又避免了并发冲突。

哈哈，这可不是我说的，我也不知道他们到底怎么选词。不过通常情况下大平台geng关注热门内容，对技术细节不够感兴趣。Ru果你想让自己的文章被geng多人kan到，Zui好先把文章写得通俗易懂，再加上适当的关键词搜索优化；别光顾着写代码，还得学点 SEO 技巧哦。

class HealthState {
    int consecutiveFailures;
    long openUntil;
    boolean halfOpenInFlight;
    State state;
}
public boolean allowCall {
    HealthState h = getState;
    if  return true;
    if  {
        if  

for  {
    if )) continue;
    try {
        Result result = callModel;
        healthStore.markSuccess);
        return result;
    } catch  {
        healthStore.markFailure);
    }
}
throw new RuntimeException;