「彩虹小区」午高峰到了，空调、烤箱、充电桩一起上，老楼的配电箱滋滋作响。电工老周攥着两套工具：柜子左侧是一排传统保险丝（Hystrix），右侧是新装的智能空气开关（Sentinel）。保险丝烧断就跳闸，保护整栋楼不被烧毁，但换起来麻烦；智能空开更聪明，能设定每路功率上限、自动恢复、还能把故障回路与健康回路隔开。Java 微服务世界里，一次下游抖动就可能像跳闸一样引发全链路雪崩，熔断降级正是那个保护系统不烧毁的「总闸」。本文就用老周的配电箱故事，带你对比两款主流总闸的脾气与用法，看完你就知道：什么时候该用谁，出了故障该查谁。

岗位关联

熔断与限流是把「不可控的下游」变成「可控的失败」的必修课。理解两款工具的设计取舍，能让你在技术选型、故障排查和高可用架构设计中更有底气。

目录
  1. 可视化演示
  2. 熔断降级本质
  3. Hystrix隔离机制
  4. Sentinel特色能力
  5. 限流算法对比
  6. 动态规则配置
  7. 监控运维对比
  8. 选型与迁移
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示熔断器状态机、限流算法对比与舱壁隔离策略，切换模式查看两款熔断降级工具的核心机制差异。

本节配有交互动效（进入视口后自动加载，约 3KB）。

熔断状态机：CLOSED→OPEN→HALF_OPEN CLOSED正常放行请求 错误率超阈值触发OPEN熔断 错误率 = 失败请求数 / 总请求数 Sentinel支持慢调用比例+异常比例双策略

熔断降级本质

彩虹小区午高峰，老周最怕整栋楼停电——不是发电机坏了，而是某一户短路后，电流击穿其他回路的绝缘层，一层层烧下去。微服务世界一模一样：一个下游服务抖动，调用它的服务跟着线程积压，再传染给更上游，这就是「服务雪崩」。熔断降级，就是老周在每层楼装的那道总闸。

微服务调用链 A→B→C，C 响应变慢，B 的线程被占满，请求继续堆积到 A，最后整条链路瘫痪。熔断（Circuit Breaking）是主动断开对故障依赖的调用，让它快速失败，不再傻等；降级（Degradation）是断开后返回兜底结果，比如缓存数据、默认值或友好提示。两者一个管「断」，一个管「救」。

熔断器本质上是一个状态机，三态交替：关闭（CLOSED）时正常放行；连续失败超过阈值，跳到打开（OPEN），请求直接快速失败；经过等待窗口进入半开（HALF_OPEN），放一个探活请求试水，成功就回到关闭，失败则再次打开。整个流程和保险丝「烧断—检查—合闸」如出一辙。

老周总结：单户短路不可怕，可怕的是顺着串联线路烧遍全楼。所以熔断降级不是「修好下游」，而是「保证自己不死」，把故障关在笼子里。

Psnow=1−(1−p)n\displaystyle P_{\text{snow}} = 1 - (1-p)^{n}
调用链上串行挂着 n 个依赖，每个依赖独立故障概率为 p，整条链至少一个出问题的概率就是雪崩概率。n 越多、p 越高，它越接近 1。
  1. 单点幸存(1-p) 表示某个服务不出故障的概率，就像一根灯丝完好的概率。
    Pok=1−p\displaystyle P_{\text{ok}} = 1 - p
  2. 串联求全链路要正常，n 根灯丝必须全部完好，概率相乘。
    Pchain=(1−p)n\displaystyle P_{\text{chain}} = (1-p)^{n}
  3. 补集求崩用 1 减去全部完好的概率，就是至少一处故障的概率。
    Psnow=1−(1−p)n\displaystyle P_{\text{snow}} = 1 - (1-p)^{n}

Hystrix隔离机制

老周的保险丝盒，最有价值的设计是「每户独立回路」：厨房跳闸，卧室照样亮灯。Hystrix 把这个思路叫「舱壁隔离」——像轮船的水密隔舱，一个舱进水，船不沉。

