半开状态

引言：熔断器如何"自愈"？ 在前面几篇文章中，我们学习了熔断的原理、策略和降级处理。我们知道，当依赖服务出现故障时，熔断器会开启（Open），停止对服务的调用。 但问题来了：熔断器什么时候恢复？ 如果依赖服务的故障已经修复了，熔断器还一直开启，那就失去了熔断的意义——我们不能让系统永久降级！ 另一方面，如果熔断器贸然恢复，而依赖服务还没完全恢复，可能会再次被拖垮。 Sentinel是如何优雅地解决这个两难问题的？ 答案就是：半开状态（Half-Open）。 熔断器的完整生命周期 三种状态回顾 我们在第12篇文章中学习过，熔断器有三种状态： 关闭（Closed）：正常状态，所有请求通过 开启（Open）：熔断状态，所有请求快速失败 半开（Half-Open）：探测状态，试探性地发送请求 状态转换流程 初始状态：Closed（关闭） ↓ 检测到故障（慢调用/异常超过阈值） ↓ Closed → Open（开启） ↓ 等待熔断时长（如10秒） ↓ Open → Half-Open（半开） ↓ 发送探测请求 ↓ 探测请求成功？ ├─ 是 → Half-Open → Closed（恢复正常） └─ 否 → Half-Open → Open（继续熔断） 关键点： 熔断器开启后，不会永久熔断 等待一段时间（timeWindow），自动进入半开状态 在半开状态下，只允许一个探测请求通过 根据探测请求的结果，决定是恢复还是继续熔断 半开状态的作用 为什么需要半开状态？ 问题1：如果没有半开状态，熔断器开启后永不恢复 结果：服务永久降级，即使依赖服务已经恢复 问题2：如果熔断器直接恢复（Open → Closed） 结果：大量请求涌入，可能再次拖垮刚恢复的服务 半开状态的作用： 用一个探测请求试探依赖服务是否恢复，避免大量请求直接涌入。 就像"壮士试毒"——先派一个人尝试，安全了大家再上。 半开状态的特点 只允许一个请求通过：Sentinel会选择一个请求作为探测请求 其他请求快速失败：在探测期间，其他请求继续降级 快速决策：根据这一个请求的结果，立即决定后续策略 半开状态的触发条件 触发时机 半开状态的触发非常简单：熔断时长到期。 配置参数： DegradeRule rule = new DegradeRule(); rule.setResource("callRemoteService"); rule.setGrade(RuleConstant.DEGRADE_GRADE_RT); rule.setCount(1000); rule.setSlowRatioThreshold(0.5); rule.setTimeWindow(10); // ← 熔断时长：10秒 工作流程： ...