想象你是一座大型游乐园的园长。开园第一天，用户们慕名而来，你的 LLM 应用就是园里最火的“过山车”——每次调用都要消耗 GPU 算力和真金白银的模型费用。游客太热情了，过山车每秒只能接待几个人，转眼涌入上千人：队伍越排越长，设备开始过热报警，维修工程师也淹没在故障里。此时你需要一套“园区的守护系统”：门口限流，控制进场节奏；设施熔断，坏了立刻停运检修；大屏监控，随时掌握全局。Sentinel 就是阿里开源的那套守护系统。它用令牌桶控制流量进入，用熔断器在服务异常时快速切断，用 Dashboard 让你像园长看指挥中心大屏一样，实时观察每个接口的“排队情况”、放行与拒绝曲线。这篇文章，我们就从游乐园的故事出发，把 Sentinel 限流熔断讲清楚。

岗位关联

掌握 Sentinel 限流熔断，你就能为 LLM 服务筑起一道生产级流量防线——这是大厂 AI 应用工程岗面试必考、线上故障救火必备的核心能力。

目录
  1. 可视化演示
  2. 限流基础概念
  3. 规则配置详解
  4. 流控策略设计
  5. 熔断降级保护
  6. 系统自适应保护
  7. 集群限流方案
  8. Dashboard监控告警
  9. 生产落地实践
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

动态演示Sentinel限流熔断的核心机制，通过总览/传输/转换/输出四种模式展示关键概念与交互流程。

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

Sentinel限流熔断：一Sen 一、Sentinel总览与LL 二、Sentinel规则配置与 核心机制可视化 Sentinel限流熔断整体架构与关键组件

限流基础概念

游客再多也不能无限制放进园。你在大门立下一块牌子：每秒最多放 10 人入园。为什么不是 100？因为园里的窄路、电梯、设施接待能力都有限，人一多反而谁都玩不上，体验更差。限流的本质是“可控的拒绝，好过无计划的崩溃”。

在 LLM 服务里，“游客”是一个个 HTTP 请求，“入园速度”就是 QPS（每秒请求数）。一个大模型接口的推理延迟通常在 2~5 秒，单实例并发能力有限；如果 QPS 超过承载上限，请求会排队超时、显存溢出，最后拖垮整条链路。限流就是在服务入口设一道闸，让进来的流量永远在承载能力以内。

常见的限流算法有三种。固定窗口计数器：每秒数一下请求数，超过阈值就拒绝，实现最简单，但窗口边缘会有“双倍突发”漏洞。令牌桶：一个桶每秒放入 r 个令牌，桶最多存 T_max 个，请求必须拿到令牌才放行，允许一定程度的突发。漏桶：不管进来多猛，出去的速度恒定，适合平滑流量。Sentinel 默认支持前两种，也是生产中最常用的两种。

讲完算法你会发现，选哪种限流方式就像选排队策略：令牌桶允许“攒票冲一次”，适合有突发特征的接口；漏桶则像匀速放行的旋转门，适合必须平稳的流。理解了这一点，后面看 Sentinel 的规则配置就有了地基。

Tt+Δt=min⁡(Tmax, Tt+r×Δt)\displaystyle T_{t+\Delta t} = \min\left(T_{max},\ T_t + r \times \Delta t\right)
每隔一小段时间，就往桶里补充 r 张“快速通行券”，但桶里最多攒 T_max 张，多出来的券作废。请求进来时如果没有券，就按策略拒绝或排队。
  1. 当前令牌数 T_t桶里现在剩下的入场券数量，初始满桶。
    TtT_t
  2. 补充速率 r每秒新放入券的个数，r 越大放行速度越快。
    Δt×r\Delta t \times r
  3. 桶容量 T_max攒券的上限，控制允许的突发量，桶满后新增的券丢弃。
    TmaxT_{max}
  4. 取最小值 min保证补充后的令牌数不会超过容量上限。
    min⁡(Tmax, Tt+rΔt)\min(T_{max},\ T_t + r\Delta t)

规则配置详解

牌子上写“每 3 秒 30 人”还不够，还要写清“哪个项目、什么时间、超了怎么办”。游乐园的限流不是一句口号，而是一张规则表。Sentinel 里这张表叫“流控规则”。