Hystrix 是 Netflix 在 2012 年开源的 Java 容错库，曾经是 Spring Cloud 的标配。它把每次对下游的调用包装成 Command，并给每个下游分配独立线程池。当 C 服务变慢，只会耗尽它的专属线程池，B 的其他业务照常运行。配合超时控制，超过设定毫秒数直接中断，不再占着线程傻等。

Hystrix 提供两种隔离：线程池隔离（thread pool）默认开启，支持超时中断、异步、队列缓冲，但每个依赖大约 10 个线程起步，100 个依赖就是千级线程；信号量隔离（semaphore）只计数并发量，不建线程池，适合高并发、低延时的场景。熔断判定使用 10 秒滑动窗口：窗口内请求总数 ≥ 20 且失败率 ≥ 50% 即跳闸。

保险丝的规格是出厂固定的，想调整得关总闸手工换；Hystrix 的线程池参数同样依赖配置文件或配置中心，改起来带不动，这就是它「重而稳」的底色。

R=FF+S≥ϕ\displaystyle R = \frac{F}{F + S} \ge \phi
失败率等于失败数除以总请求数，超过阈值 φ（Hystrix 默认 50%）就触发熔断。F 是失败数，S 是成功数。
  1. 失败计数F 是窗口内失败请求数，包括超时、抛异常、线程池拒绝。
    T=F+S\displaystyle T = F + S
  2. 总数求和F+S 是窗口内总请求数，成功失败都算入分母。
    T=F+S\displaystyle T = F + S
  3. 阈值触发失败率 R 超过 φ 且总数达到最小请求数，熔断器由关闭转为打开。
    R≥ϕ⇒OPEN\displaystyle R \ge \phi \Rightarrow \text{OPEN}

Sentinel特色能力

如果说 Hystrix 是老实巴交的保险丝，Sentinel 就是那块智能空气开关——按下屏上的数字键，就能给每路电器设「功率红线」。

Sentinel 是阿里巴巴开源的流量防卫组件，口号是「流控优先」。它以资源为单位——一个方法、一个 URL 甚至一段代码块都可以是资源，然后用规则决定资源放行还是拒绝。相比 Hystrix「先隔离后统计」的思路，Sentinel 更强调「先限流再兜底」。

Sentinel 有三大特色能力：其一，流控规则，支持按 QPS 或并发线程数限流，并带直接拒绝、预热、匀速排队三种效果；其二，热点参数限流，精确到具体参数值，秒杀时对单个商品 ID 限流，其他商品不受影响；其三，系统自适应保护，当整机 Load、CPU 或入口 QPS 过高时全局兜底。熔断方面，Sentinel 支持慢调用比例、异常比例、异常数三种模式，比 Hystrix 的单一口径精细得多。

老周最喜欢智能空开的「自定义功率限额」——它像热点参数一样，把保护精确到「哪台空调」而不是「整个楼道」，这就是 Sentinel 比保险丝精细的地方。

Rslow=SslowNtotal>θ\displaystyle R_{\text{slow}} = \frac{S_{\text{slow}}}{N_{\text{total}}} > \theta
窗口内响应时间超过阈值的慢调用数量，占总请求数的比例，超过 θ（例如 0.5）即触发熔断。
  1. 慢请求统计S_slow 是最大 RT 超过指定值（如 500ms）的请求数量。
    Sslow=#{ti>RTmax⁡}\displaystyle S_{\text{slow}} = \#\{t_i > \text{RT}_{\max}\}
  2. 占比计算慢调用数除以窗口内总请求数 N_total，得到慢调用比例。
    Rslow=SslowNtotal\displaystyle R_{\text{slow}} = \frac{S_{\text{slow}}}{N_{\text{total}}}
  3. 触发熔断比例大于 θ 且请求数达到最小通过数，熔断打开。
    Rslow>θ⇒OPEN\displaystyle R_{\text{slow}} > \theta \Rightarrow \text{OPEN}

