什么是熔断？

面试考察点

1. 稳定性意识：面试官想知道的不只是你会不会写熔断代码，更看重你脑子里有没有“系统随时会挂”这根弦。分布式环境下故障是常态，能不能意识到这点，是另一个层面的问题。
2. 雪崩效应的理解：知不知道一个下游服务挂了，为什么会拖垮整条链路？这是熔断存在的根本原因。
3. 原理深度：熔断器的状态机（Closed → Open → Half-Open）是不是真的清楚，还是只会调个注解就完事。
4. 框架落地能力：Hystrix、Sentinel、Resilience4j 这几个主流选手各自的定位和差异能不能说清楚。

核心答案

一句话：熔断（Circuit Breaker）是一种自我保护机制。下游服务出故障或响应过慢，达到某个阈值后，熔断器主动 “跳闸”，在一段时间内直接拒绝或降级对该服务的调用。否则故障会顺着调用链一路扩散，把整个系统拖垮。

你可以把它想象成家里的保险丝：电流一过载，保险丝 “啪” 一下断了，保护电器不被烧坏。等电工来修好，再手动合闸恢复供电。熔断器干的也是这事儿，只不过它自己会 “试合闸”。

熔断 vs 降级 vs 限流，这三个概念很多人容易搞混，先一张表理清楚：

一句话总结：限流防自己被压垮，熔断防被下游拖垮，降级是兜底手段。熔断触发后通常会走降级逻辑。

深度解析

一、为什么需要熔断——雪崩效应

熔断存在的意义，全在 “雪崩” 这两个字里。我画个图你就明白了：

假设通知服务挂了，每次响应从 50ms 飙到 30 秒。这时候支付服务还在傻乎乎地调它，请求一个接一个发出去，每个都要等 30 秒才超时。结果就是：

• 支付服务的线程池被占满：所有线程都阻塞在等通知服务响应
• 支付服务也跟着不可用：新来的请求拿不到线程，全部排队
• 订单服务调不到支付服务：自己线程池也被占满
• 网关层请求堆积：连锁反应一路向上
• 整条链路雪崩：一个边缘小服务，搞挂了整个系统

这个过程就像雪崩：一小块雪松动，带动一大片，最后整个山坡都下来。没有熔断，故障会在调用链上指数级扩散。

熔断就是给每条调用链装上 “保险丝”。发现下游不对劲（失败率高、响应慢）就立刻断开，快速失败，把线程释放出来给其他正常请求用。一边牺牲掉对故障服务的调用，一边保住系统其他部分的可用性。

二、熔断器的三大状态

熔断的核心是一个状态机，三个状态来回切换。这是这道题的真正考点，得背下来：

上图就是熔断器的完整生命周期，分三个状态：

• Closed（关闭态，正常工作）：所有请求正常放行，同时熔断器在后台默默统计一段时间窗口内的请求成功 / 失败比例。这是默认状态。
• Open（打开态，熔断中）：当统计期内的失败率突破设定阈值（比如超过 50% 失败），熔断器 “啪” 一下跳闸，所有针对这个服务的请求直接快速失败，根本不发出网络调用。这段时间会执行降级逻辑（返回默认值、缓存、友好提示等）。
• Half-Open（半开态，试探恢复）：熔断器不会一直 Open 下去。等过了一段设定的时间（比如 5 秒），它会进入 Half-Open 状态，放行少量试探请求去探测下游：如果这些请求成功了，说明下游恢复了，熔断器切回 Closed；如果还是失败，重新切回 Open，再等下一轮。

还有一点值得说一下：熔断器能 “自愈”，不用人工干预。它通过 Half-Open 状态主动试探下游，下游一恢复，调用也跟着自动恢复。

三、主流框架对比

Java 生态里主流的熔断框架就三兄弟：

选型建议：新项目直接上 Sentinel（功能全、控制台好用、社区活跃），或者 Resilience4j（轻量、函数式风格、Spring Boot 友好）。Hystrix 已经是过去式了，但很多老项目还在用，面试问到得能说清楚。

四、代码示例（Sentinel）

来一段生产可用的 Sentinel 熔断配置，感受一下：