规则先要圈定保护对象——“资源”。资源可以是一个接口路径、一个方法或一段任意代码。比如把 POST /v1/chat/completions 定义成资源，再为它配置流控规则。规则的关键参数有：resource（资源名）、count（阈值）、grade（阈值类型：QPS 或并发线程数）、strategy（流控模式）、controlBehavior（控制行为）。规则最好持久化到 Nacos 或本地文件，避免服务重启后丢失。

规则执行逻辑就是实时统计流量并与阈值比较。每个资源有一个滑动窗口计数器，统计当前 QPS，当实际 QPS 达到或超过阈值时，触发限流策略。

规则表填得越细，守护越精准。就像游乐园会把限流精确到“过山车每小时 120 人”，而不是全园一个总数；Sentinel 的规则支持按资源、按来源甚至按调用关系拆分，这样不同业务线互不拖累。

1[Q^(t)≥L]⟹拦截\displaystyle \mathbb{1}\left[\hat{Q}(t) \ge L\right] \Longrightarrow \text{拦截}
当前实测 QPS 达到或超过阈值 L 时，规则生效，请求被拦截。
  1. 实测 QPS滑动窗口统计出的每秒实际请求数。
    Q^(t)\hat{Q}(t)
  2. 配置阈值 L你为资源设定的最大放行量。
    LL
  3. 比较判定实际值不小于阈值就触发拦截。
    Q^(t)≥L\hat{Q}(t) \ge L

流控策略设计

同样是“人太多”，游乐园不同场景处理方式不同：热门项目超员，保安直接劝返下一批；新开的项目游客不熟，先放少量人试玩再慢慢加量；等候区极小的项目，按固定节奏放人；两个项目共用一条通道时，一个排队会堵死另一个，需要关联管控。

这些策略在 Sentinel 里就是控制行为（controlBehavior）和流控模式（strategy）。控制行为有四种：直接拒绝（快速失败）、Warm Up（冷启动预热）、匀速排队（Pace），以及 Warm Up 与匀速排队的组合。流控模式则有直接、关联、链路三种。

冷启动预热：新服务刚启动，JIT 还没热、缓存还没到位，直接放满 QPS 容易压垮自己。Sentinel 让阈值从一个小值随时间线性爬升到目标阈值。匀速排队：把突发流量按固定间隔“摊平”，比如阈值 100 QPS 时每 10ms 放一个。关联流控则是在资源 A 与资源 B 共享底层容量时，用 B 的流量给 A 设上限，防止互相挤占。

选策略的本质，是回答“超了之后想让用户体验什么”。直接拒绝最干脆，但会损失部分请求；匀速排队把尖峰削平，适合能接受延迟的异步业务；预热则让新实例平安度过“新手期”。守护神不是只会拒绝，它懂得在什么场景用什么姿态。

Q(t)=Qtarget×min⁡(1, tTwarmup)\displaystyle Q(t) = Q_{target} \times \min\left(1,\ \frac{t}{T_{warmup}}\right)
启动后的 t 秒内，放行 QPS 从 0 逐步爬升；当 t 达到预热时长 T_warmup 时，达到目标阈值。
  1. 目标阈值 Q_target最终允许的满额 QPS。
    QtargetQ_{target}
  2. 已运行时间 t从规则生效起经过的秒数。
    tt
  3. 预热时长 T_warmup指定的升温窗口，比如 10 秒。
    TwarmupT_{warmup}
  4. 线性爬升t 小于预热时长时，放行量按比例放大，到点封顶。
    min⁡(1, t/Twarmup)\min(1,\ t / T_{warmup})

熔断降级保护

限流防的是“人太多”，熔断防的是“设备已坏”。想象过山车运行中发出异响：安全员的职责不是继续放人排队，而是立刻拉闸停运（熔断打开），让工程师检修；检修一段时间后，先放 5 个志愿者试坐（半开），如果安全回来，再全面开放（关闭）。

Sentinel 的熔断降级规则正是这个模型。它统计一段时间窗口内的慢调用比例或异常比例，当比例超过阈值（如 50%）时，熔断器从 CLOSED 切到 OPEN，之后所有请求快速失败，不再真正打到后端。OPEN 状态维持指定秒数后进入 HALF_OPEN，放少量探测请求验证服务是否恢复，成功则回到 CLOSED。

