面试考察点
- 是否理解四种手段解决不同故障阶段的问题。
- 能否设计端到端超时预算和有限退避重试。
- 是否考虑重试放大、幂等和半开探测。
核心答案
超时限制单次等待，重试处理短暂失败，熔断在持续失败时快速阻止调用，降级提供可接受的替代结果。正确顺序是先定义端到端预算，每跳超时小于剩余预算；只对幂等且可能恢复的错误有限重试；熔断后快速失败并进入降级。
四者必须配合隔离和限流，否则线程、连接和队列仍可能被慢依赖耗尽。
重试策略
使用指数退避加随机抖动，限制次数和总耗时，并尽量只在一层重试，避免调用链每层三次形成指数放大。写操作携带幂等键，明确超时后“结果未知”的查询或补偿路径。
端到端超时预算
假设用户请求总预算 800 ms，入口解析和本地处理预留 100 ms，调用库存和价格各需要并行访问，则每个依赖不能都设置 800 ms。应为每跳分配剩余预算、网络传输和重试空间，例如依赖单次 250 ms、最多一次快速重试，剩余时间用于聚合与响应。
总预算 800ms
-> 服务自身 100ms
-> 依赖并行窗口 500ms
-> 降级/序列化/网络余量 200ms
超时设置应沿调用链传播 deadline，而不是每层重新从零开始计算。否则内层请求已经超时，外层还在等待；线程和连接会在用户已放弃后继续占用。
重试放大模型
若入口一次请求调用 3 个服务，每层都重试 3 次，最坏情况下下游可能承受 27 倍请求。正确策略是只在最靠近可恢复错误的边界有限重试，并传播 attempt、deadline 和幂等键。连接超时、连接被拒绝、429、5xx 和业务 4xx 的重试语义应分别配置。
指数退避要加随机抖动，避免同一批请求同时再次冲击依赖。重试队列要有容量与死信，后台重试不能绕过入口限流。
熔断状态机
CLOSED --失败率/慢调用超阈值--> OPEN
OPEN --冷却时间到--> HALF_OPEN
HALF_OPEN --探测成功--> CLOSED
HALF_OPEN --探测失败--> OPEN
小样本下不能立即熔断，需设置最小请求数和时间窗口；探测请求应少量、可控且优先幂等。统计维度要区分超时、业务拒绝、客户端参数错误和下游真正故障，否则正常 4xx 会把熔断器误触发。
熔断与降级
熔断器根据时间窗口内失败率、慢调用率和最小请求数从关闭转为打开，冷却后半开少量探测。降级可以返回缓存、默认值、排队受理或关闭非核心功能，但不能把错误伪装成真实成功。
常见误区
超时设得越长不代表越可靠，只会让资源更久被占用。熔断阈值过敏会在小样本下抖动，过迟又无法阻止级联故障，需要压测和故障演练校准。
降级不是返回假成功
可接受降级包括读取上一版缓存、隐藏推荐模块、返回排队受理、使用静态配置或只保留核心字段。不能把扣款未知、库存未知伪装成成功；结果不确定时应返回操作号和查询入口。降级逻辑本身也要测试、监控和设置恢复条件。
隔离与舱壁
按依赖拆线程池、连接池、信号量和队列，避免一个慢合作方占满所有请求线程。隔离容量要与下游真实配额匹配；池太大只会把拥塞转到数据库或网络。对非核心任务使用低优先级和独立队列，故障时先丢弃或暂停。
故障演练指标
演练 DNS 失败、连接超时、响应慢、部分 5xx、返回脏数据和恢复抖动，记录错误率、P99、重试次数、熔断状态、线程/连接池、队列、下游压力和恢复时间。没有演练的“熔断已配置”无法证明级联故障真的被控制。
高频追问与参考回答
追问：什么时候不应该重试？
参数错误、权限失败、明确业务拒绝、非幂等且无幂等键的操作，以及剩余预算不足时都不应自动重试。
追问：重试和超时哪个先设计？
先定义端到端超时预算，再决定在剩余预算内是否允许有限重试；没有预算的重试等于无限等待和资源泄漏。
追问：熔断打开后所有请求都失败吗？
通常快速失败非核心依赖，并允许少量半开探测；核心业务可走缓存、排队或备用路径。策略必须明确优先级，不能一刀切让整个系统不可用。
追问：限流和熔断可以只选一个吗？
限流保护容量，熔断处理持续失败；下游正常但流量过大需要限流，下游已故障则需要熔断，通常应配合使用。
总结
超时限定成本，重试恢复瞬时故障，熔断阻止持续伤害，降级维持核心服务；共同目标是控制失败扩散。
机制全景图
下面把「熔断、降级、超时和重试应该如何配合？」从输入到结果压缩成一条可复述的主链路。面试时先用图建立全局坐标，再进入局部实现，能避免只背零散结论。
flowchart LR
A["请求进入隔离舱"]
A --> B["应用超时预算"]
B --> C["失败触发有界重试"]
C --> D["熔断并返回降级"]
D --> E["半开探测后恢复"]
完整链路：从输入到结果
沿着「请求进入隔离舱 → 应用超时预算 → 失败触发有界重试 → 熔断并返回降级 → 半开探测后恢复」观察输入、状态与输出，下面每个阶段都对应一个可以在源码、日志或系统表中验证的位置。
1. 请求进入隔离舱
线程池、连接池或信号量隔离不同依赖，避免一个故障耗尽全部执行资源。
2. 应用超时预算
端到端超时预算要逐级递减，内部调用不能各自使用比入口更长的超时。
3. 失败触发有界重试
重试只适合瞬时故障和幂等操作，应使用退避、抖动和重试预算防止流量放大。
4. 熔断并返回降级
熔断器依据失败/慢调用在窗口内达到阈值后快速拒绝，降级必须是业务可接受结果。
5. 半开探测后恢复
半开状态只允许少量探测，恢复应渐进，避免依赖刚好转立即被全量流量再次打垮。
源码与实现定位
| 入口 | 阅读重点 |
|---|---|
| Resilience4j CircuitBreaker events | 状态与窗口 |
| 调用链 retry_count | 重试放大 |
源码或系统表应按上表顺序追踪：先确认入口实际走到哪条路径，再用运行时数据验证，而不是仅凭类名或配置推测。
参数配置与可复现实验
timeout=300ms; maxAttempts=2; waitDuration=50ms; failureRateThreshold=50%
让下游延迟、错误、恢复逐段变化，验证超时、熔断、半开和渐进恢复。
验证步骤与预期结果
1. 固定输入和基线
先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「重试放大倍数」为主基线，记录值应满足「记录活动/稳态基线」；同时保存 超时与慢调用率、重试放大倍数，使后续变化能够回到同一时间轴比较。
2. 从实现入口确认路径
在「Resilience4j CircuitBreaker events」确认请求确实进入「状态与窗口」对应的实现，再沿「调用链 retry_count」观察「重试放大」。如果入口路径都未命中，就不应继续调整下游参数，而应先检查调用条件、版本或路由是否与假设一致。
3. 注入本文特有的失败模式
优先复现「每层各重试三次形成指数放大」，并把单一变量逐级放大，直到「重试放大倍数」越过「超过容量或 SLO」。随后再分别验证「降级返回成功却写入错误业务状态」和「半开一次放全量流量」，三类故障分开执行，避免多个变量同时变化而无法归因。
4. 执行止损和根因修复
第一轮只应用「总预算逐级递减」，确认它能控制影响范围；第二轮应用「只重试幂等瞬时错误」，验证核心链路恢复；最后落实「隔离池与下游容量对齐」，消除同类问题再次出现的条件。每一步都保留变更前后数据，不用“感觉变快了”替代测量。
5. 通过退出条件
实验只有同时满足三项才算通过：「重试放大倍数」回到「记录活动/稳态基线」、「端到端 P99」回到「小于预算」、「状态差异」回到「0」，并且业务结果差异为零。若性能恢复但结果不一致，仍应视为失败；若指标恢复后很快再次越线，则说明只完成了临时止损，没有消除根因。
量化基线
| 指标 | 样例基线/口径 | 风险线 | 结论 |
|---|---|---|---|
| 重试放大倍数 | 记录活动/稳态基线 | 超过容量或 SLO | 触发降级 |
| 端到端 P99 | 小于预算 | 突破预算 | 停止扩量 |
| 状态差异 | 0 | 任意非零 | 补偿并对账 |
这些数值是实验口径或示例告警线，不是可复制到所有系统的固定答案；上线阈值应由本系统稳态、峰值和故障演练共同确定。
事故复盘：下游超时引发整站线程耗尽
每个请求串行调用下游三次重试，每次 2 秒，入口线程大量阻塞。将下游隔离、总预算 800ms、只对安全错误重试一次并设置熔断后，故障不再跨服务扩散。
| 失败模式 | 首要证据 | 第一处置动作 |
|---|---|---|
| 每层各重试三次形成指数放大 | 超时与慢调用率 | 总预算逐级递减 |
| 降级返回成功却写入错误业务状态 | 重试放大倍数 | 只重试幂等瞬时错误 |
| 半开一次放全量流量 | 熔断状态变化 | 隔离池与下游容量对齐 |
发布与回滚检查点
- 发布前：确认「Resilience4j CircuitBreaker events」对应实现和上述配置在目标版本仍然有效，并保存「重试放大倍数」基线。
- 灰度中：同时观察 超时与慢调用率、重试放大倍数、熔断状态变化；任一指标越过表中风险线，就停止继续扩量。
- 回滚时：先执行「总预算逐级递减」控制影响，再回退代码或参数；涉及持久状态时必须额外核对结果差异。
- 发布后：至少覆盖一个完整峰值周期，确认「每层各重试三次形成指数放大」没有再次出现，才关闭变更观察窗口。
方案对比与选型
| 方案 | 更适合的场景 | 主要收益 | 代价与边界 |
|---|---|---|---|
| 超时+有界重试 | 短暂网络抖动、操作幂等 | 提高瞬时成功率 | 放大下游压力和尾延迟 |
| 熔断+降级 | 依赖持续故障 | 快速失败保护资源 | 阈值错误会误熔断 |
| 隔离舱 | 多依赖/租户风险不同 | 限制故障范围 | 资源碎片与配额治理 |
选型至少带上 峰值流量、数据规模、依赖容量、一致性目标和故障预算，并用上面的量化基线验证；未知数据应明确为待测假设。
设计边界与工程取舍
韧性设计目标是控制故障半径和恢复速度，不是隐藏所有错误；降级结果必须在业务语义上真实且可追踪。
工程落地遵循：先定义 SLO 与不变量，再通过限流、隔离、异步和补偿保护核心链路。回答时直接引用「Resilience4j CircuitBreaker events」、配置实验和事故数据，比复述固定模板更有说服力。