title: 熔断阈值写成 0.5健康的支付链路被自己掐死Sentinel 滑动窗口的 5 个格子怎么算topic: 微服务熔断降级Sentinel 滑动窗口算法batch: 5round: 3半年前一次压测我们把一个下游支付服务的熔断阈值errorRatioThreshold设成了 0.5本意是「错误率过半就熔断保护」。结果压测刚起来 20 秒整条支付链路直接熔断订单全部走降级——可下游监控显示它的错误率只有 3%。我们一边重启一边查最后发现是我们把「滑动窗口」理解成了「固定时间窗」阈值在窗口切换的瞬间被一两个慢请求顶爆了。这篇文章用那次误杀讲清楚 Sentinel 的滑动窗口到底怎么统计以及熔断规则里几个常被拍脑袋定的参数真实代价是什么。事故现场一个被误读的熔断规则PostConstruct public void initRule() { ListDegradeRule rules new ArrayList(); DegradeRule rule new DegradeRule(); rule.setResource(payService); rule.setGrade(RuleConstant.DEGRADE_GRADE_EXCEPTION_RATIO); // 按异常比例熔断 rule.setCount(0.5); // 异常比例阈值 50% rule.setTimeWindow(10); // 熔断 10 秒 rule.setStatIntervalMs(1000); // 统计窗口 1 秒 rule.setMinRequestAmount(5); // 窗口内最少 5 个请求才统计 rules.add(rule); DegradeRuleManager.loadRules(rules); }逐行解释这段配置为什么危险- 第 6 行DEGRADE_GRADE_EXCEPTION_RATIO表示按「异常比例」判断不是异常数。- 第 7 行setCount(0.5)阈值 50% 看着宽松但配合第 9 行setStatIntervalMs(1000)的 1 秒小窗口一个 1 秒的窗口里只要 5 个请求里挂了 3 个比例就到 60%立刻熔断。- 第 10 行setMinRequestAmount(5)最少 5 个请求才生效压测瞬间流量打满1 秒内轻松超过 5 个于是阈值很容易被短暂抖动触发。- 真正的问题在第 9 行1 秒窗口太短偶发的下游 GC 停顿造成的一两个超时就能把比例瞬间顶过线。Sentinel 怎么统计滑动窗口的 5 个格子Sentinel 的「滑动窗口」不是把时间切成不重叠的块而是把statIntervalMs切成若干个windowLength的小格子默认约 2 个但慢调用场景会细分只统计「当前时间戳所在格子 前面还没过期的格子」。// 简化自 Sentinel ArrayMetric#currentWindow核心是用数组环形复用格子 public WindowWrapMetricBucket currentWindow(long timeMillis) { long timeId timeMillis / windowLengthInMs; // 当前属于第几个格子 int idx (int) (timeId % array.length); // 环形数组取下标复用旧格子 WindowWrapWindow old array[idx]; if (old null) { array[idx] new WindowWrap(windowLengthInMs, timeId, new MetricBucket()); return array[idx]; } if (old.windowStart windowLengthInMs timeMillis) { // 格子已过期CAS 重置后复用避免每次 new 对象 array[idx] new WindowWrap(windowLengthInMs, timeId, new MetricBucket()); return array[idx]; } return old; // 还在当前窗口内累加数据 }逐行解释- 第 3 行timeMillis / windowLengthInMs算出当前时间落在第几个格子这是滑动的基础——格子按时间推进不是固定从 0 开始。- 第 4 行timeId % array.length用取模把格子映射到固定长度的环形数组格子过期后原地复用不频繁创建对象这也是 Sentinel 高并发下统计开销低的原因。- 第 9 行「格子过期判断」如果当前时间已经超出了这个格子原本的窗口起点就 CAS 重置它。这一步保证统计的是「最近一个统计周期」旧数据自然滑出。- 第 14 行直接返回old表示还在当前窗口把这次请求的 pass/block/exception 计数累加进去。关键点在于熔断判断读的是「最近一个完整统计周期statIntervalMs里所有未过期格子的汇总」所以窗口边界上的一两个异常会被前后格子的正常请求摊薄——前提是你的statIntervalMs别设太短。我们那次就是 1 秒太短抖动没被摊薄。滑动窗口 vs 固定计数器差在哪维度固定时间窗如 Hystrix 旧版思路Sentinel 滑动窗口边界突变窗口切换瞬间计数归零易误判格子随时间滑动平滑过渡突发容忍差边界两请求可双倍计数较好过期格子滑出统计精度粗细可到毫秒级格子说「滑动窗口比计数器好」不准确——它好在边界平滑但代价是你要理解statIntervalMs和格子的关系否则照样误杀。实战用 SentinelResource 兜底并让参数一起生效光配规则不够熔断触发后你得告诉调用方「降级走哪」否则抛个 DegradeException 直接 500反而把故障面撑大。Service public class PayService { // blockHandler 指定熔断/限流时的兜底方法方法签名要和原方法一致且多一个 BlockException 参数 SentinelResource(value payService, blockHandler payFallback) public String pay(long userId, int amount) { return downstreamClient.doPay(userId, amount); } // 兜底方法返回降级结果绝不直接抛异常中断主流程 public String payFallback(long userId, int amount, BlockException e) { log.warn(pay blocked, uid{}, reason{}, userId, e.getClass().getSimpleName()); return DEGRADED; // 上游拿到降级标记走异步重试或排队 } }逐行解释- 第 3 行SentinelResource(valuepayService, blockHandlerpayFallback)把资源名和兜底方法绑起来熔断或限流触发时走payFallback而不是抛异常。- 第 9 行兜底方法签名必须和原方法一致且多一个BlockException参数Sentinel 靠这个签名找到它。- 第 11 行返回DEGRADED而不是抛异常让上游能优雅降级——否则熔断瞬间一堆 500把故障面反而撑大。除了 fallback那次误杀之后我们把「几个参数当成一组」来调而不是单改阈值statIntervalMs从 1000 调到 5000。窗口拉长到 5 秒偶发的下游 GC 停顿造成的一两个超时会被前后 5 秒的正常请求摊薄比例不再瞬间顶过线。代价是熔断响应变慢——极端情况下最坏晚 5 秒才熔断对这个支付链路可接受。minRequestAmount从 5 调到 20。低流量时比如凌晨单实例每秒不到 5 个请求几个异常就把比例顶到 50%纯属噪声设成 20 相当于「窗口内至少 20 个请求才统计」过滤掉低流量抖动。errorRatioThreshold从 0.5 调到 0.6。50% 在我们的流量下太敏感60% 给正常毛刺留了余量又不至于真故障时反应迟钝。timeWindow维持 10 秒。熔断 10 秒后自动半开探测下游恢复就能很快放量。这组参数我们压测了 3 轮才定下来第一轮只改阈值还是误杀第二轮拉长窗口误杀没了但偶发故障恢复慢第三轮把 minRequestAmount 和阈值一起调才同时压住「误杀」和「反应慢」两头。复盘那次误杀的真实代价熔断持续 10 秒timeWindow压测期间触发了 4 次累计支付链路不可用约 40 秒订单降级走人工多花了 2 人时的排查。下游那个「3% 错误率」其实是压测机到支付服务的网络抖动不是服务真挂了。我们后来把statIntervalMs调到 50005 秒minRequestAmount提到 20阈值改成 0.6同样的压测再没误杀。我们还发现一个连带问题熔断期间抛出的DegradeException没被上层统一处理前端收到 500 后无脑重试重试又打进正在熔断的服务形成「熔断 → 重试 → 更堵」的二次放大。加上blockHandler兜底返回DEGRADED、前端按标记走排队而非重试后这个放大环才断掉。另一个教训是监控我们之前只在 Grafana 看「熔断触发次数」总量没按资源名细分导致前 3 次误杀都以为是下游真挂了。后来按resource维度拆监控才看清是payService自己的阈值在抖而不是下游。我的取舍阈值别拍脑袋我的习惯是熔断阈值和窗口一定要按「你能接受多少误杀、下游抖动多大」反推而不是直接抄文档的默认值。statIntervalMs我一般设在 5-10 秒让短暂抖动被摊薄minRequestAmount设成日常 QPS 在窗口内的 1-2 倍避免低流量时几个异常就熔断。exceptionRatio 比 exception count 更安全因为它考虑了流量基数——但基数太小请求数低于 minRequestAmount时比例毫无意义所以这两个参数必须一起调。另外提醒一句熔断开之后一定要有blockHandler兜底否则上层拿不到降级信号、只能看到异常很容易引发重试风暴把故障放大。熔断保护的是下游兜底保护的是你自己这条链路——这两件事少一个熔断的价值就折半。思考题如果你的下游每天有两次定时任务会卡 2 秒批处理你的熔断规则该怎么设才能既不误杀、又能在下游真挂时及时熔断 