限流算法对比

限流就像楼道里的刷卡闸机：高峰期每分钟最多放 30 人进门。四种常用算法，相当于四种闸机设计，有的粗放，有的精细。

Hystrix 自身不做窗口限流，它靠线程池饱和来「被动限流」；Sentinel 则把限流算法作为一等公民内置。先说固定窗口：把时间切成 1 秒一格，每格限 100 个请求，实现简单，但边界突刺明显——第 0.9 秒放走 99 个，第 1.1 秒又能放 100 个，瞬时流量翻倍。

滑动窗口把 1 秒再切成一堆小格子，计数随时间滚动，突刺被抹平；令牌桶按固定速率往桶里装令牌，桶里攒下的令牌允许突发流量；漏桶则让请求以恒定速率流出，彻底磨平突发。一句话：滑动窗口胜在精确，令牌桶胜在灵活，漏桶胜在匀速。

老周给单元门装了滑动窗口闸机——数人排得平；给电梯装了漏桶——匀速更稳当。算法没有银弹，按场景选，这正是 Sentinel 的配置哲学。

N(t)=min⁡ ⁣(C,  N(t−Δt)+r⋅Δt)\displaystyle N(t) = \min\!\big(C,\; N(t - \Delta t) + r \cdot \Delta t\big)
每个时间片往桶里匀速加 r 个令牌，最多不超过容量 C；请求来一个取一个，没令牌就拒绝或排队。
  1. 桶有容量桶最多装 C 个令牌，装满后新令牌直接丢弃，防止无限积累。
    N≤C\displaystyle N \le C
  2. 匀速补充每隔 Δt 时间增加 r·Δt 个令牌，补充速率恒定。
    Nnew=Nold+r⋅Δt\displaystyle N_{\text{new}} = N_{\text{old}} + r \cdot \Delta t
  3. 取令牌过闸一个请求消耗一个令牌；桶空则拒绝或排队等待。
    N>0⇒pass\displaystyle N > 0 \Rightarrow \text{pass}

动态规则配置

智能空开的操作屏是个「遥控器」，老周能现场改参数：老王办婚礼要开大功率，临时把空调回路限额调高，不用断电更不用换零件。动态规则就是熔断限流的遥控器。

规则配置是把流控、熔断参数告诉组件的方式。Hystrix 用 @HystrixCommand 注解声明降级方法，线程池、超时参数大多通过配置文件或配置中心下发，调整要配合发布流程。Sentinel 用 @SentinelResource 注解埋点，规则由控制台或 API 动态推送，改完立刻生效。

Sentinel 的规则分四类：流量规则、熔断规则、热点规则、系统规则。埋点后的资源出现在控制台「簇点链路」里，点几下就配好；规则还能持久化到 Nacos 等配置中心，应用重启不丢。网关层面，Spring Cloud Gateway 与 Sentinel 适配后，可以在入口统一限流，形成「网关粗粒度 + 服务细粒度」的双层保护。

「不用断电改参数」听起来是小事，在生产环境意味着零发布、零重启。老周的遥控器，就是运维同学的续命神器。

Nwindow=∑i=1mni≤Tlimit\displaystyle N_{\text{window}} = \sum_{i=1}^{m} n_i \le T_{\text{limit}}
把时间窗口切成 m 个小格子，格子内请求数求和；总和不超过阈值就放行，超过则拒绝。这是滑动窗口限流的判定核心。
  1. 切格子窗口（如 1 秒）切成 m 个微窗口，每个微窗口记录请求数 n_i。
    Δtslot=windowm\displaystyle \Delta t_{\text{slot}} = \frac{\text{window}}{m}
  2. 逐格求和窗口内请求总数等于各格子计数累加。
    Nwindow=∑i=1mni\displaystyle N_{\text{window}} = \sum_{i=1}^{m} n_i
  3. 判定限流N_window 超过阈值即拒绝；格子随时间滚动，窗口平滑滑动。
    Nwindow>Tlimit⇒reject\displaystyle N_{\text{window}} > T_{\text{limit}} \Rightarrow \text{reject}