打开期间，请求可以走降级逻辑——返回兜底结果，比如固定文案或最近的缓存，而不是把异常抛给用户。这就像过山车检修期间，广播告知游客并赠送“下次免费券”，而不是让游客干等着看检修。

熔断是“宁可错杀，不可硬扛”。比起让 1000 个请求全部超时拖垮全局，熔断 5 秒、再半开试探，能让服务在几秒内自我修复。这也是 LLM 应用在与上游模型 API 抖动共舞时最需要的一层保险。

Perror=NerrorNtotal≥θ⟹OPEN\displaystyle P_{error} = \frac{N_{error}}{N_{total}} \ge \theta \Longrightarrow \text{OPEN}
统计窗口内，异常请求数占总请求数的比例达到阈值 θ，熔断器切换到打开状态。
  1. 异常计数 N_error窗口内返回异常或超时的请求数。
    NerrorN_{error}
  2. 总请求数 N_total窗口内进入统计的请求总数。
    NtotalN_{total}
  3. 异常比例 P_error前者除以后者，反映服务健康度。
    Perror=Nerror/NtotalP_{error} = N_{error} / N_{total}
  4. 触发阈值 θ如 0.5，达到即打开熔断，所有请求短路。
    ≥θ\ge \theta

系统自适应保护

规则人工定死，总有失手的时候。聪明的园区会装一套中央控制系统：实时感知全园人流和负载，负载一高就自动调低各项目放行速度，人少时再放快。这就是“系统自适应保护”。

Sentinel 的系统保护规则不是盯单个接口，而是盯整台机器的健康度：CPU 使用率、系统 Load（平均负载）、平均 RT、线程数、入口 QPS。当实时指标超过配置的阈值时，Sentinel 会自动计算并收紧入口 QPS，从源头掐住流量，而不是等每个接口各自崩溃。

核心思路是：当前负载越接近上限，允许通过的流量就越少。例如 CPU 使用率超过介入阈值 C0 开始介入，越接近标杆上限 C，入口 QPS 收缩得越狠。这保证服务始终工作在“快而不崩”的甜点区。

自适应保护像一位经验丰富的老园长——他不看死规则，而是看形势调阀门。突发流量来袭时，系统自动把入口收窄，保护整机；流量退去后，又悄悄放开，不影响正常生意。

Qallow=min⁡(Qlimit, Qlimit×C−CnowC−C0)\displaystyle Q_{allow} = \min\left(Q_{limit},\ Q_{limit} \times \frac{C - C_{now}}{C - C_0}\right)
实时 CPU 值 C_now 越接近标杆上限 C，允许的入口 QPS 按比例收缩；C_now 回落后，放行量自动恢复。
  1. 标杆上限 C系统规则的 CPU 目标上限，比如 80%。
    CC
  2. 介入阈值 C0CPU 超过它才开始保护，比如 60%。
    C0C_0
  3. 当前值 C_now实时采集的 CPU 使用率。
    CnowC_{now}
  4. 收缩比例用剩余安全余量除以可调区间，再乘上基础 QPS。
    (C−Cnow)/(C−C0)(C - C_{now}) / (C - C_0)

集群限流方案

游乐园有三个大门：东、西、南。假如每个门各自限流 1000 人，三个门可放进 3000 人，但全园总容量只有 2000——各自为政的结果是总量失控。要真正做到“全园限流”，需要一位总指挥，统一掌握三个门的放行配额。

Sentinel 的集群限流正是这个思路。多个服务实例不再各看各的本地计数器，而是统一向一个 Token Server（令牌服务器）申请令牌。Token Server 维护全局的集群 QPS 配额，实例每来一个请求就去申请，成功则放行，失败则拒绝。

集群限流有两种模式：集群模式（真正的全局协调）和伪集群模式（本地缓存配额，减少与 Token Server 的通信开销）。Token Server 支持独立部署或嵌入某实例，客户端通过配置连接即可。规则仍然在 Dashboard 统一管理、统一推送。

