目录
一、 流量控制规则（Flow Rule）
1. 核心作用
2. 核心配置项（关键）
3. 常见使用场景
4. 实操示例（控制台配置）
二、 熔断降级规则（Degrade Rule）
1. 核心作用
2. 核心配置项（关键）
3. 三种熔断策略详解
（1） 平均响应时间（RT）熔断
（2） 异常比例熔断
（3） 异常数熔断
4. 熔断状态流转
5. 实操场景
三、 热点参数规则（Param Flow Rule）
1. 核心作用
2. 核心配置项（关键）
3. 核心特性
4. 实操示例
（1） 改造方法
（2） 配置热点规则
（3） 测试
5. 适用场景
四、 其他补充规则
1. 系统规则（System Rule）
2. 授权规则（Authority Rule）
五、 各类规则核心差异与适用场景总结
总结
Sentinel 的所有规则都遵循「按需配置、动态生效」的原则，支持通过代码、配置文件、Sentinel 控制台三种方式配置，且控制台配置可实时推送无需重启应用。
一、 流量控制规则（Flow Rule）
1. 核心作用
限制资源的访问流量，避免瞬时高流量压垮系统，保障系统的吞吐量和稳定性。核心思想是「削峰填谷」，比如限制接口每秒最多接收 100 次请求。
2. 核心配置项（关键）
| resource | 受保护的资源名（与 @SentinelResource 的 value 对应） | helloResource |
| grade | 限流阈值类型 | ① FLOW_GRADE_QPS（默认）：按 QPS 限流（每秒请求数）② FLOW_GRADE_THREAD：按线程数限流（同时处理该资源的线程数） |
| count | 限流阈值 | 如 QPS 阈值 = 10，线程数阈值 = 20 |
| strategy | 流控策略（针对资源本身 / 关联资源 / 链路） | ① DIRECT（默认）：直接限流当前资源② ASSOCIATE：关联限流（关联资源触发阈值，限流当前资源）③ CHAIN：链路限流（只限制指定链路进入该资源的流量） |
| controlBehavior | 流量控制效果（超出阈值后的处理方式） | ① DIRECT_REJECT（默认）：直接拒绝（返回 BlockException）② WARM_UP：预热模式（阈值从低到高渐变，适用于突发流量）③ RATE_LIMITER：匀速排队（请求按固定速率通过，适用于秒杀等场景）④ WARM_UP_RATE_LIMITER：预热 + 匀速排队 |
| limitApp | 限制调用来源（默认不限制） | default（所有来源）、具体服务名（如 service-a） |
3. 常见使用场景
- QPS 限流：普通接口防刷，比如用户注册接口限制 QPS=50，避免恶意批量注册。
- 线程数限流：针对耗时较长的接口（如查询数据库报表），限制同时处理的线程数 = 10，避免线程池耗尽。
- 预热模式：针对缓存重建、服务启动场景，比如限流阈值 = 100，预热时间 = 5 秒，阈值会从 50（100/2）渐变到 100，避免瞬间打满资源。
- 匀速排队：秒杀接口，限制 QPS=10，排队超时时间 = 500ms，让请求按 100ms / 个的速率通过，避免系统被突发流量冲垮。
4. 实操示例（控制台配置）
二、 熔断降级规则（Degrade Rule）
1. 核心作用
当资源出现异常（如调用超时、报错率高）时，暂时切断该资源的调用链路，避免异常扩散导致整个系统雪崩，同时给资源留出恢复时间。
区别于流控：流控是「防患于未然」，限制正常流量；熔断是「亡羊补牢」，处理已出现异常的资源。
2. 核心配置项（关键）
| resource | 受保护的资源名 | helloResource |
| grade | 熔断降级策略（判断资源是否异常的依据） | ① DEGRADE_GRADE_RT（平均响应时间）② DEGRADE_GRADE_EXCEPTION_RATIO（异常比例）③ DEGRADE_GRADE_EXCEPTION_COUNT（异常数） |
| count | 熔断阈值 | ① 平均响应时间：如 500（ms）② 异常比例：如 0.5（50%）③ 异常数：如 10（次） |
| timeWindow | 熔断窗口时间（单位：秒） | 如 10（熔断后，10 秒内不再调用该资源，10 秒后尝试半开状态） |
| minRequestAmount | 最小请求数（触发熔断的前提：统计时间内请求数≥该值，默认 5） | 如 10（每秒至少 10 次请求，才会判断是否熔断） |
| statIntervalMs | 统计时间窗口（单位：毫秒，默认 1000ms=1 秒） | 如 2000（每 2 秒统计一次异常数据） |
3. 三种熔断策略详解
（1） 平均响应时间（RT）熔断
- 逻辑：统计时间内，资源的平均响应时间 ≥ count，且请求数 ≥ minRequestAmount，触发熔断。
- 示例：配置 grade=RT、count=500、timeWindow=10、minRequestAmount=10。含义：1 秒内，helloResource 的请求数≥10，且平均响应时间≥500ms，触发熔断，10 秒内不再调用该资源。
- 场景：针对耗时接口（如调用第三方支付接口），避免慢请求拖垮系统。
（2） 异常比例熔断
- 逻辑：统计时间内，资源的异常请求比例 ≥ count（0~1 之间），且请求数 ≥ minRequestAmount，触发熔断。
- 示例：配置 grade=EXCEPTION_RATIO、count=0.5、timeWindow=10、minRequestAmount=10。含义：1 秒内，helloResource 的请求数≥10，且异常率≥50%，触发熔断，10 秒内不再调用该资源。
- 场景：针对接口报错率高的场景（如数据库连接失败、第三方接口返回异常）。
（3） 异常数熔断
- 逻辑：统计时间内，资源的异常请求数 ≥ count，且请求数 ≥ minRequestAmount，触发熔断。
- 示例：配置 grade=EXCEPTION_COUNT、count=10、timeWindow=10、minRequestAmount=20。含义：1 秒内，helloResource 的请求数≥20，且异常数≥10，触发熔断，10 秒内不再调用该资源。
- 场景：针对异常数容易统计的场景（如批量处理接口，允许最多 10 次异常）。
4. 熔断状态流转
Sentinel 熔断遵循「闭合→打开→半开」的状态机：
- 若尝试请求成功（无异常、响应时间正常），则恢复为闭合状态。
- 若尝试请求失败，重新进入打开状态，重置 timeWindow。
5. 实操场景
配置一个异常比例熔断规则：
三、 热点参数规则（Param Flow Rule）
1. 核心作用
针对资源的「热点参数」进行精细化限流，即对资源中某个频繁使用的参数（如用户 ID、商品 ID）进行单独限流，而不是对整个资源限流。
热点：指访问频率高的参数，比如秒杀接口的 goodsId，大部分请求都集中在少数几个商品 ID 上。
2. 核心配置项（关键）
| resource | 受保护的资源名 | helloResource |
| paramIdx | 热点参数索引（方法参数列表的下标，从 0 开始） | 如方法 hello(String name, Integer age)，name 是索引 0，age 是索引 1 |
| grade | 限流阈值类型（同流控） | FLOW_GRADE_QPS（默认）、FLOW_GRADE_THREAD |
| count | 默认限流阈值（该参数的所有值都适用的基础阈值） | 如 QPS 阈值 = 10 |
| paramFlowItemList | 参数例外项（针对特定参数值单独配置阈值，优先级高于默认阈值） | 如商品 ID=1001，阈值 = 100；其他商品 ID，阈值 = 10 |
| durationInSec | 统计时间窗口（单位：秒，默认 1） | 1（每秒统计一次） |
| controlBehavior | 流控效果（同流控，仅支持直接拒绝和匀速排队） | DIRECT_REJECT（默认） |
3. 核心特性
4. 实操示例
给 hello 方法的 name 参数（索引 0）配置热点规则：
（1） 改造方法
@GetMapping("/hello")
@SentinelResource(value = "helloResource", blockHandler = "helloBlockHandler")
public String hello(@RequestParam(required = false, defaultValue = "guest") String name) {
return "Hello, " + name + "!";
}
// 注意：blockHandler 方法需保留热点参数，且添加 BlockException
public String helloBlockHandler(String name, BlockException e) {
System.err.println("热点参数限流触发，参数：" + name);
return "抱歉，该参数访问过于频繁，请稍后再试！";
}
（2） 配置热点规则
（3） 测试
- 访问 http://localhost:8080/hello?name=guest，快速访问≥5 次 / 秒，触发限流。
- 访问 http://localhost:8080/hello?name=test，快速访问≤20 次 / 秒，不会触发限流，超过 20 次才会限流。
5. 适用场景
- 秒杀接口：对热门商品 ID 配置更高的限流阈值，普通商品 ID 配置较低阈值。
- 用户中心：对 VIP 用户 ID 配置更高的接口访问阈值，普通用户配置较低阈值。
四、 其他补充规则
1. 系统规则（System Rule）
- 核心作用：针对整个应用的系统级指标进行限流，而非单个资源，保障应用整体稳定性。
- 监控指标：① load：系统负载（仅支持 Linux/Unix 系统）。② cpuUsage：CPU 使用率。③ memoryUsage：内存使用率。④ qps：应用整体 QPS。⑤ threadCount：应用整体线程数。
- 场景：当应用 CPU 使用率≥80% 时，触发系统限流，拒绝所有新请求，避免应用宕机。
2. 授权规则（Authority Rule）
- 核心作用：对资源的调用来源进行黑白名单控制，即允许 / 拒绝某个服务 / 应用调用该资源。
- 配置项：resource（资源名）、strategy（授权策略：黑白名单）、limitApp（允许 / 拒绝的应用名列表，多个用逗号分隔）。
- 场景：保护内部接口，只允许内部服务 service-admin 调用，拒绝外部服务调用。
五、 各类规则核心差异与适用场景总结
| 流量控制 | 限制资源的整体访问流量 | 普通接口防刷、避免瞬时高流量 | 针对「资源整体」，粗粒度控制 |
| 熔断降级 | 处理异常资源，避免雪崩 | 耗时接口、第三方接口、报错率高的接口 | 针对「异常资源」，有状态流转 |
| 热点参数 | 精细化控制资源的热点参数 | 秒杀接口、商品查询接口（针对特定参数值） | 针对「资源参数」，细粒度控制 |
| 系统规则 | 保障应用整体稳定性 | 应用负载过高、CPU / 内存使用率过高 | 针对「整个应用」，全局控制 |
| 授权规则 | 控制资源的调用来源 | 内部接口保护、白名单访问 | 针对「调用方」，身份验证 |