监控运维对比

老周最怕的不是跳闸，而是「不知道谁在偷电、哪条线过热」。电表读数、温度报警才是配电房的真正眼睛。熔断降级如果没有监控，就像保险丝烧了没人知道，只能等用户投诉。

Hystrix 的监控靠 Hystrix Dashboard 展示单机指标，多机聚合要再搭建 Turbine 服务，链路较长；加上 Hystrix 2018 年后进入维护模式，官方不再出新功能，社区指标逐步转向 Micrometer 对接 Prometheus。说白了，老保险丝盒没有自带电表，得自己外接。

Sentinel 自带 Dashboard 控制台，开箱即用：实时监控秒级刷新，每台机器的 QPS、拒绝数、熔断状态一目了然；簇点链路列出所有资源，能看出流量花在哪；规则管理支持在线修改。长期存储和告警可对接 Prometheus + Grafana，形成「秒级看板、分钟级告警、小时级复盘」的闭环。

智能空开的屏幕让老周一眼看到哪路在跳闸、哪路在过载；Sentinel 的 Dashboard 正是这块屏幕，让「看不见的故障」变成「看得见的曲线」。

A=MTBFMTBF+MTTR\displaystyle A = \frac{\text{MTBF}}{\text{MTBF} + \text{MTTR}}
可用性等于平均无故障时间除以总时间。熔断恢复越快（MTTR 越小），系统可用性越高。
  1. 健康时长MTBF 是两次故障之间的平均正常工作时长。
    MTBF=正常总时长故障次数\displaystyle \text{MTBF} = \frac{\text{正常总时长}}{\text{故障次数}}
  2. 修复时长MTTR 是故障发生到恢复的平均时长，熔断半开的探活间隔就是它的一部分。
    MTTR=故障总时长故障次数\displaystyle \text{MTTR} = \frac{\text{故障总时长}}{\text{故障次数}}
  3. 相除出值正常时间占总时间的比例，越接近 1 越稳定。
    A=MTBFMTBF+MTTR\displaystyle A = \frac{\text{MTBF}}{\text{MTBF} + \text{MTTR}}

选型与迁移

换配电箱是大事：老保险丝便宜但呆板，智能空开功能全但要改造线路。选型不是单纯比参数，而是权衡「省心」和「省钱」。

功能上，Sentinel 覆盖流控、热点、系统保护、熔断、可观测，全面胜出；Hystrix 只擅长隔离和熔断，且已停更。性能上，Hystrix 每个依赖一个线程池，用 Little 定律粗算：一个依赖 1000 QPS、平均耗时 50ms，就需要 50 个常驻线程，十个依赖就是五百线程；Sentinel 默认不额外占线程，省下的资源可观。

迁移有两条路：老项目想小步快跑，可以迁到 Resilience4j——它是轻量容错库，只有状态机、不带线程池，概念与 Hystrix 几乎一一对应，改造量小；想彻底现代化，直接上 Sentinel，注解替换加规则搬到控制台。社区与生态方面，Sentinel 背靠阿里，与 Spring Cloud Alibaba、Nacos 深度集成，活跃度和文档都更好。

老周最后定了方案：楼里主闸换智能空开，每户加装轻量漏电保护。这就像当下社区里流行的「Sentinel 主防 + Resilience4j 兜底」组合拳。

N=QPS×Tlatency\displaystyle N = \text{QPS} \times T_{\text{latency}}
满足目标 QPS 所需的并发线程数，约等于每秒请求数乘以平均响应时间。这是估算线程池大小和对比隔离开销的核心公式。
  1. 每秒来客QPS 是每秒请求量，代表流量压力。
    Nreq=QPS\displaystyle N_{\text{req}} = \text{QPS}
  2. 客占时长T_latency 是平均响应时间，代表每个请求占住线程多久。
    T=Tlatency\displaystyle T = T_{\text{latency}}
  3. 乘法得并发两者相乘就是同时占用的线程数，即线程池大小上界。
    N=QPS×Tlatency\displaystyle N = \text{QPS} \times T_{\text{latency}}

