以下内容来自于Sentinel 的熔断降级（Degrade）机制，主要包括：
DegradeRule：熔断规则的定义- 两个
onRequestComplete()方法（分别对应慢调用比例和异常比例/计数两种熔断策略） - 熔断状态机（CLOSE → OPEN → HALF_OPEN → CLOSE）的触发逻辑
下面我将系统性地解释这些内容，帮助你深入理解 Sentinel 的熔断机制是如何工作的。
🔍 一、DegradeRule：熔断规则的核心配置
publicclassDegradeRuleextendsAbstractRule{privateintgrade;// 熔断策略类型privatedoublecount;// 阈值（含义取决于 grade）privateinttimeWindow;// 熔断后恢复时间（秒）privateintminRequestAmount;// 最小请求数（防止统计噪声）privatedoubleslowRatioThreshold;// 慢请求比例阈值（仅 RT 模式）privateintstatIntervalMs;// 统计窗口长度（毫秒，默认 1000ms）}✅ 三种熔断策略（grade）
| 值 | 常量 | 含义 | count的含义 |
|---|---|---|---|
| 0 | DEGRADE_GRADE_RT | 平均响应时间（RT） | 最大允许 RT（毫秒） |
| 1 | DEGRADE_GRADE_EXCEPTION_RATIO | 异常比例 | 异常比例阈值（0.0 ~ 1.0） |
| 2 | DEGRADE_GRADE_EXCEPTION_COUNT | 异常数量 | 每秒异常数阈值 |
📌 注意：从 Sentinel 1.8 开始，RT 模式不再看“平均 RT”，而是看“慢请求比例”！
🧠 二、RT 模式（慢调用比例）的工作原理
📄 规则说明（来自你的注释）：
当接下来的 5 个请求的 RT 都超过阈值，才触发熔断。
但这是旧版逻辑（1.7 及之前）。
1.8+ 版本已改为基于滑动窗口的“慢请求比例”判断，更科学。
🔁 新逻辑（1.8+）关键参数：
count：最大允许 RT（比如 200ms）slowRatioThreshold：慢请求比例阈值（比如 0.5 = 50%）minRequestAmount：最小请求数（比如 5），低于此数不触发熔断statIntervalMs：统计窗口（默认 1000ms）
📊onRequestComplete()（RT 模式）做了什么？
publicvoidonRequestComplete(Contextcontext){longrt=completeTime-createTimestamp;if(rt>maxAllowedRt){counter.slowCount.add(1);// 记录慢请求}counter.totalCount.add(1);// 总请求数 +1handleStateChangeWhenThresholdExceeded(rt);}handleStateChangeWhenThresholdExceeded()核心逻辑：
- 如果当前是 OPEN 或 HALF_OPEN：只处理探测请求（见下文）
- 否则（CLOSE 状态）：
- 从滑动窗口中汇总：
slowCount和totalCount - 如果
totalCount < minRequestAmount→ 不判断（数据不足） - 计算慢请求比例：
currentRatio = slowCount / totalCount - 如果
currentRatio > slowRatioThreshold→触发熔断（OPEN）
- 从滑动窗口中汇总：
✅ 举例：
count = 200（RT > 200ms 算慢）slowRatioThreshold = 0.6- 过去 1 秒内有 10 个请求，其中 7 个 RT > 200ms → 比例 70% > 60% →熔断！
⚠️ 三、异常模式（异常比例 / 异常数）的工作原理
onRequestComplete()（异常模式）：
publicvoidonRequestComplete(Contextcontext){Throwableerror=entry.getError();// 通过 Tracer.trace(ex) 标记的异常if(error!=null){counter.errorCount.add(1);}counter.totalCount.add(1);handleStateChangeWhenThresholdExceeded(error);}判断逻辑：
doublecurCount=errCount;if(strategy==EXCEPTION_RATIO){curCount=errCount*1.0/totalCount;// 转为比例}if(curCount>threshold){transformToOpen(curCount);}✅ 举例（异常比例）：
count = 0.5（50% 异常率）- 1 秒内 10 个请求，5 个抛异常 → 比例 50% ≥ 阈值 →熔断！
✅ 举例（异常数）：
count = 5（每秒 5 个异常）- 1 秒内 6 个异常 →熔断！
🔁 四、熔断状态机（State Machine）
Sentinel 的熔断器有三种状态：
| 状态 | 行为 |
|---|---|
| CLOSE | 正常放行请求，统计 RT/异常 |
| OPEN | 直接拒绝所有请求（抛DegradeException），不执行业务 |
| HALF_OPEN | 放行一个探测请求，根据结果决定是否恢复 |
🔄 状态转换逻辑
1.CLOSE → OPEN
- 满足熔断条件（慢比例/异常比例超标）
- 调用
transformToOpen() - 启动定时任务：
timeWindow秒后自动切换到HALF_OPEN
2.OPEN → HALF_OPEN
- 由后台定时任务触发（非请求驱动）
3.HALF_OPEN → ?
- 放行下一个请求作为探测：
- 成功（无异常 & RT 正常）→
fromHalfOpenToClose()→ 恢复 - 失败（异常 or 慢）→
fromHalfOpenToOpen()→ 再次熔断
- 成功（无异常 & RT 正常）→
💡 注意：目前 Sentinel 的 HALF_OPEN 只探测一个请求，不是多个。
🧩 五、关键设计思想总结
| 特性 | 说明 |
|---|---|
| 基于滑动窗口统计 | 使用LeapArray实现高精度、低内存的实时统计 |
| 防误判机制 | minRequestAmount避免低流量时因个别慢请求误熔断 |
| 快速失败 | OPEN 状态下直接拒绝，不消耗资源 |
| 自动恢复 | timeWindow后自动尝试恢复（HALF_OPEN） |
| 策略灵活 | 支持 RT、异常比例、异常数三种主流熔断场景 |
📌 六、使用建议
RT 模式：
- 设置合理的
slowRatioThreshold（如 0.5） minRequestAmount至少设为 5~10timeWindow建议 5~30 秒（避免频繁震荡）
- 设置合理的
异常模式：
- 确保业务代码中通过
Tracer.trace(ex)上报异常 - 异常比例适合稳定流量场景；异常数适合突发流量
- 确保业务代码中通过
监控：
- 观察
metric.log中的 RT 和异常统计 - 结合 Dashboard 查看熔断状态变化
- 观察
✅ 举个完整例子
// 配置：当 /order 接口慢请求比例 > 60%，且最小请求数 >= 10，熔断 10 秒DegradeRulerule=newDegradeRule("GET:/order").setGrade(RuleConstant.DEGRADE_GRADE_RT).setCount(300)// RT > 300ms 算慢.setSlowRatioThreshold(0.6)// 慢请求比例 > 60%.setMinRequestAmount(10).setTimeWindow(10);// 熔断 10 秒DegradeRuleManager.loadRules(Collections.singletonList(rule));❓常见问题
Q：为什么我的熔断没触发？
A：检查：
- 是否达到
minRequestAmount - 是否真的有慢请求/异常（通过
Tracer.trace()上报） statIntervalMs是否太短（默认 1s，一般不用改）
Q：HALF_OPEN 为什么只试一次？
A：Sentinel 设计如此，简化实现。如需更健壮，可自行扩展CircuitBreaker。
✅ 总结
你看到的代码体现了 Sentinel现代熔断器的核心思想：
“基于实时指标 + 滑动窗口 + 状态机” 实现自适应熔断
它不再是简单的“连续 N 次失败就熔断”，而是：
- 更精准（比例 vs 绝对次数）
- 更稳定（防抖：minRequestAmount）
- 更智能（自动探测恢复）
理解这些，你就能合理配置熔断规则，并在系统出现不稳定时快速定位问题。