总指挥的存在，让“全局视角”成为可能。用户调用我们的大模型网关时，流量会分散到多个实例，只有集群限流才能保证“不管走哪个门，总量都不超”。这也是生产环境多实例部署时的刚需配置。

QPScluster=∑i=1nQPSi≤Lcluster\displaystyle QPS_{cluster} = \sum_{i=1}^{n} QPS_{i} \le L_{cluster}
集群所有实例的实时 QPS 之和，受全局阈值 L_cluster 约束。这是单机限流根本做不到的。
  1. 单机流量 QPS_i第 i 个实例当前的请求速率。
    QPSiQPS_i
  2. 实例总数 n集群中参与限流的实例个数。
    nn
  3. 累加总和把每个实例的流量加在一起，才是全局流量。
    ∑i=1nQPSi\sum_{i=1}^{n} QPS_i
  4. 集群阈值 L_cluster总指挥设定的全局限流值。
    ≤Lcluster\le L_{cluster}

Dashboard监控告警

守护神不仅要有手（限流、熔断），还得有眼睛。园长办公室的大屏上，实时滚动着客流曲线、每个设施的排队数、报警红灯。Dashboard 就是 Sentinel 送给你的这双眼睛。

接入 Sentinel Dashboard 后，你能在网页上看到每个资源的实时 QPS（通过/拒绝）、平均 RT、异常比例，以及簇点链路——一次完整调用经过了哪些资源、在哪里被限流或熔断。流量情况一目了然。

更强大的是，Dashboard 不只是只读的“眼睛”，还是能操作的“遥控器”：可以在界面上动态新增、修改流控规则和熔断规则，实时推送到客户端生效，不用重启服务；还可以配置告警，比如“拒绝 QPS 超过阈值”或“熔断打开”时通知钉钉、飞书。

有眼睛的守护神才让人安心。上线初期，盯着 Dashboard 观察红线是否逼近；大促时，看着流量曲线被削平；故障时，顺着簇点链路一眼定位被熔断的资源。可视化的价值，是让“流量防护”从玄学变成显学。

Ppass=QPSpassQPSpass+QPSblock\displaystyle P_{pass} = \frac{QPS_{pass}}{QPS_{pass} + QPS_{block}}
通过率 = 放行的 QPS 占总进入流量的比例，是大屏上最核心的健康指标之一。
  1. 通过 QPS被放行进入后端服务的请求速率。
    QPSpassQPS_{pass}
  2. 拒绝 QPS被限流或熔断拦下的请求速率。
    QPSblockQPS_{block}
  3. 对比得出通过率通过率骤降，往往说明限流生效或服务异常。
    PpassP_{pass}

生产落地实践

再好的游乐园管理制度，也要有一本运营手册：先摸底，再定规则，灰度试点，复盘迭代。Sentinel 落地也是这套动作。

第一步接入：引入依赖、定义资源、创建规则、启动 Dashboard。第二步压测：用压测工具打满单机，找到“延迟开始飙升”的拐点，这就是单机容量。第三步算阈值：单机容量 × 实例数 × 安全余量系数；不要顶格，给流量洪峰留缓冲。第四步灰度：先对次要接口启用规则，观察一两天，再推广到核心链路。

阈值不是一次定死的。每次大促前后都要复盘：限流拒绝率是否过高？熔断是否误伤？根据线上指标持续调整。另外注意规则持久化——把规则存到 Nacos 或本地文件，避免重启丢失。

守护神的养成，本质是持续调优的过程。没有一劳永逸的阈值，只有不断复盘总结的运维文化。把 Sentinel 当成运维团队的一部分，LLM 服务才能在高流量洪峰下稳稳接住每一个用户。

L=⌊Qsingle×n×β⌋,β∈(0.5, 0.8)\displaystyle L = \left\lfloor Q_{single} \times n \times \beta \right\rfloor,\quad \beta \in (0.5,\ 0.8)
集群限流阈值 ≈ 单机压测容量 × 实例数 × 安全系数。β 小于 1，给突发和故障留出缓冲。
  1. 单机容量 Q_single压测得到的单实例最大健康 QPS。
    QsingleQ_{single}
  2. 实例数 n参与承接流量的实例数量。
    nn
  3. 安全系数 β0.5~0.8，预留扩容和突发的余量。
    β\beta
  4. 向下取整保证阈值不超理论上限。
    ⌊⋅⌋\lfloor \cdot \rfloor

