第4章 服务容错与高可用设计：熔断降级、限流、超时重试、隔离策略
本章定位：微服务面试中“容错设计”是必考高频区，面试官通过你的方案判断对分布式韧性、流量治理、故障隔离的理解深度。核心四招：熔断降级、限流、超时重试、隔离策略。本章提供结构化回答框架 + 真实项目模板，助你应对从原理到实战的所有追问。
常规面试问答
Q1：你们系统如何实现熔断降级？请详细说明设计思路。
面试官考察点：是否理解熔断状态机（Closed/Open/Half-Open）、降级兜底与业务损失之间的平衡。
回答框架：① 基于异常比例或慢调用比例触发熔断 → ② 使用Hystrix/Sentinel维护三种状态 → ③ 设置滑动窗口统计指标 → ④ 降级返回缓存/提示/默认值 → ⑤ 定时探测恢复。
示例回答：“我们使用Sentinel，按错误率>50%或RT>500ms触发熔断。熔断后直接返回兜底数据（如商品库存缓存），每5秒允许一个请求探测恢复。核心是降级数据必须提前准备好，避免雪崩。”
可能追问：熔断恢复后如何平滑？降级数据一致性怎么保证？
Q2：如何设计限流策略？请结合具体业务说明。
面试官考察点：限流算法选型（令牌桶/漏桶/滑动窗口）、粒度（接口/用户/集群）、动态调优能力。
回答框架：① 分析业务流量特征（突发/均匀）→ ② 选择令牌桶（允许突发）或漏桶（平滑） → ③ 按API维度配置阈值 → ④ 结合热点参数限流 → ⑤ 设置限流后降级行为。
示例回答：“我们的秒杀接口使用令牌桶，QPS上限1万，突发倍数2。利用Sentinel热点规则对userId限流，防止刷单。超出后直接返回‘排队中’提示，避免击穿数据库。”
可能追问：流量从1万突增到10万怎么办？限流数据在分布式下如何同步？
Q3：超时重试和隔离策略如何配合使用？
面试官考察点：是否掌握超时设置原则、重试幂等性要求、线程池隔离与信号量隔离的适用场景。
回答框架：① 设置合理超时（比P99晚20%）② 重试必须幂等且最多1-2次 ③ 隔离方式选型：线程池隔离（高依赖）、信号量隔离（低延迟）④ 重试与熔断联动，避免重试击穿。
示例回答：“对下游RPC设置300ms超时，重试1次。使用线程池隔离核心链路，信号量隔离非关键调用。重试前检查熔断状态，若已Open则直接降级。确保重试接口幂等，如订单查询使用唯一流水号。”
可能追问：重试可能放大流量，如何控制？隔离线程池如何配置大小？
项目案例实战模板
📁 项目名称：电商核心下单链路容错与高可用改造
| 业务背景 | 618/双11大促，下单流量瞬间暴涨到平时100倍，依赖的库存、订单、积分服务频繁超时，出现雪崩风险。 |
| 规模指标 | 峰值QPS 10万+，机器约200台，下游20+微服务，核心链路RT要求<200ms。 |
| 技术栈 | Spring Boot / Cloud、Sentinel、Nacos、Redis、MySQL、Kafka（异步削峰） |
| 核心难点 | ① 熔断阈值难设定（不同接口SLA不同）② 限流与重试互相放大流量 ③ 隔离资源分配不当导致核心线程池饥饿 |
| 面试高频追问 | · 熔断恢复时如何防止雪崩再次出现？ · 动态限流如何根据系统负载自动调整？ · 隔离线程池大小怎么算（按IO密集型）？ · 重试超过1次怎么办？ |
| 可迁移回答话术 | “我们采用按业务优先级降级：非核心功能（如库存预告）直接熔断，核心下单保持。所有降级结果提前预热至Redis。重试必须与熔断状态联动，且写接口不做重试。隔离线程池根据下游线程数+PDD配置，保留30%缓冲。” |
💡 加分技巧：面试时主动说出“我们使用Sentinel的SlidingWindow统计，并自定义了渐进式降级策略（先限流10%再熔断）”，远超“用了Sentinel”的简单回答。