熔断机制是什么？熔断器的状态如何转换？
简化版
熔断机制是在下游持续失败或变慢时，调用方临时停止访问下游，直接返回降级结果，避免请求继续堆积并给下游恢复时间。熔断器通常有关闭、打开、半开三种状态。关闭状态正常调用；失败率或慢调用比例超过阈值后进入打开状态，直接拒绝或降级；等待一段时间后进入半开状态，放少量探测请求，如果成功则关闭，失败则重新打开。
详细版
熔断不是为了让请求成功，而是为了让系统在依赖异常时快速失败，保护调用方资源和下游服务。它适合下游错误率高、超时多、响应明显变慢的场景。
关闭状态下，熔断器记录最近一段时间的调用结果，例如请求数、失败率、慢调用比例。达到最小请求数且超过阈值，就打开熔断。打开状态下，请求不再真正访问下游，而是走 fallback、缓存或错误返回。经过熔断窗口后进入半开状态，允许少量请求试探下游是否恢复。如果探测成功率达标，熔断器关闭；否则继续打开。
工程上要合理设置统计窗口、最小请求数、失败阈值、慢调用阈值、打开时长和半开探测数量。阈值太敏感会误熔断，太迟钝则挡不住雪崩。
完整版教学
一、熔断要解决什么问题
在分布式调用里，下游服务不可能永远健康。它可能响应很慢、线程池打满、数据库抖动、网络超时。如果调用方仍然不断发请求，就会把自己的线程、连接和队列也耗尽。熔断器的作用就是在故障明显时先切断调用链，避免把局部故障扩散成系统雪崩。
熔断的思想和家用电路保险丝类似：电流异常时先断开，不是为了修好电器，而是为了防止更大损失。服务熔断也是如此，它不能修复下游，只能保护调用方和系统整体稳定性。
二、三种状态如何转换
关闭状态是正常状态，请求会真实访问下游。熔断器在这个状态持续统计调用结果，比如最近 10 秒内请求数、失败数、超时数、慢调用数。如果请求量达到最小统计要求，并且失败率或慢调用比例超过阈值，就进入打开状态。
打开状态表示下游被认为不健康。此时新请求不会访问下游，而是直接走降级逻辑，比如返回默认值、缓存值、空列表或错误提示。打开状态持续一段时间后，熔断器进入半开状态。半开状态只放少量请求试探下游。如果探测成功，说明下游可能恢复，熔断器回到关闭；如果探测失败，则重新打开。
三、失败率和慢调用都要关注
很多人只把熔断理解成错误率熔断，但生产中“慢”往往比“错”更危险。下游如果每次都能返回，但耗时从 50ms 变成 5s，调用方线程会大量阻塞，风险同样很高。因此现代熔断器通常支持慢调用比例统计。
合理指标包括异常比例、超时比例、慢调用比例、连续失败次数、并发数等。不同业务适合不同指标。比如支付服务更关注错误和超时，推荐服务可能更关注慢调用对页面整体耗时的影响。
四、熔断和降级的关系
熔断是决策机制，降级是兜底动作。熔断器打开后，系统必须知道该返回什么。没有 fallback 的熔断，只是把下游超时变成快速失败；有合理 fallback，才能把用户体验控制在可接受范围。
但降级不能乱用。查询类、展示类、非核心链路可以返回缓存、默认值或隐藏模块；交易、资金、库存扣减等强一致写链路通常不能返回假成功。面试里讲熔断时，最好顺带说明降级策略要按业务分级。
五、参数设置的工程取舍
熔断参数太激进会导致误判。比如请求量很小，2 个失败就达到 100% 失败率，如果立刻熔断可能误伤。因此一般要设置最小请求数。统计窗口太短容易抖动，太长又反应慢；打开时间太短会频繁试探，太长会影响恢复；半开探测太多可能再次压垮下游。
实践中通常先根据历史 P95/P99、错误率基线和业务可接受降级时间设置初值，再通过压测、故障演练和线上监控调整。熔断器不是配上就完事，它需要持续校准。
六、面试追问与工程边界
常见追问是熔断和限流区别。限流是流量还没进入或刚进入时控制请求量，解决流量过大；熔断是依赖已经异常时停止继续调用，解决故障扩散。另一个追问是熔断是否会导致下游恢复后仍然没流量。半开状态就是为了解决这个问题，用少量探测请求判断是否恢复。
还要注意熔断器本身要轻量可靠。如果统计逻辑复杂、锁竞争严重，反而会增加调用链开销。治理组件也要有默认策略和开关，避免治理系统故障影响业务主链路。
七、落地设计清单
设计熔断器时，要先确定保护对象。保护对象可以是某个下游服务、某个接口、某个方法、某个租户维度，粒度太粗会误伤，粒度太细会配置复杂。然后确定触发指标：异常比例、慢调用比例、连续失败次数、并发线程数等。交易类接口通常对错误敏感，查询类接口通常对慢调用敏感，两者阈值不应一刀切。
还要设计 fallback。fallback 不是随便返回空，而是业务兜底策略。商品推荐可以返回默认推荐，用户画像可以返回基础标签，优惠服务异常时可能只能提示稍后重试。fallback 也要监控，因为大量 fallback 说明系统已经处于降级状态。熔断打开、半开、关闭都应该有指标和日志，否则线上只知道用户失败，却不知道是下游失败还是熔断器主动保护。
八、常见误区和参数经验
第一个误区是请求量很小也按失败率熔断。比如一分钟只有 2 个请求，失败 1 个就是 50%，直接熔断会很荒唐。因此要设置最小请求数或最小统计样本。第二个误区是熔断窗口太短，导致开开关关频繁抖动；或者打开时间太长，下游恢复后业务迟迟不能恢复。
参数经验上，统计窗口要覆盖足够样本，慢调用阈值要参考接口 P95/P99，半开探测数量要小而稳定。熔断策略上线前最好做故障演练：模拟下游超时、下游 5xx、下游慢调用、下游恢复，观察熔断器是否按预期打开和恢复。没有演练过的熔断规则，很可能在真正事故里要么太迟钝，要么过度保护。
九、常见误区与追问
这道题不能只背概念，要把「熔断机制」放回真实分布式系统里解释：谁发起、谁协调、状态如何变化、失败后怎么兜底，以及它和性能、可用性、一致性的取舍。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | 熔断在下游异常率或慢调用超阈值时短暂拒绝请求，防止故障扩散 | 不要停在名词解释 |
| 流程机制 | 关闭状态正常调用 -> 统计错误率和慢调用 -> 超过阈值打开熔断 -> 请求快速失败或降级 -> 半开少量探测 -> 恢复则关闭 | 说明触发方、参与方、状态变化和兜底 |
| 工程取舍 | 10 秒窗口内 100 次请求错误率超过 50% 可打开熔断，30 秒后半开探测 | 治理组件是为了控制故障半径，不是让下游无限扛流量 |
熔断机制 面试拆解：
1. 关闭状态正常调用
2. 统计错误率和慢调用
3. 超过阈值打开熔断
4. 请求快速失败或降级
5. 半开少量探测
6. 恢复则关闭记忆钩子：先定位治理目标，再拆限流、熔断、降级、重试、追踪、灰度和幂等边界；回答时要紧扣「熔断机制」这道题，不要把相邻概念混成一段泛泛的分布式套话。
- 误区：熔断就是限流。 限流控制进入流量，熔断根据下游健康状况阻断调用。
- 误区：熔断打开后永远拒绝。 需要半开探测来判断是否恢复。
- 误区：熔断只看异常数量。 还要结合最小请求数、错误率、慢调用比例和时间窗口。
- 追问：熔断三态是什么？ 关闭、打开、半开。
- 追问：降级返回怎么设计？ 返回缓存、默认值、排队提示或明确失败，不能伪造成功。
- 追问：熔断放在哪里？ 调用方、网关和服务内部都可放，保护的边界不同。
十、加强记忆
熔断器可以记成“关态正常调，开态直接降，半开少量试”。关闭时统计失败率和慢调用，超过阈值打开；打开时快速失败或 fallback；等待后半开探测，成功关闭，失败再打开。熔断保护的是调用方资源和系统稳定，不是修复下游服务。