AI 应用场景

LLM 网关流量管控

阶段：应用部署与运维

解决的问题：大模型 API 调用昂贵且有并发限制。没有限流时，一次营销投放或爬虫突发，会把单次推理时间从 2 秒拖到 10 秒，甚至打爆上游模型配额。用 Sentinel 对整个 Gateway 层限流，按用户维度限量，超限直接拒绝或排队，保障核心用户体验。

具体案例：某智能客服 SaaS 上线后，一次投放带来的流量是平时的 20 倍，网关崩溃导致全量不可用。接入 Sentinel 后，为不同套餐用户分别配置 QPS 阈值，付费用户优先放行，免费用户超限返回“稍后再试”，系统在大促期间保持 99.9% 可用。

模型服务熔断降级

阶段：依赖治理与容错

解决的问题：LLM 应用通常依赖第三方大模型 API（OpenAI、通义等），上游抖动或限流会快速传导到你的服务。用熔断规则监控慢调用和异常比例，上游异常时快速短路并走降级——返回缓存答案或模板话术，避免线程池被拖垮。

具体案例：某 Agent 应用调用多家模型厂商，某厂商故障导致 P99 延迟从 3 秒涨到 60 秒。Sentinel 熔断在 10 秒内打开开关，流量自动切到备用模型，同时返回兜底提示，客服工单量并未上升。

集群统一管控

阶段：多实例规模化治理

解决的问题：多副本部署时，单机限流简单叠加会让总量超标。集群限流通过 Token Server 做全局配额协调，配合 Dashboard 统一监控和规则热更新，让 20 个实例像一个大园区一样有序放行。

具体案例：某大模型应用 20 个实例部署在 2 个可用区，配置集群限流后，全局 QPS 精确控制在目标值，Dashboard 实时展示各实例分流情况，运维人员一键调整阈值即可完成容量变更。

Python 演示

python104 行
# -*- coding: utf-8 -*-"""Sentinel 风格限流熔断模拟器 用令牌桶对 LLM 网关做限流，用熔断器保护后端模型服务。""" import timeimport random  class TokenBucket:    """令牌桶限流器：桶内有令牌才能放行"""     def __init__(self, capacity, refill_rate):        self.capacity = capacity           # 桶容量：最多攒几张令牌        self.refill_rate = refill_rate     # 每秒补充几张令牌        self._tokens = capacity        self._last = time.time()     def try_acquire(self):        now = time.time()        self._tokens = min(            self.capacity,            self._tokens + (now - self._last) * self.refill_rate        )        self._last = now        if self._tokens >= 1:            self._tokens -= 1            return True        return False  class CircuitBreaker:    """熔断器：失败比例超阈值打开，半开时放少量探测请求"""     def __init__(self, fail_threshold=0.5, open_seconds=5,                 half_open_max=5):        self.fail_threshold = fail_threshold        self.open_seconds = open_seconds        self.half_open_max = half_open_max        self.state = "closed"              # closed / open / half_open        self.total = 0                     # 窗口内总请求数        self.fails = 0                     # 窗口内失败请求数        self.opened_at = 0.0        self.half_tests = 0                # 半开阶段已探测次数     def allow(self):        if self.state == "closed":            return True        if self.state == "open":            if time.time() - self.opened_at >= self.open_seconds:                self.state = "half_open"                self.half_tests = 0                return True            return False        # half_open 状态        if self.half_tests >= self.half_open_max:            return False        return True     def record(self, ok):        if self.state == "closed":            self.total += 1            if not ok:                self.fails += 1            if self.total >= 10 and self.fails / float(self.total) >= self.fail_threshold:                self.state = "open"                self.opened_at = time.time()        elif self.state == "half_open":            self.half_tests += 1            if not ok:                self.state = "open"                self.opened_at = time.time()            else:                self.state = "closed"                self.total = 0                self.fails = 0  def main():    random.seed(42)    bucket = TokenBucket(capacity=8, refill_rate=5)    breaker = CircuitBreaker(fail_threshold=0.4, open_seconds=5)    passed = blocked = failed = 0    for i in range(100):        time.sleep(0.01)        if not bucket.try_acquire():       # 限流：没令牌直接拦截            blocked += 1            continue        if not breaker.allow():            # 熔断：打开期间快速失败            blocked += 1            continue        ok = random.random() > 0.35        # 模拟调用后端 LLM        breaker.record(ok)        if ok:            passed += 1        else:            failed += 1    print("放行:", passed, "失败:", failed, "被拦截:", blocked,          "熔断状态:", breaker.state)  if __name__ == "__main__":    main()
目的：模拟一个 LLM 网关的“令牌桶限流 + 熔断器”组合逻辑，跑完能看到 100 个请求中多少被放行、多少被拦截，以及熔断器最终停在什么状态。
  1. self._tokens = min(self.capacity, self._tokens + (now - self._last) * self.refill_rate)按时间差补充令牌，复现公式 min(T_max, T + rΔt) 的核心逻辑。
  2. if self._tokens >= 1:有令牌才放行，这是令牌桶的判定核心。
  3. if self.total >= 10 and self.fails / float(self.total) >= self.fail_threshold:统计窗口内失败比例达到 40%，熔断器切换到打开状态。
  4. if time.time() - self.opened_at >= self.open_seconds:打开时间满 5 秒后自动进入半开（half_open）试探。
  5. breaker.record(ok)每次调用后回报成功/失败，驱动熔断状态机流转。

