Sentinel 与 Resilience4j 熔断限流原理有何不同？如何选型？
结论先行：两者都做“流量防护”，理念不同：Sentinel 是规则驱动 + 中心化管理的流量治理组件，重限流（QPS/并发线程/热点）与熔断降级，配有可视化控制台、规则可推送持久化；Resilience4j 是轻量进程内容错库，以装饰器组合出熔断、限流、隔离、重试、超时，无控制台、规则靠代码/配置。中文互联网微服务多用 Sentinel；追求轻量、与函数式/响应式风格一致选 Resilience4j。
一、核心能力对比
| 维度 | Sentinel | Resilience4j |
|---|---|---|
| 模型 | 资源 + 规则 + Slot 责任链 | CircuitBreaker/RateLimiter/Bulkhead 等模块 |
| 限流 | QPS、并发线程、热点参数、系统自适应 | RateLimiter（令牌） |
| 熔断 | 慢调用/异常比例/异常数 | 状态机 CLOSED→OPEN→HALF_OPEN |
| 隔离 | 信号量/线程池（结合） | Bulkhead（信号量/线程池） |
| 重试/超时 | 少内置 | Retry、TimeLimiter 原生 |
| 控制台 | Sentinel Dashboard + 规则推送 | 无，指标对接 Prometheus/Grafana |
| 侵入 | @SentinelResource + 规则中心 | 注解/装饰器，规则在代码或配置 |
二、Sentinel 关键原理
- 资源定义：埋点（SphU.entry 或 @SentinelResource(value="getOrder")）；
- 规则：流控规则（grade=QPS/并发线程、控制行为=快速失败/预热/排队）、熔断降级规则（慢调用比例/异常比例/异常数 + 时间窗口）；
- 责任链：NodeSelector→ClusterBuilder→StatisticSlot（统计）→AuthoritySlot（黑白名单）→SystemSlot（系统自适应）→FlowSlot（流控）→DegradeSlot（熔断降级）逐个裁决；
- 统计滑动窗口：以时间为单位的滑动窗口计数 QPS/异常，支持秒级实时；
- 规则持久化：控制台/API 推送到客户端内存，配合 Nacos 等做规则数据源持久化。
@SentinelResource(value = "createOrder",
blockHandler = "createOrderBlock", // 限流/熔断触发
fallback = "createOrderFallback") // 业务异常兜底
public Order createOrder(OrderReq req) { ... }
三、Resilience4j 关键原理
- CircuitBreaker 状态机：关闭(CLOSED)→超过阈值打开(OPEN)→等待窗口后半开(HALF_OPEN)试放少量请求→成功回 CLOSED、失败回 OPEN；
- 指标基于滑动窗口（计数/时间）统计失败率、慢调用率；
- 组合使用：TimeLimiter + CircuitBreaker + Retry + RateLimiter + Bulkhead 装饰同一调用，构成弹性调用链；
- Spring Cloud 集成：spring-cloud-starter-circuitbreaker-resilience4j + @CircuitBreaker(name, fallbackMethod)。
常见追问 / 记忆点
- 追问：熔断和限流解决什么问题？答：熔断防“下游故障拖垮自己”，限流防“自身过载拖垮整个系统”，降级是两者触发后的兜底响应。
- 追问：两套都见过怎么判断该信哪个？答：看是否有规则中心/控制台诉求——要治理平台选 Sentinel，要轻内嵌选 Resilience4j。
- 记忆点：Sentinel 中心化治理、Resilience4j 进程内组合；状态机三态与滑动窗口是熔断通用底座。