AI 应用场景

大促秒杀的流量洪峰防护

阶段：在线服务稳定性保障阶段

解决的问题：大促时用户瞬间涌入，传统「靠扩容扛流量」成本高且扩容速度追不上峰值。用 Sentinel 的流控规则 + 热点参数，对下单接口按 QPS 限流，对单个商品 ID 热点限流，超量请求直接拒绝并提示「稍后再试」。

具体案例：某电商平台 618 大促，用 Sentinel 控制台把「创建订单」接口限流为 5 万 QPS，热点规则把爆款商品的单商品维度 QPS 限制为 2 万，下游库存服务全程零告警。

第三方支付网关抖动隔离

阶段：故障隔离与降级兜底阶段

解决的问题：支付网关抖动时，同步阻塞会占满业务线程。用 Hystrix 线程池隔离把支付依赖独立成池，配合超时控制快速失败，失败返回兜底结果「支付确认中」。

具体案例：某外卖平台对接银行支付，晚间银行系统变慢，平均耗时从 200ms 涨到 3 秒。Hystrix 在失败率超 50% 时打开熔断，5 秒后探活恢复，高峰期系统整体 RT 保持 100ms 以内。

AI 推荐服务的模型依赖保护

阶段：AI 模型服务的高可用保障阶段

解决的问题：推荐系统既要调模型推理服务，又要调用户画像服务，模型服务 GPU 资源紧张时响应变慢。用熔断降级在模型超时或异常比例超标时兜底为「热榜推荐」，避免整站推荐链路雪崩。

具体案例：某内容社区给推荐接口配置 Sentinel 慢调用比例熔断（RT > 300ms 的比例超 50% 触发），模型服务抖动时自动走兜底推荐，核心点击率仅损失 5%。

Python 演示

python82 行
import timeimport random  class CircuitBreaker:    # 极简熔断器: 统计失败率, 触发开关, 支持半开探活    def __init__(self, fail_threshold=0.3, min_requests=5, wait_seconds=2):        self.fail_threshold = fail_threshold        self.min_requests = min_requests        self.wait_seconds = wait_seconds        self.state = "CLOSED"        self.success_count = 0        self.failure_count = 0        self.opened_at = 0.0     def _reset_counts(self):        self.success_count = 0        self.failure_count = 0     def _failure_rate(self):        total = self.success_count + self.failure_count        if total == 0:            return 0.0        return self.failure_count / total     def allow(self):        now = time.time()        if self.state == "OPEN":            if now - self.opened_at >= self.wait_seconds:                self.state = "HALF_OPEN"                self._reset_counts()            else:                return False        return True     def record(self, ok):        if ok:            self.success_count += 1        else:            self.failure_count += 1        if self.state == "HALF_OPEN":            if ok:                self.state = "CLOSED"            else:                self.state = "OPEN"                self.opened_at = time.time()            self._reset_counts()            return        total = self.success_count + self.failure_count        if total < self.min_requests:            return        if self._failure_rate() >= self.fail_threshold:            self.state = "OPEN"            self.opened_at = time.time()            self._reset_counts()  def remote_call(prob_down=0.3):    if random.random() < prob_down:        raise RuntimeError("upstream timeout")    return "ok"  def main():    breaker = CircuitBreaker(fail_threshold=0.3, min_requests=10, wait_seconds=1)    for i in range(30):        if not breaker.allow():            print("req=%02d state=%s result=fast-fail" % (i, breaker.state))            time.sleep(0.1)            continue        try:            remote_call(prob_down=0.4)            breaker.record(True)            print("req=%02d state=%s result=success" % (i, breaker.state))        except RuntimeError:            breaker.record(False)            print("req=%02d state=%s result=failure" % (i, breaker.state))        time.sleep(0.1)  if __name__ == "__main__":    main()
目的：用 80 行 Python 实现一个极简熔断器，完整演示「关闭 → 打开 → 半开 → 关闭」的状态机，对应 Hystrix/Sentinel 的核心熔断逻辑。
  1. breaker = CircuitBreaker(fail_threshold=0.3, min_requests=10, wait_seconds=1)设置失败率阈值 30%、至少统计 10 个请求，对应 Hystrix 的 requestVolumeThreshold。
  2. if self._failure_rate() >= self.fail_threshold:失败率超过阈值就打开断路器，对应正文公式 R ≥ φ。
  3. if now - self.opened_at >= self.wait_seconds: self.state = "HALF_OPEN"等待窗口过后进入半开，准备放探活请求。
  4. if self.state == "HALF_OPEN": if ok: self.state = "CLOSED"半开探活成功则恢复关闭，失败则重新打开。
  5. if not breaker.allow(): print(... result=fast-fail)熔断打开时请求直接快速失败，跳过下游调用。
  6. remote_call(prob_down=0.4)模拟下游有 40% 概率超时，让演示能真实触发熔断。