常见误区

误区既然已经做了限流，服务就不会被打挂了，熔断可有可无。限流和熔断听起来都是拒绝请求，效果应该一样。

正解限流是“防患于未然”，控制还没进来的流量；熔断是“亡羊补牢”，在下游已经出问题时快速切断。限流挡在入口，熔断挡在故障门前。游乐园里，限流是门口控制人数，熔断是过山车故障时立刻停运检修——两者时机不同，缺一不可。

为何常见：两者最终都表现为“拒绝请求”，初学者只看现象不看时机，很容易混淆。

误区压测得 300 QPS，我就把阈值设到 300，充分利用每一分机器资源，别浪费。

正解压测 300 QPS 是在理想条件下的数字，真实世界有突发叠加、GC 停顿、上游抖动，顶格阈值等于让游乐园满负荷运转，旺季一来直接过载雪崩。实践上一般取压测容量的 50%~80%，并配合熔断兜底。

为何常见：人都有“物尽其用”的心态，而且阈值设大在低峰期确实看不出问题，容易踩坑。

误区熔断一打开，我就马上重试几次看看服务恢复没有，恢复了好赶紧接流量。

正解打开期间持续重试，等于继续打爆本就脆弱的下游，反而拖慢恢复。正确做法是等熔断器自动进入半开状态，放少量探测请求确认健康后再恢复。半开就是“先让 5 个志愿者试坐，再决定开放还是继续检修”。

为何常见：故障时人容易焦虑，本能地想“试一下”，忽略了快速重试的放大效应。

误区10 台机器每台限 50 QPS，一共就能扛 500 QPS，这不就是集群限流吗？

正解这是单机限流的简单叠加。如果下游总容量只有 300 QPS，10×50=500 早已超限。集群限流必须引入 Token Server 做全局配额协调，保证“所有入口之和”不超过总阈值。三个大门各自放进 1000 人，不等于全园能装 3000 人。

为何常见：长期单机部署形成的思维惯性，习惯用“每台一个数”估算总量，缺少全局协调视角。

误区Dashboard 就是看看曲线，要改规则还得改代码、重新发布。

正解Sentinel Dashboard 支持规则热更新和动态推送：在界面上新增、修改限流和熔断规则，实时下发到客户端生效，无需重启。它既是“眼睛”也是“遥控器”，故障应急时像在园长室一键调闸。

为何常见：很多监控系统确实只读，容易把同类工具的刻板印象套过来。

面试题

Q1. Sentinel 令牌桶算法中“桶容量”指什么？

单选题 · easy

  • A.每秒最大请求数
  • B.桶内最大令牌数← 正确答案
  • C.服务实例总数
  • D.请求超时时间

