Sentinel 是什么？和 Hystrix、Resilience4j 有什么区别？限流和熔断怎么实现？

简化版

Sentinel（阿里开源）是一个流量治理组件——以「流量控制（限流）」为核心，同时提供熔断降级、热点参数限流、系统自适应保护，是 Spring Cloud Alibaba 里替代 Hystrix 的组件。它和 Hystrix、Resilience4j 的定位差异：Hystrix 以「熔断 + 线程隔离」为核心（已停更）；Resilience4j 是轻量的熔断/限流函数库；Sentinel 更全面，以「限流」见长，还有热点限流、系统保护、实时监控控制台、规则动态推送。核心能力：限流（控制 QPS/并发数，用滑动窗口统计）、熔断降级（依赖出错/慢调用比例超阈值就熔断）、热点参数限流（对某个参数的高频值单独限流）、系统自适应保护（按 Load/CPU 自动限流）。它有可视化控制台，规则可动态配置、实时生效。

详细版

Sentinel 的核心能力：

能力	作用
流量控制（限流）	限制资源的 QPS 或并发线程数，超了就拒绝/排队
熔断降级	依赖的慢调用比例/异常比例超阈值 → 熔断一段时间
热点参数限流	针对某个参数的特定值限流（如某个热门商品 ID）
系统自适应保护	根据系统 Load、CPU、RT 等指标自动限流，保护系统不被压垮
实时监控 + 控制台	可视化查看流量、配置规则、规则动态推送生效

Sentinel vs Hystrix vs Resilience4j：

维度	Hystrix	Resilience4j	Sentinel
核心	熔断 + 线程隔离	轻量熔断/限流函数库	流量控制（限流）为核心，功能全面
限流	弱	有（RateLimiter）	强（多维度流控）
熔断	有	有	有（慢调用比例/异常比例/异常数）
热点限流	无	无	有
系统自适应	无	无	有
控制台	Hystrix Dashboard	无	功能丰富的控制台
规则动态推送	弱	无	有（配合 Nacos 等）
维护状态	已停更	活跃	活跃（阿里）

基本用法：

// 定义资源 + 限流/降级
@SentinelResource(value = "getUser", blockHandler = "handleBlock", fallback = "handleFallback")
public User getUser(Long id) {
    return userService.getById(id);
}
// blockHandler：被限流/熔断时的处理（BlockException）
public User handleBlock(Long id, BlockException ex) { return User.DEFAULT; }
// fallback：业务异常时的降级
public User handleFallback(Long id, Throwable ex) { return User.DEFAULT; }

⚠️ Sentinel 区分两种「兜底」：blockHandler（限流/熔断触发时的处理，捕获 BlockException） 和 fallback（业务方法自身抛异常时的降级，捕获业务异常）——两者场景不同：blockHandler 是「被 Sentinel 规则拦截」，fallback 是「业务本身出错」。别搞混——被限流走 blockHandler，业务报错走 fallback（如果都配了，BlockException 优先走 blockHandler）。

完整版教学

一、Sentinel 的定位：以「限流」为核心的流量治理

要理解 Sentinel，先看它和 Hystrix 的定位差异。Hystrix 的核心是「熔断 + 线程隔离」（防止某个依赖故障拖垮整个服务），而 Sentinel 的核心是「流量控制（限流）」（控制进入系统的流量，防止系统被过载压垮）：

Hystrix 视角：保护"调用方"不被"故障的依赖"拖垮
  → 依赖挂了就熔断、用线程池隔离依赖

Sentinel 视角：保护"系统本身"不被"过大的流量"压垮
  → 限制 QPS/并发、按系统负载自适应限流，还兼顾熔断降级

Sentinel 更全面——它不只是熔断，而是一整套「流量治理」：限流（控制入口流量）、熔断降级（隔离故障依赖）、热点限流（针对特定参数）、系统保护（按负载自适应）。所以面试问「Sentinel 和 Hystrix 区别」，核心答案是：Hystrix 侧重熔断隔离，Sentinel 侧重流量控制且功能更全面，加上 Hystrix 已停更、Sentinel 活跃维护有控制台，国内更主流。

二、流量控制：限流的两个维度与算法

限流是 Sentinel 的招牌能力，控制「多少流量能进来」，有两个维度：

① QPS 限流：每秒最多处理多少请求
   阈值 100 QPS → 超过 100 的请求被拒绝/排队

② 并发线程数限流：同时最多多少线程在处理这个资源
   阈值 20 → 同时超过 20 个线程处理时，多的被拒绝

被限流后有三种「流控效果」：

