Sentinel 熔断规则 - 异常比例(order & product 示例)笔记

一 核心定义

异常比例熔断是 Sentinel 实现服务容错的核心策略,针对服务间调用异常的场景设计。

以 order(订单服务)调用 product(商品服务)的查询商品库存接口为例:

当 order 服务在指定时间范围内,调用 product 库存接口的异常请求占比达到阈值时,会立即触发熔断机制;在设定的熔断时长内,order 对该接口的所有请求都会被直接拦截,不会发送至 product 服务;熔断时长结束后,会进入试探状态判断服务是否恢复,以此避免异常服务拖垮调用方。

二 关键规则参数

配置异常比例熔断规则,必须明确以下4个核心参数,缺一不可:

1 最小请求数

触发熔断的请求基数门槛。只有当时间窗口内的总请求数达到或超过该数值,才会计算异常比例。

比如设为5,则1秒内 order 调用 product 接口的请求数不足5时,即使全部请求异常,也不会触发熔断。

2 时间窗口

统计异常请求占比的时间范围。Sentinel 会在这个时间范围内累计请求数和异常请求数,计算比例。

比如设为1秒,则每1秒会重新统计一次请求的异常情况。

3 异常比例阈值

触发熔断的临界占比,取值范围在 0.0 - 1.0 之间(如 0.5 代表 50%)。

当时间窗口内的异常请求数 ÷ 总请求数 ≥ 该阈值时,立即触发熔断。

4 熔断时长

触发熔断后拦截请求的持续时间。

比如设为30秒,则熔断触发后的30秒内,order 对 product 库存接口的请求都会被拦截。

三 完整执行流程(order → product 调用场景)

假设配置:最小请求数=5、时间窗口=1秒、异常比例阈值=0.5、熔断时长=30秒

1 正常调用阶段

order 服务持续调用 product 的库存接口,若1秒内请求数不足5,或异常请求占比低于50% → 不触发熔断,请求正常发送。

2 熔断触发阶段

某1秒内 order 发起了10次调用请求,其中6次出现异常(异常占比60% ≥ 50%),且总请求数达到了最小请求数5 → 立即触发熔断。

3 熔断拦截阶段

熔断触发后的30秒内,order 对 product 库存接口的所有请求都会被 Sentinel 拦截,不会真正发送到 product 服务,避免 product 服务在异常状态下被持续请求,减轻其压力。

4 半熔断试探阶段

30秒熔断时长结束后,进入半熔断状态:此时会放行少量请求(如1次)去调用 product 库存接口。

  • 若试探请求正常响应 → 判定 product 服务已恢复,熔断状态解除,恢复正常调用。

  • 若试探请求仍异常 → 判定服务未恢复,重新触发熔断,再次进入30秒拦截期。

四 关键补充说明

1 异常请求判定范围:Sentinel 默认将接口超时、抛出运行时异常、返回错误状态码等情况,判定为"异常请求"。

2 熔断本质:熔断是拦截请求的发送,而非禁止调用逻辑执行。order 服务仍会触发调用接口的代码逻辑,但 Sentinel 会在代码执行过程中阻断请求,不让其发送到 product 服务。

3 配置误区:不要忽略"最小请求数"参数。如果不设置该参数,少量请求的异常(比如1秒内2次请求全部异常)就会触发熔断,容易导致正常业务被误拦截

相关推荐
似水明俊德3 小时前
02-C#.Net-反射-面试题
开发语言·面试·职场和发展·c#·.net
Leinwin3 小时前
OpenClaw 多 Agent 协作框架的并发限制与企业化规避方案痛点直击
java·运维·数据库
薛定谔的悦3 小时前
MQTT通信协议业务层实现的完整开发流程
java·后端·mqtt·struts
enjoy嚣士4 小时前
springboot之Exel工具类
java·spring boot·后端·easyexcel·excel工具类
Thera7774 小时前
C++ 高性能时间轮定时器:从单例设计到 Linux timerfd 深度优化
linux·开发语言·c++
罗超驿4 小时前
独立实现双向链表_LinkedList
java·数据结构·链表·linkedlist
炘爚4 小时前
C语言(文件操作)
c语言·开发语言
阿蒙Amon4 小时前
C#常用类库-详解SerialPort
开发语言·c#
盐水冰5 小时前
【烘焙坊项目】后端搭建(12) - 订单状态定时处理,来单提醒和顾客催单
java·后端·学习
凸头5 小时前
CompletableFuture 与 Future 对比与实战示例
java·开发语言