答案：B。令牌桶的容量指桶内最多能积累的令牌数，控制允许的突发量，就像游乐园快速通道最多攒几张券。A 是补充速率决定的，C 是部署规模，D 与令牌桶无关。

Q2. 熔断器“半开”状态的作用是什么？

单选题 · easy

  • A.直接永久拒绝请求
  • B.停止一切流量监控
  • C.放行少量请求试探← 正确答案
  • D.自动扩容后端实例

答案：C。半开（HALF_OPEN）状态放少量探测请求验证下游是否恢复，像过山车检修后先让 5 个志愿者试坐。A 是打开状态的表现，B、D 都不是熔断器的工作内容。

Q3. 冷启动预热（Warm Up）的阈值变化规律是？

单选题 · mid

  • A.从高阈值逐步降低
  • B.始终保持固定阈值
  • C.从低阈值升至目标← 正确答案
  • D.按随机值来回波动

答案：C。Warm Up 让阈值从低值随时间线性爬升到目标阈值，避免新实例刚启动就被打满，像新项目先放少量人试玩再慢慢加量。A、B、D 都不符合预热语义。

Q4. 系统自适应保护中，CPU 使用率超过设定阈值时 Sentinel 会怎么做？

单选题 · mid

  • A.立即重启整个服务
  • B.提高令牌补充速率
  • C.按比例降低入口流量← 正确答案
  • D.强制关闭熔断保护

答案：C。系统保护按比例收缩入口 QPS，让服务始终工作在“快而不崩”的区间，像老园长根据全园负载调小阀门。重启、提速、关熔断都不是保护手段。

Q5. 集群限流与单机限流最大的区别是什么？

单选题 · mid

  • A.集群限流不消耗资源
  • B.单机限流更加精准
  • C.只能在容器环境使用
  • D.做全局配额统一协调← 正确答案

答案：D。集群限流通过 Token Server 做全局配额协调，保证所有实例的总量不超限，好比总指挥统一管三个大门。A、C 说法错误，B 不是区别点。

Q6. 慢调用比例触发熔断时，统计的是什么？

单选题 · mid

  • A.服务进程启动耗时
  • B.网络带宽占用比例
  • C.请求响应超时的占比← 正确答案
  • D.数据库连接的数量

答案：C。慢调用比例统计响应时间超过阈值的请求占比，达到配置值就打开熔断。A 是启动时间，B、D 与慢调用无关。

Q7. 使用匀速排队策略且阈值设为 100 QPS 时，大约多久放行一个请求？

单选题 · hard

  • A.约 10 毫秒放行一个← 正确答案
  • B.约 100 毫秒放行一个
  • C.约 1000 毫秒放行一个
  • D.间隔完全不固定

答案：A。匀速排队把 1 秒均分给 100 个请求，间隔 = 1000ms / 100 = 10ms。这像旋转门按固定节奏放人，把突发流量削平，而不是让游客一口气涌进。

Q8. 以下哪些属于 Sentinel 流控规则的配置参数？

多选题 · mid

  • A.资源名与统计维度← 正确答案
  • B.阈值与流控模式← 正确答案
  • C.控制行为的选择← 正确答案
  • D.数据库连接信息

答案：ABC。流控规则包含资源名、阈值、阈值类型、流控模式、控制行为等，相当于游乐园规则表上的各个栏目。数据库连接信息是基础设施配置，不属于流控规则。

Q9. 熔断器包含哪些状态？

多选题 · easy

  • A.熔断关闭状态← 正确答案
  • B.熔断打开状态← 正确答案
  • C.半开试探状态← 正确答案
  • D.深睡待机状态

答案：ABC。熔断器三态是关闭（CLOSED）、打开（OPEN）、半开（HALF_OPEN），对应过山车的正常运行、停运检修、试运行。D 只是干扰项。

Q10. 生产上确定限流阈值时，需要考虑哪些因素？

多选题 · hard

  • A.压测单机容量← 正确答案
  • B.服务实例数量← 正确答案
  • C.安全余量系数← 正确答案
  • D.前端页面配色

答案：ABC。阈值 = 单机压测容量 × 实例数 × 安全系数 β（0.5~0.8），要给突发流量和故障留缓冲。配色与容量规划无关。