中 进阶
Sentinel限流原理#
一句话答案#
Sentinel 责任链模式：FlowSlot（限流）→DegradeSlot（熔断）→SystemSlot（系统保护），基于滑动窗口统计 QPS。
核心要点
流控策略： 直接拒绝 / Warm Up(预热) / 排队等待
熔断策略： 慢调用比例 / 异常比例 / 异常数
核心架构： 责任链模式 ProcessorSlotChain → FlowSlot(限流) → DegradeSlot(熔断) → SystemSlot(系统保护)
三代熔断限流框架对比：
| 维度 | Sentinel | Resilience4j | Hystrix |
|---|---|---|---|
| 维护状态 | 阿里巴巴活跃维护 | 社区活跃维护 | Netflix 已停止维护（2018） |
| 隔离策略 | 信号量隔离（基于并发数） | 信号量隔离 | 线程池隔离 + 信号量隔离 |
| 熔断策略 | 慢调用比例 / 异常比例 / 异常数 | 基于失败率 / 慢调用率 | 基于失败率 |
| 限流 | 内置（QPS、并发数、关联限流） | 内置（Rate Limiter） | 不支持 |
| 流量整形 | 支持（匀速排队、预热） | 不支持 | 不支持 |
| 热点参数 | 支持（按参数限流） | 不支持 | 不支持 |
| 系统自适应 | 支持（CPU/Load 自适应限流） | 不支持 | 不支持 |
| Dashboard | 自带控制台（实时监控 + 动态规则） | 无（需搭配 Prometheus + Grafana） | Hystrix Dashboard + Turbine |
| 规则持久化 | 支持（Nacos / Apollo / ZK） | 需自行实现 | 配置文件 |
| 性能开销 | 低（滑动窗口，无线程池切换） | 极低（纯函数式） | 较高（线程池隔离有上下文切换开销） |
选型建议：
- Spring Cloud Alibaba 技术栈 → Sentinel（功能最全面，Dashboard 强大）
- Spring Boot 原生 / 轻量级需求 → Resilience4j（轻量、函数式、无外部依赖）
- 老项目迁移 → 从 Hystrix 迁移到 Sentinel 或 Resilience4j
面试回答（2分钟版）
Sentinel是阿里开源的流量治理组件，核心架构采用责任链模式，请求进来后依次经过ProcessorSlotChain上的多个Slot：FlowSlot负责限流、DegradeSlot负责熔断降级、SystemSlot负责系统级保护。限流方面支持三种策略：直接拒绝适合突发流量场景，Warm Up预热模式让通过的QPS逐渐增加适合冷启动，排队等待模式让请求匀速通过适合削峰填谷。熔断方面支持按慢调用比例、异常比例和异常数三种维度触发。底层通过滑动窗口统计实时的QPS和响应时间数据来做决策。和Hystrix相比，Sentinel的优势是支持更丰富的限流策略、自带Dashboard可视化配置、支持热点参数限流，而且是轻量级的，对性能影响更小。生产中规则不应该硬编码在代码里，应该推送到Nacos等配置中心实现动态管理。
追问与易错
追问方向：
- “Sentinel 和 Hystrix 区别？”→ Sentinel 支持更丰富的限流策略（QPS/并发数/热点参数）、自带 Dashboard 可视化、信号量隔离性能开销小；Hystrix 已停止维护（2018），依赖线程池隔离开销较大
- “规则怎么持久化？”→ 默认规则存在内存中重启即丢失；生产环境应推送到 Nacos/Apollo/ZooKeeper 等配置中心，实现规则持久化和动态更新，Dashboard 修改也同步到配置中心
易错点：
- ❌ Sentinel 只能限流——还支持熔断和系统保护
- ❌ 规则配在代码里——应推送到配置中心