常见误区

误区我一直觉得熔断和降级是一回事，只要下游挂了，返回一段兜底数据就是熔断。

正解熔断是「开关动作」——统计失败率后决定断不断开连接；降级是「兜底策略」——断开后返回什么。熔断通常会触发降级，但降级不一定因为熔断：超时、流量超限、手动开关都会降级。就像跳闸是开关动作，点蜡烛才是应急照明方案。

为何常见：两者总是一起出现，资料里也常写「熔断降级」，初学者便默认它们是同一个东西。

误区Hystrix 给每个依赖配独立线程池，那我给所有下游都做隔离，系统肯定更安全。

正解线程池也吃内存和上下文切换开销。每个依赖 10 线程，100 个依赖就是 1000 个常驻线程，光闲置成本就很高。信号量隔离更适合高并发、短耗时的场景。隔离的核心是把「高风险依赖」关进独立回路，而不是全楼每户都装闸。

为何常见：看到隔离能防雪崩，就下意识全员上线程池，忽略了资源成本和收益边界。

误区1 秒固定窗口限流 100，看着挺稳。窗口临界点那个瞬间可能放到 200 个请求，但平均下来还是每秒 100，应该没问题。

正解固定窗口的「窗口边界突刺」正是它最大的短板：第 0.9 秒放了 99 个，第 1.1 秒又能放 100 个，瞬时流量翻倍。滑动窗口把窗口细分成小格子，计数随时间滚动，才能逼近真实速率。

为何常见：人的直觉是「每秒 100」已经很精确，想不到窗口交界处会漏出双倍流量。

误区熔断器进入半开，探活请求成功一个，然后恢复关闭状态，下游应该彻底好了。

正解半开只放一个请求试探，成功只说明「这次通了」。如果下游是间歇性故障，探活成功恢复后可能再次熔断。Hystrix 有最小请求数要求，Sentinel 会持续评估慢调用比例，恢复不等于一劳永逸。

为何常见：把探活当成「检测结论」而非「概率采样」，忽略了故障的间歇性和波动性。

面试题

Q1. 熔断器状态机中的三种状态是？

单选题 · easy

  • A.关闭、打开、半开← 正确答案
  • B.启动、运行、停止
  • C.等待、就绪、阻塞
  • D.新建、就绪、销毁

答案：A。熔断器三状态是关闭（CLOSED）正常放行、打开（OPEN）快速失败、半开（HALF_OPEN）探活恢复。B、C、D 都是进程或线程状态，与熔断无关。

Q2. Hystrix 默认使用哪种隔离方式？

单选题 · easy

  • A.线程池隔离← 正确答案
  • B.信号量隔离
  • C.数据库隔离
  • D.缓存隔离

答案：A。Hystrix 默认线程池隔离，把每个下游依赖放入独立线程池。信号量隔离也是合法选项，但它是可选而非默认；C、D 是凑数干扰项。

Q3. 5 个依赖串行组成调用链，每个依赖故障概率 0.2，链路发生雪崩的概率约为？