① 直接拒绝（默认）：超过阈值直接抛 BlockException（快速失败）
② Warm Up（预热）：阈值缓慢升到设定值（冷启动保护，防止刚启动就被打满）
   例：阈值 100，预热 10 秒 → 从 100/3 逐渐升到 100，给系统预热时间
③ 匀速排队（漏桶）：请求匀速通过，多的排队等待（削峰填谷）
   用漏桶算法，让突发流量变成匀速流量

Sentinel 底层用滑动窗口统计 QPS（把时间切成小格子统计请求数，比固定窗口更平滑）。三种流控效果对应不同场景：直接拒绝用于「超了就快速失败」；Warm Up用于「刚启动/缓存刚失效，需要预热避免瞬间被打满」；**匀速排队（漏桶）**用于「削峰，把突发流量平滑成匀速」。理解「限流两维度（QPS/并发）+ 三效果（拒绝/预热/排队）」，就掌握了 Sentinel 限流的核心。

三、熔断降级：慢调用与异常比例

Sentinel 的熔断和 Hystrix 类似（也是三态：关闭→打开→半开），但熔断的触发条件更丰富：

Sentinel 熔断的三种触发策略：
① 慢调用比例：响应时间超过阈值（如 500ms）的调用占比超过阈值（如 50%）→ 熔断
② 异常比例：异常调用占比超过阈值（如 50%）→ 熔断
③ 异常数：一定时间内异常数超过阈值（如 5 个）→ 熔断

熔断后（打开状态）：熔断时长内的请求直接走 fallback，不再调真实方法
熔断时长过后 → 半开状态 → 放一个请求试探 → 成功则关闭、失败则继续熔断

关键增强是**「慢调用比例」熔断**——Hystrix 主要看异常，Sentinel 还能看「响应慢」（慢调用比例）。这很重要：一个依赖可能不报错但响应极慢（比报错更危险，会拖垮线程池），Sentinel 能基于「慢调用比例」熔断它。三态转换（关闭→打开→半开）的逻辑和熔断器通用模型一致：正常时关闭、故障多了打开（快速失败）、过一段时间半开试探恢复。理解「Sentinel 熔断支持慢调用/异常比例/异常数三种触发」，就抓住了它比 Hystrix 熔断更全面的点。

四、热点参数限流：针对特定值限流

这是 Sentinel 的独特能力（Hystrix/Resilience4j 都没有）——对某个参数的「特定热点值」单独限流：

场景：一个商品查询接口，某个爆款商品 ID=888 被疯狂查询（占了 90% 流量）
普通限流：对整个接口限流 → 会误伤其他正常商品的查询
热点限流：识别出"参数 id=888 是热点"，单独对它限流（如 id=888 限 10 QPS）
  → 其他商品 ID 不受影响，只压制那个爆款

实现：Sentinel 统计每个参数值的访问频率，对高频的特定值单独设阈值

热点限流解决的是「流量倾斜」问题——不是整个接口流量大，而是某几个「热点值」（爆款商品、大 V 用户、热门话题）占了大部分流量。对整个接口限流会误伤正常请求，热点限流能精准地只压制那些热点值。它还支持「例外项」（对某些特定值设不同阈值）。这是 Sentinel 在电商、社交等「有明显热点」场景的杀手锏，也是它区别于其他熔断限流组件的独特功能。

五、系统自适应保护：按负载自动限流

Sentinel 还有一个「兜底」能力——系统自适应保护，根据系统整体指标自动限流：

前面的限流都是"针对单个资源"设固定阈值，但有个问题：
  你很难为每个接口都算准阈值，且系统整体负载才是最终瓶颈

系统自适应保护：不针对单个接口，而是看系统整体指标：
  - Load（系统负载）
  - CPU 使用率
  - 平均响应时间（RT）
  - 入口 QPS、并发线程数
  当系统整体快扛不住时（如 Load 超阈值）→ 自动限流，保护系统不被压垮

它的价值是「最后一道防线」——即使你没给每个接口配限流，或者配的阈值不准，系统自适应保护也能在「系统整体快崩溃」时自动介入限流，让系统保持在「刚好能处理」的水位，避免雪崩。这体现了 Sentinel「保护系统本身」的核心理念——不只是保护单个资源，而是从系统整体健康度出发做流量控制。这是它比「只做单点熔断」的 Hystrix 更全面的地方。

六、控制台与规则动态推送

Sentinel 的工程化能力也是它比 Resilience4j 强的地方——有功能丰富的控制台：

