Sentinel 流控规则：QPS/并发线程与流控效果

流控（流量控制）是 Sentinel 最核心的能力：为资源设定阈值，超出部分的请求被拦截，避免系统过载。配一条规则只需要回答三个问题：按什么统计（阈值类型）、在什么范围内生效（流控模式）、超限后怎么办（流控效果）。

阈值类型：QPS 还是并发线程数

QPS 阈值统计"每秒通过的请求数"，直观、适合绝大多数接口场景，例如某接口 QPS 上限 200。并发线程数阈值统计"正在处理该资源的线程数"，例如上限 20：当处理不过来时线程数积压到 20，新请求直接被拒，不再排队占用线程。两者的本质区别是"限速率"还是"限并发占用"。QPS 适合限流接口频率，并发线程数适合保护线程池与慢接口场景——慢接口用 QPS 限制效果有限（请求进来就占住线程慢慢响应），用并发线程数限制能直接把"正在处理中的慢请求"控制在阈值内。两者可同时配置，先到先拦。

在控制台配置第一条规则

进入"流控规则"，新增规则并选择资源（簇点链路里出现的接口即资源名，例如 GET:/api/order/list），设置阈值类型 QPS、单机阈值 10，点击新增即可。随后用压测工具或快速刷新触发验证：超出后请求立即被拒绝，响应里出现 Blocked by Sentinel (flow limiting) 的提示（默认返回 429 状态，由框架处理）。同一实例上规则立即生效，无需重启。

流控模式：直接、关联、链路

直接模式只统计资源自身的流量，最简单常用。关联模式统计"另一个资源"的流量来控制当前资源，典型场景：写接口（如 /order/update）流量大了会拖慢读接口（/order/list），可以给读接口配关联规则，统计写接口 QPS 超过阈值时限制读接口，优先保证读体验。链路模式按调用来源（入口）分别统计，例如同一个公共方法被 A、B 两个入口调用，只想限制 A 的流量，需要把该方法做成资源并开启调用链入口配置；链路模式涉及上下文埋点，使用前请阅读官方文档确认配置项。

流控效果：快速失败、预热、排队等待

快速失败：超限立即拒绝，最常用。预热（Warm Up）：阈值从"冷启动值"逐渐爬升到设定值，适合缓存刚重建、需要时间暖起来的系统，避免刚重启就被打满。排队等待：超限请求进入队列匀速放行，适合削峰填谷的异步型接口（如消息批量处理），需设置超时时间，队列满或等待超时才拒绝。效果的选择取决于业务能否接受"等待"：同步查询接口等不起，选快速失败；后台任务类接口可以排队。

代码方式加载规则

规则也可以代码加载，适合启动初始化或测试：

FlowRule rule = new FlowRule();
rule.setResource("GET:/api/order/list");
rule.setGrade(RuleConstant.FLOW_GRADE_QPS);
rule.setCount(10);
FlowRuleManager.loadRules(Collections.singletonList(rule));

生产环境不推荐代码硬编码规则，规则应由控制台/配置中心统一管理（推送与持久化方式以官方文档为准），代码加载主要用于测试与特殊引导场景。

阈值怎么定：从压测数据出发

别拍脑袋填阈值，建议按三步走：

• 压测基线：用压测工具测出接口在目标响应时间内的最大吞吐，作为初始阈值的依据（压测思路见本书后半部分专题）；
• 留出余量：生产阈值通常取基线的七到八成，给流量尖峰留缓冲，避免正常波动就被拦截；
• 灰度观察：先小流量上线，观察 Blocked 量与业务错误率，若误杀偏高再逐步上调。

阈值是动态的：业务重构、缓存命中率变化都会改变接口的真实容量，定期用新压测数据校准比一次定死更可靠。

规则治理：资源与规则都有生命周期

资源在首次访问时自动创建，规则常驻应用内存，需要纳入治理：

• 接口下线后及时清理对应规则与资源，避免僵尸规则占用内存、或在将来同名的接口上误伤；
• 规则变更要能回溯：控制台操作留痕，定期把规则导出备份到配置中心，作为灾难恢复与审计依据；
• 规则要联动告警：Blocked 量突增说明阈值过紧或流量异常，应触发告警而不是被静默丢弃。

流控规则的来源与持久化

规则从哪里来，决定它好不好管、重启丢不丢：

• 控制台点选：开发联调阶段最直观，规则下发到应用内存，应用重启即丢失，不能作为生产常态；
• 代码加载：用 FlowRuleManager.loadRules 初始化规则，适合测试与引导场景；生产硬编码会让规则散落在代码里，难以统一调整与审计；
• 配置中心持久化：把规则做成配置数据，通过规则数据源（Spring Cloud Alibaba 支持 Nacos 等）推送到 Sentinel，实现"规则集中管理、重启不丢、变更可回溯"，接入方式以官方文档为准。

与网关限流的分工

限流职责要分层，两层各管一段，互不替代：

• 网关限流（第 10 章 RequestRateLimiter）挡"入口总量"：刷量与突发流量在进入业务服务前被拦下，保护入口带宽与整体资源；
• Sentinel 流控管"服务实例容量"：贴近各服务、各实例的真实处理能力，防止单实例过载拖垮进程；
• 两层可叠加使用，但要注意总量关系：网关限额应高于后端期望容量，否则后端永远跑不满，限流就失去了弹性。

常见误区与排障

第一，QPS 是"每实例独立统计"的，3 个实例各限 100，总量其实是 300；需要全局精确限额时要了解集群流控（需独立的 token server，以官方文档为准）。第二，规则不生效先查：应用是否出现在控制台机器列表、资源名是否一致（含 HTTP 方法与路径）、是否多个 namespace 串扰。第三，Dashboard 下发的规则存在内存，重启丢失是预期行为，别当成 Bug，持久化方案见官方文档。

小结

流控规则=阈值类型（QPS/并发线程数）× 流控模式（直接/关联/链路）× 流控效果（快速失败/预热/排队）。先从"每接口 QPS + 快速失败"起步，再针对慢接口补并发线程数规则，逐步完善。流控管住"自己"，下一章解决"坏邻居"——熔断降级。