单选题 · mid

  • A.1 - 0.2^5 ≈ 0.9997
  • B.1 - 0.8^5 ≈ 0.6723← 正确答案
  • C.0.8^5 ≈ 0.3277
  • D.0.2 × 5 = 1.0

答案：B。每个依赖正常概率为 1-0.2=0.8，链路全部正常概率为 0.8^5≈0.3277，雪崩概率为 1-0.3277≈0.6723。A 把方向搞反了，D 是简单相加忽略了概率乘法。

Q4. 固定窗口限流算法最主要的缺陷是？

单选题 · mid

  • A.窗口边界处流量突刺← 正确答案
  • B.令牌耗尽导致饥饿
  • C.线程池死锁风险高
  • D.内存泄漏难以回收

答案：A。固定窗口在窗口交界处可放行双倍请求，形成流量突刺。B、C、D 分别是令牌桶、线程调度、资源回收话题，与窗口计数无关。

Q5. 关于令牌桶限流算法，下列说法正确的是？

单选题 · mid

  • A.允许一定程度的突发流量← 正确答案
  • B.完全拒绝所有突发流量
  • C.不需要设置桶的容量
  • D.只能用于单机部署场景

答案：A。令牌桶会以恒定速率积累令牌，请求突发时可消耗桶内存量，所以允许一定突发。漏桶才是强制匀速；桶容量 C 是必设参数；分布式场景也能用。

Q6. Sentinel 的系统自适应保护，主要依据下列哪类指标做整机兜底？

单选题 · mid

  • A.系统负载与 CPU 使用率← 正确答案
  • B.应用启动时间长短
  • C.磁盘剩余空间大小
  • D.编译器执行频次统计

答案：A。Sentinel 系统自适应保护依据 Load、CPU、整体 RT、线程数、入口 QPS 等整机指标兜底，防止流量把机器打垮。B、C、D 与流量控制无关。

Q7. Hystrix 默认触发熔断的条件组合是？

单选题 · hard

  • A.10 秒窗口内请求数 ≥ 20 且失败率 ≥ 50%← 正确答案
  • B.5 秒窗口内请求数 ≥ 10 且失败率 ≥ 30%
  • C.1 分钟窗口内请求数 ≥ 100 且失败率 ≥ 80%
  • D.任意单个请求发生超时就立刻熔断

答案：A。Hystrix 用 10 秒滑动窗口统计，失败率 ≥ 50% 且请求总数 ≥ 20 才开闸，两个条件缺一不可。D 忽略了最小请求数要求，避免低频小流量误伤。

Q8. 下列哪些属于 Sentinel 相比 Hystrix 的独有能力？（多选）

多选题 · hard

  • A.支持热点参数限流← 正确答案
  • B.提供系统自适应保护← 正确答案
  • C.基于线程池的参数隔离
  • D.依赖 Turbine 的指标聚合

答案：AB。热点参数限流和系统自适应保护是 Sentinel 标志性能力。C 是 Hystrix 的线程池隔离，D 是 Hystrix Dashboard 的聚合方案，都不属于 Sentinel。

Q9. 以下哪些做法能有效防止服务雪崩？（多选）

多选题 · easy

  • A.熔断快速失败← 正确答案
  • B.服务降级兜底← 正确答案
  • C.无限次重试下游
  • D.将线程池调到无限大

答案：AB。熔断切断故障传播，降级返回兜底结果，两者是防雪崩核心。无限重试和无限线程会放大故障，反而加速雪崩。

Q10. 关于限流算法，下列哪些说法正确？（多选）

多选题 · extreme

  • A.漏桶算法强制匀速流出← 正确答案
  • B.滑动窗口比固定窗口更平滑← 正确答案
  • C.令牌桶完全无法应对突发
  • D.固定窗口没有边界突刺

答案：AB。漏桶以恒定速率放行请求，天然匀速；滑动窗口把窗口细化，边界突刺更小。C 与令牌桶特性相反，D 否定了固定窗口最大短板，均错误。