Sentinel 控制台能做：
  - 实时监控：查看每个资源的 QPS、响应时间、拒绝量（秒级）
  - 规则配置：在控制台配置限流/熔断/热点规则，动态生效
  - 规则推送：规则可推送到应用（配合 Nacos 等做持久化，重启不丢）

对比：
  Resilience4j：轻量函数库，无控制台，规则写在代码/配置里
  Hystrix：有 Dashboard 但只能看不能改规则
  Sentinel：能看能改，规则动态推送、实时生效

关键优势是**「规则动态配置 + 实时推送」**——不用改代码、不用重启，在控制台改个限流阈值就立即生效。生产环境这非常重要：大促前临时调高/调低限流阈值、发现某接口异常临时熔断，都能实时操作。不过默认 Sentinel 控制台的规则是存在内存的（重启丢失），生产要配合 Nacos 等做规则持久化（规则存 Nacos，应用重启从 Nacos 拉取，控制台改了推到 Nacos 再推给应用），形成完整的「配置-推送-持久化」闭环。这套工程化能力是 Sentinel 成为国内主流的重要原因。

记忆钩子：「Sentinel（阿里）以限流为核心的流量治理：限流（QPS/并发 + 直接拒绝/Warm Up 预热/匀速排队漏桶，滑动窗口统计）、熔断降级（慢调用比例/异常比例/异常数，三态）、热点参数限流（对特定热点值单独限流，独有）、系统自适应保护（按 Load/CPU 自动限流）；有控制台 + 规则动态推送（配 Nacos 持久化）；vs Hystrix（熔断隔离已停更）/Resilience4j（轻量无控制台）」。

七、常见误区与追问

误区：Sentinel 就是 Hystrix 的替代品，功能一样。 Sentinel 以「限流」为核心且更全面（热点限流、系统自适应、控制台、规则推送），Hystrix 以「熔断+线程隔离」为核心且已停更。
误区：blockHandler 和 fallback 是一回事。 blockHandler 处理「被 Sentinel 规则限流/熔断」（BlockException），fallback 处理「业务方法自身抛异常」；场景不同，被限流走前者、业务报错走后者。
误区：限流只能限 QPS。 Sentinel 支持 QPS 和并发线程数两个维度限流，还有直接拒绝/预热/匀速排队三种流控效果适配不同场景。
误区：Sentinel 熔断只看异常。 它支持三种熔断触发——慢调用比例、异常比例、异常数；「慢调用比例」很重要（依赖不报错但极慢也危险，比 Hystrix 只看异常更全面）。
追问：热点参数限流解决什么问题？ 流量倾斜——某个参数的特定值（爆款商品 ID、大 V 用户）占大部分流量时，对整个接口限流会误伤正常请求，热点限流能只压制那些热点值、不影响其他。
追问：Sentinel 的系统自适应保护是什么？ 不针对单个资源，而是根据系统整体 Load/CPU/RT/QPS 等指标自动限流，作为「最后一道防线」——即使单点阈值没配准，系统整体快崩时也能自动介入保护。
追问：Sentinel 规则重启会丢吗？怎么持久化？ 默认规则存内存、重启丢失；生产配合 Nacos 等做持久化——规则存 Nacos，控制台改了推到 Nacos 再推给应用，应用重启从 Nacos 拉取，形成配置闭环。

八、加强记忆

Sentinel（阿里）是以「限流」为核心的流量治理组件（Spring Cloud Alibaba 里替代 Hystrix），核心理念是「保护系统本身不被过大流量压垮」（Hystrix 侧重「保护调用方不被故障依赖拖垮」）。四大能力：① 流量控制（限流）——QPS/并发两维度 + 直接拒绝/Warm Up 预热/匀速排队（漏桶）三效果，滑动窗口统计；② 熔断降级——慢调用比例/异常比例/异常数三种触发（比 Hystrix 只看异常更全面，慢调用尤其重要），三态转换；③ 热点参数限流——对某参数的特定热点值单独限流（治理流量倾斜，独有能力）；④ 系统自适应保护——按 Load/CPU/RT 自动限流，做最后防线。工程化上有功能丰富的控制台 + 规则动态推送（配 Nacos 持久化），能不改代码不重启实时调规则。用法上区分 blockHandler（被限流/熔断，BlockException）和 fallback（业务异常）。对比：Hystrix（熔断+隔离，已停更）、Resilience4j（轻量函数库无控制台）、Sentinel（限流为核心、功能全、有控制台、活跃）。一句话「Sentinel 限流为核心：QPS/并发限流+慢调用熔断+热点限流+系统自适应，控制台可动态配规则，比 Hystrix 全面且活跃」。

简化版

详细版