// 1. 定义熔断规则
private static void initCircuitBreakerRule() {
    List<DegradeRule> rules = new ArrayList<>();

    // 慢调用比例熔断：响应时间 > 200ms 算慢调用
    // 在 10 秒内，若请求数 ≥ 5 且慢调用比例 > 50%，熔断 5 秒
    DegradeRule slowCallRule = new DegradeRule("orderService")
            .setGrade(CircuitBreakerStrategy.SLOW_REQUEST_RATIO.getType())
            .setCount(200)                    // 慢调用阈值：200ms
            .setSlowRatioThreshold(0.5)       // 慢调用比例阈值：50%
            .setMinRequestAmount(5)           // 最小请求数：5
            .setStatIntervalMs(10_000)        // 统计时间窗口：10 秒
            .setTimeWindow(5);                // 熔断持续时间：5 秒

    // 异常比例熔断：异常比例 > 50% 时熔断
    DegradeRule exceptionRule = new DegradeRule("orderService")
            .setGrade(CircuitBreakerStrategy.ERROR_RATIO.getType())
            .setCount(0.5)                    // 异常比例阈值：50%
            .setMinRequestAmount(5)
            .setStatIntervalMs(10_000)
            .setTimeWindow(5);

    rules.add(slowCallRule);
    rules.add(exceptionRule);
    DegradeRuleManager.loadRules(rules);
}

// 2. 业务代码用 try-with-resources 包裹资源
public Order getOrder(String orderId) {
    try (Entry entry = SphU.entry("orderService")) {
        // 业务逻辑：调用下游服务
        return orderClient.query(orderId);
    } catch (BlockException e) {
        // 被熔断 / 限流了，走降级逻辑
        return getFallbackOrder(orderId);
    }
}

// 3. 降级方法：返回缓存或默认值
private Order getFallbackOrder(String orderId) {
    Order cached = orderCache.get(orderId);
    return cached != null ? cached : Order.defaultOrder();
}

几个关键参数的含义：

• setCount：阈值。慢调用模式下是响应时间（毫秒），异常比例模式下是比例（0~1）
• setMinRequestAmount：最小请求数。这个特别重要。要是只有 2 个请求挂了 2 个，失败率 100% 就熔断，那系统抖一下就挂了。一般要求至少 5 个或更多请求才生效。
• setStatIntervalMs：统计窗口。多久算一次失败率
• setTimeWindow：熔断多久。Open 状态持续几秒后进入 Half-Open

五、Hystrix 的 “桶” 统计

如果你面的是老项目岗，Hystrix 还在被问到。它有个有意思的设计：滑动窗口计数。把时间切成一个个桶（默认 10 个桶，每个桶 1 秒），每个桶记录成功 / 失败次数，统计时滑动地取最近 10 个桶求和。

[桶1] [桶2] [桶3] ... [桶10]  ← 当前统计窗口
 ↓     ↓     ↓          ↓
成功   失败  成功      失败

这种设计比 “记录每个请求时间戳” 节省内存，缺点是精度有损失。面试官偶尔会追问这个细节，答上来加分。

面试高频追问

1. 追问一：熔断和降级有什么区别？

   熔断是触发机制，失败率达到阈值就 “断开”。降级是应对手段，主流程走不通就走兜底结果。熔断触发后通常会执行降级逻辑，但反过来不一定，超时、异常这些也会触发降级。

2. 追问二：熔断器的 Half-Open 状态是怎么工作的？

   Open 状态持续一段时间后，放行一个或少量探测请求去调用下游。如果探测成功，说明下游恢复，切回 Closed；如果探测失败，重新回到 Open 再等一轮。Half-Open 是熔断器能自愈的关键。

3. 追问三：为什么需要最小请求数这个参数？

   防止系统冷启动或偶发抖动误触发熔断。比如刚启动时 2 个请求都失败了，失败率 100%，但样本太小不能说明下游真的挂了。所以一般会要求至少 5~20 个请求样本，统计结果才作数。

4. 追问四：Sentinel 和 Hystrix 的核心区别？

   • 设计思路：Hystrix 以熔断为主，限流能力弱；Sentinel 把熔断、限流、系统自适应保护整合在一起
   • 数据统计：Hystrix 用滑动窗口 + 桶；Sentinel 用滑动窗口（LeapArray），支持更细粒度
   • 控制台：Sentinel 有独立的 Dashboard，可视化配置规则；Hystrix 只能看监控
   • 扩展性：Sentinel 规则可以动态推送（Nacos、Apollo），Hystrix 配置相对静态

常见面试变体

• “什么是雪崩效应？怎么防止？”
• “Sentinel 的熔断策略有哪些？”
• “熔断器的状态机是怎么流转的？”
• “Hystrix 为什么不维护了？用什么替代？”

记忆口诀

三态二触一自愈：

• 三态：Closed、Open、Half-Open
• 二触：失败率触发、慢调用比例触发
• 一自愈：Half-Open 自动试探恢复

总结

熔断本质就是分布式系统的 “保险丝”。下游出问题，立刻切断，快速失败，保护上游。核心考点其实就三块：雪崩效应、三态状态机、主流框架差异。自己拿 Sentinel 或 Resilience4j 跑个 Demo，面试时配上实践案例，这道题基本就稳了。