尧图网站建设 
做高并发系统绕不开流量控制这个问题。我维护的订单服务每逢大促和秒杀QPS能从几百冲到上万早期用固定阈值写死限流被热点流量打爆过好几次。后来把Sentinel的流控规则QPS/线程数、热点参数限流、系统自适应保护这三件事完整落地才算是把流量治理这件事想明白了。这篇不是照着官方文档念概念而是把我在生产环境里配置Sentinel限流配置时踩过的坑、调过的参数、验证过的方法按实操链路整理出来给正在折腾Sentinel的同行一个可直接参考的版本。1. 先从流量控制的思路说起Sentinel的定位不是“一个计数器”而是一套完整的流量防卫体系。它的核心模型是“资源规则”资源就是你要保护的接口、方法或网关路由规则就是针对资源定义的流控策略。你可以对同一个资源叠加多条规则也可以把多个资源串成链路做精细管控。相比手写限流它最大的价值是把流量统计、阈值判断、拒绝逻辑、控制台预览全链路打通改规则不用发版本实时生效。很多人刚接触Sentinel容易纠结一个点到底该用它的流控规则还是用RedisLua自己写一个分布式限流我的理解是如果只是给一个简单接口压一下峰值RedisLua够用但业务一旦复杂起来比如同一个接口被多个上游调用、某个参数值特别热、系统整体负载高要全局兜底自己造轮子成本就很高了。Sentinel把这几类场景都内置成了规则类型所以本文重点聊的QPS/线程数、热点参数限流、系统自适应保护正是对应了接口维度、参数维度、系统维度这三层流量治理。1.1 Sentinel和Hystrix的区别用过Hystrix的同学熟悉线程池隔离和信号量隔离它主要解决的是“依赖故障别拖垮我”的问题。Sentinel则更侧重“流量太猛别打死我”两者思路不一样。Hystrix的信号量隔离本质上是限制并发Sentinel的流控规则可以按QPS做时间维度的速率控制也可以按并发线程数做资源维度控制粒度更细。再加上热点参数限流和系统自适应保护这两类Hystrix没有的能力Sentinel在高并发网关和核心链路治理上更顺手。还有一个实用层面的区别Hystrix的规则默认静态配置为主想动态调整要么改代码重启要么额外开发配置中心对接。Sentinel天生支持从Nacos、Apollo、Redis等外部数据源动态加载规则控制台还能实时查看每个资源的流量曲线。生产环境里“规则可动态调整”几乎是刚需这也是我最终选型Sentinel的重要原因。1.2 Sentinel的Slot Chain设计想排查“规则为什么不生效”必须了解Sentinel的执行链。每个资源被调用时会经过一系列SlotNodeSelectorSlot维护调用树ClusterBuilderSlot维护集群节点统计StatisticSlot做实时指标统计FlowSlot执行流控规则DegradeSlot执行熔断降级ParamFlowSlot执行热点参数限流SystemSlot执行系统自适应保护。这个顺序解释了几个现象统计先行、规则判断在后所以规则判断用的都是上一个时间窗口的数据某个Slot如果异常后续Slot基本不会执行。遇到“阈值明明没到却被拦截”优先怀疑是不是多个Slot叠加判断导致比如接口自带流控规则同时又命中了系统保护规则。很多诡异问题追根溯源最后都落在Slot之间的配合上。2. Sentinel流控规则QPS和线程数怎么选流控规则是Sentinel最基础也最常用的能力核心是FlowRule。配置一条流控规则需要搞清楚的第一个决策就是阈值类型选QPS还是线程数。QPS模式很好理解就是每秒最大通过请求数超过阈值直接拒绝适合读多写少、响应时间稳定的接口比如商品查询、配置拉取。线程数模式限的是并发处理中的线程数量同一时刻最多允许多少个线程并行处理该资源适合响应时间波动大、依赖外部服务或者数据库连接的接口。一个RT响应时间200ms的接口如果QPS限制1000理论上并发也就200但实际上大量线程可能阻塞在慢调用上线程一堆积后面的请求全部排队所以慢接口用并发线程数来保护更直接。这里有个常见误区很多人把QPS当成“并发量”来配比如觉得“我能撑100并发就限100 QPS”这是错位理解。QPS是速率线程数是水位。判断该用哪个建议直接问自己一个问题这个接口的RT是否稳定RT稳定的接口用QPS更直观RT波动大的接口用并发线程数更安全因为它限制的是“同时占用线程资源的数量”而不是“每秒放进来多少”对下游的连接池、线程池更友好。2.1 流控模式直接、关联、链路确定了阈值类型下一步是选流控模式FlowRule里的strategy字段控制。默认的“直接”模式只针对当前资源本身做统计超过阈值就拦当前资源简单粗暴适合绝大多数接口兜底。“关联”模式针对的是两个有主次关系的资源。经典的场景是“读多写少保护写”当关联资源比如读接口的QPS超过阈值时对当前资源比如写接口启动限流目的是优先保证读接口可用牺牲一部分写流量。配置时要指定refResource为关联资源名统计维度和当前资源隔离各自保留各自的统计节点。“链路”模式是针对调用来源的精细控制。同一个资源可能被多个入口调用比如订单详情接口既被App端调用又被内部定时任务调用你只想限制定时任务这一路流量。此时需要把资源按调用链拆开并设置web-context-unify为false让每个入口生成独立的调用上下文。链路模式能精准限制“从某个入口进来”的流量不会误伤其他来源但配置成本也高需要前端埋点配合ContextUtil.enter做好链路透传否则上下文串了规则会失效。2.2 三种流控效果的适用场景controlBehavior字段决定超阈值后的表现方式三种效果对应三种不同的算法思想。快速失败CONTROL_BEHAVIOR_DEFAULT最直白一旦超出阈值直接抛出BlockException。它的好处是响应快、实现简单、不会堆积请求坏处是流量曲线是“砍头式”的短暂突发流量会被一刀切适合对延迟极其敏感、不希望排队拖慢的核心接口。预热模式WARM_UP解决的是“冷系统被热流量直接打瘫”的问题。系统刚启动时缓存是空的、连接池是冷的如果立刻放行大量流量很可能瞬间压垮依赖。预热会从低阈值开始放行逐步逼近设定阈值。默认冷启动因子coldFactor是3也就是说初始阈值是最终阈值的三分之一比如设QPS阈值3000刚启动时只放1000 QPS经过warmUpPeriodSec配置的时间比如20秒慢慢升到3000。这个模式对重启后的服务、缓存重建场景特别有用。匀速排队RATE_LIMITER本质是漏桶算法请求先放入队列以固定的速率逐个通过排队时间超过maxQueueingTimeMs的请求会直接丢弃。它能把突发流量整形为平稳流量适合削峰填谷典型场景是消息推送、订单回调这类可以接受几秒延迟的业务。缺点很明显如果业务要求高实时性排队带来的延迟不可接受而且队列本身会占用内存长时间占不满时阈值形同虚设。2.3 阈值怎么拍别拍脑袋要压测流控规则配置里最没把握的是阈值设多少。我见过不少项目上线前直接把阈值写成1000、5000这种“感觉值”结果大促第一波流量就直接全拒或者阈值设太高根本没起到保护作用。更靠谱的做法是先压测再设阈值。压测时从低并发开始逐渐加压记录每个阶段的QPS、P99 RT、错误率、CPU使用率找到“RT明显上涨”或者“错误率开始抬头”的拐点这个拐点就是服务的容量上限。生产阈值建议保守一点参考“拐点值×0.8”或者“预估峰值×1.2取小值”。比如压测结果显示最大可支撑800 QPS预估峰值流量是500 QPS那么线上阈值可以先设600 QPS留出缓冲同时盯着监控在白天逐步调优而不是一步到位。这句经验值很重要限流阈值不是一次配完就完事它应该是一个动态值。大促期间临时调低常态运行时逐步调高需要一套可动态调整规则的手段这就是后面第5章要说的规则持久化和数据源。2.4 代码配置一条QPS流控规则开发环境调试流控规则可以直接用FlowRuleManager加载规则不需要启动控制台Configuration public class SentinelRuleConfig { PostConstruct public void initFlowRules() { FlowRule rule new FlowRule(); rule.setResource(order:create); // 按QPS限流 rule.setGrade(RuleConstant.FLOW_GRADE_QPS); rule.setCount(1000); // 直接模式 rule.setStrategy(RuleConstant.STRATEGY_DIRECT); // 快速失败 rule.setControlBehavior(RuleConstant.CONTROL_BEHAVIOR_DEFAULT); FlowRuleManager.loadRules(Collections.singletonList(rule)); } }注意几点resource的名称必须和被保护点一致如果接口是Spring MVC的URL路径资源名默认是请求路径如果是自定义方法需要用SentinelResource注解指定资源名。FlowRuleManager.loadRules是整表替换逻辑意思是每次调用都会用新列表覆盖旧规则所以多规则建议一次性组装好List再加载别一条条去调。生产环境通常不会用代码硬编码规则而是走数据源动态加载。但理解这段代码的字段语义对接下来的控制台配置、Nacos配置字段都会很有帮助因为JSON格式里grade、strategy、controlBehavior这几个字段和代码是一一对应的。3. 热点参数限流把额度花在刀刃上流控规则有一个先天不足它只能对“资源整体”做限制区分不了请求里的参数值。商品详情接口普通商品每秒100个请求热门商品每秒几千个请求如果用流控规则把整个接口限制在2000 QPS热门商品一个请求可能就把额度吃掉一大半普通商品反而被误伤。热点参数限流就是来解决这个问题的。它按照“请求参数的具体值”做统计和限流比如配置paramIdx0也就是第一个参数作为维度那么Sentinel会按第一个参数的值分别统计QPS。参数值是sku_001的请求有自己的计数器参数值是sku_002的请求也有自己的计数器互不影响。这样就能做到普通参数值限制100 QPS热门参数值独立提升到5000 QPS谁热就精准管控谁。3.1 热点规则配置与参数索引配置热点规则用的是ParamFlowRule核心字段是resource、paramIdx和count。paramIdx表示你要针对请求的第几个参数做维度从0开始。假设你的方法签名是queryGoods(String skuId, Long userId)想按skuId限流paramIdx就是0想按userId限流paramIdx就是1。这里有容易踩的坑paramIdx是从0开始的数组下标很多同学下意识把第一个参数写成1结果规则加载成功但永远不生效。还有一个坑是参数类型不匹配热点规则在做参数值统计时是按类型区分的如果你的方法参数是Long类型但rule里配置的paramType没对上或者从HTTP请求参数里解析出来的字符串和对象类型对不上也会出现“规则加了但拦不住”的情况。配置示例ParamFlowRule hotRule new ParamFlowRule(); hotRule.setResource(goods:query); // 针对第一个参数skuId做统计 hotRule.setParamIdx(0); // 默认针对任意参数值限制100 QPS hotRule.setCount(100); // 精确参数例外项当skuId等于sku_100001时单独给5000 QPS ParamFlowItem special new ParamFlowItem(); special.setParamType(String); special.setParamValue(sku_100001); special.setCount(5000); hotRule.setParamFlowItemList(Collections.singletonList(special)); ParamFlowRuleManager.loadRules(Collections.singletonList(hotRule));注意ParamFlowItem用于配置“参数例外项”也就是针对特定参数值单独放大或缩小阈值。paramValue必须和实际请求中的参数值类型一致比如请求里传的是字符串“sku_100001”paramType就是StringparamValue就是sku_100001。3.2 热点参数的例外项和兜底策略这里顺便展开讲一下例外项逻辑如果某个参数值命中了paramFlowItemList里的精确项就使用精确项里的count作为该参数值的阈值如果没命中任何精确项就用规则上层的count作为默认阈值。也就是说默认阈值是兜底用来限制绝大多数参数值例外项是放量给重点参数值更高的额度。这套机制特别适合秒杀场景。秒杀商品详情接口所有商品共用接口但只有活动商品需要高并发放行。配置一个默认count100的兜底规则再给秒杀商品id配一条count5000的例外项平时流量轻松通过秒杀流量来了也顶得住。反过来如果某个参数值是爬虫重点抓取的对象你也能把它配成例外项并设置一个低于默认值的阈值做到精准打压。需要特别补充的是热点参数限流目前只支持QPS模式不支持线程数限流流控效果也只支持快速失败不支持预热线速和匀速排队。这是官方明确的能力边界在控制台配置时会发现可选选项就是有限的如果你从网上教程里看到“热点参数也能排队等待”的说法那多半是把流控规则和热点规则搞混了。3.3 热点限流的使用经验我实际用下来热点参数限流最适合的三个场景是按用户ID限流防刷、按商品ID/店铺ID做精细化流量管控、按订单号保护下游查询。但真正落地时有一个前置条件被限流的方法必须能通过Sentinel识别到参数。如果用的是Spring MVC接口Sentinel内置支持从请求参数里提取参数值如果自定义方法请结合SentinelResource注解声明资源名并保证参数类型一致。还有一种情况需要自定义参数提取器。比如入参是包装对象OrderQuery里面有个字段shopId热点规则默认没法解析“对象里的某个字段”。Sentinel提供了ParamRequestorAdapter扩展点可以实现从对象中提取特定字段。这个场景在复杂业务里经常遇到官方文档提得比较少我在对接旧项目时专门为参数封装写过一次适配器才把热点规则用起来。4. 系统自适应保护从单点限流到全局兜底流控规则和热点参数限流解决的都是“某一个资源”的问题但系统是一个整体。如果一个服务实例上同时跑着几十个接口每个接口都配了2000 QPS的限额合起来可能是几万QPS直接把CPU和内存打满。这时候单独看任何一个接口都没超阈值但整个机器已经快不行了。系统自适应保护就是给整个进程装上的“最后一道安全阀”。它借鉴了TCP拥塞控制的思路不再只是机械地对单个资源计数而是根据系统整体指标动态判断当前状态如果系统已经过载就直接对入口流量进行全局拦截。Sentinel官方叫它“自适应”主要是因为阈值判断会结合系统容量和实时的流量形态不是简单的一刀切。4.1 触发器指标详解系统自适应保护的规则由SystemRule承载支持五类指标可以在一个SystemRule里同时配多个highestSystemLoad系统1分钟负载load值仅在Linux/Unix类系统上有效。设置要根据机器核数来评估比如4核机器设4.0表示load超过4就认为系统过载。highestCpuUsageCPU使用率取值范围0到1比如0.8表示CPU使用率超过80%触发系统保护。相比load它在容器环境下更可靠。avgRt所有入口流量的平均响应时间超阈值触发保护用于防止系统因慢调用堆积而整体崩溃。maxThreads所有入口流量的并发线程总数超过阈值触发保护相当于全局的线程并发上限。qps所有入口流量的总QPS超过阈值触发保护相当于一个全局的总入口限流。这里的“入口流量”指的是Dashboard上的入口资源通常是网关路由入口或者Spring MVC的根路径不是某个具体的业务接口。如果某个服务只被内部RPC调用没有走HTTP入口系统保护依然能作用于所有统计到的入口调用但建议结合实际的入口梳理清楚否则会漏掉部分流量。4.2 系统规则配置代码示例开发阶段可以直接用SystemRuleManager加载系统规则SystemRule sysRule new SystemRule(); // load阈值按机器核数评估 sysRule.setHighestSystemLoad(4.0); // CPU使用率80%触发 sysRule.setHighestCpuUsage(0.8); // 入口平均RT不超过1000ms sysRule.setAvgRt(1000); // 全局并发线程不超过500 sysRule.setMaxThreads(500); // 入口总QPS不超过20000 sysRule.setQps(20000); SystemRuleManager.loadRules(Collections.singletonList(sysRule));注意这些阈值都是针对单机维度的不是集群维度。如果服务开了多个实例每个实例会独立判断自己的系统指标所以配置时要按单机容量来算别把集群的总量除以实例数指望系统帮我们分摊。比如集群总QPS承载是6万三台机器一台2万系统规则qps就配20000不是60000。实际生产经验是系统自适应保护指标的设定宁低勿高。因为它的触发代价是“所有入口流量都被拦截”影响面比单个接口的流控大得多。我通常先按CPU使用率0.7-0.8、load不超过核数来设一个保守值看监控曲线稳定后再逐步放宽绝不会把阈值顶到压测极限留20%余量是底线。4.3 和流控规则怎么分工说了半天系统自适应保护容易给人“规则越多越好”的感觉实际不是。我倾向于把系统自适应保护当作最后一道防线而不是日常限流的主力。日常限流还是靠具体的流控规则和热点参数限流因为它们作用面小、逻辑可控、误伤范围有限。系统自适应保护只在机器整体指标异常时才介入比如CPU飙到90%、load严重超标时全局拦一波给系统喘口气。两层规则的正确分工是流控规则管“单个接口别超量”热点参数限流管“特殊参数值别过载”系统自适应保护管“整个进程别被打垮”。三者互不替代协同生效。排查问题时如果发现某次拦截来自系统保护而非具体流控规则也别惊讶说明系统自己已经先“求救”了优先级反而是调低其他资源的流量。5. 规则持久化与数据源集成Nacos和Redis实操到这里三种限流能力的原理和用法都讲透了。但还有个问题没解决这些规则都存在哪如果只是通过Dashboard控制台手动配置规则是存在Sentinel客户端内存里的服务一重启规则全没了。生产环境要是这样每次重启都要人工重新配一遍规则出了故障根本没法追溯。更常见的是规则要跟随环境变化动态调整大促前批量更换阈值没有配置中心根本做不了。所以规则持久化是生产落地的前提。数据源的核心概念是通过DataSource把规则存储到外部介质Nacos、Redis、Apollo、ZK等客户端启动时读取运行期间根据配置中心的变动实时更新规则。Sentinel支持两种模式PULL模式是客户端定时去外部存储拉取规则实现简单、有延迟PUSH模式是配置中心主动推送规则变更到客户端实时性好但需要Dashboard和控制台配合改造。5.1 Nacos数据源配置样例Spring Cloud Alibaba环境下最顺手的方案是用Nacos做规则持久化。步骤分三步引入依赖、配置数据源、在Nacos里放规则。第一步Maven依赖加入sentinel-datasource-nacosdependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-sentinel/artifactId /dependency dependency groupIdcom.alibaba.csp/groupId artifactIdsentinel-datasource-nacos/artifactId /dependency第二步在application.yml里声明数据源。这里需要区分不同规则类型每种规则类型对应一个数据源标识spring: cloud: sentinel: transport: dashboard: 10.0.0.11:8858 datasource: flowNacos: nacos: server-addr: 10.0.0.12:8848 >[ { resource: order:create, limitApp: default, grade: 1, count: 1000, strategy: 0, controlBehavior: 0, warmUpPeriodSec: 20 } ]字段和前面代码里一一对应grade代表阈值类型0是线程数1是QPSstrategy是流控模式0直接、1关联、2链路controlBehavior是流控效果0快速失败、1预热、2匀速排队。warmUpPeriodSec只有在预热模式下才有意义。配置完成后启动服务时会自动从Nacos拉取规则Nacos里的配置变更后客户端会自动感知并更新规则。这个方案省掉了手动登录Dashboard反复配置的麻烦也方便把规则纳入Git仓库做版本管理。5.2 Redis数据源与集群场景小结如果团队没有Nacos/Apollo这类配置中心Sentinel也支持用Redis做规则数据源属于轻量级PULL模式。在Spring Cloud Alibaba里Redis数据源的配置如下spring: cloud: sentinel: datasource: dsRedis: redis: server-addr: 10.0.0.13:6379 > Sentinel限流配置实战：流控规则、热点参数与系统自适应保护
做高并发系统绕不开流量控制这个问题。我维护的订单服务每逢大促和秒杀QPS能从几百冲到上万早期用固定阈值写死限流被热点流量打爆过好几次。后来把Sentinel的流控规则QPS/线程数、热点参数限流、系统自适应保护这三件事完整落地才算是把流量治理这件事想明白了。这篇不是照着官方文档念概念而是把我在生产环境里配置Sentinel限流配置时踩过的坑、调过的参数、验证过的方法按实操链路整理出来给正在折腾Sentinel的同行一个可直接参考的版本。1. 先从流量控制的思路说起Sentinel的定位不是“一个计数器”而是一套完整的流量防卫体系。它的核心模型是“资源规则”资源就是你要保护的接口、方法或网关路由规则就是针对资源定义的流控策略。你可以对同一个资源叠加多条规则也可以把多个资源串成链路做精细管控。相比手写限流它最大的价值是把流量统计、阈值判断、拒绝逻辑、控制台预览全链路打通改规则不用发版本实时生效。很多人刚接触Sentinel容易纠结一个点到底该用它的流控规则还是用RedisLua自己写一个分布式限流我的理解是如果只是给一个简单接口压一下峰值RedisLua够用但业务一旦复杂起来比如同一个接口被多个上游调用、某个参数值特别热、系统整体负载高要全局兜底自己造轮子成本就很高了。Sentinel把这几类场景都内置成了规则类型所以本文重点聊的QPS/线程数、热点参数限流、系统自适应保护正是对应了接口维度、参数维度、系统维度这三层流量治理。1.1 Sentinel和Hystrix的区别用过Hystrix的同学熟悉线程池隔离和信号量隔离它主要解决的是“依赖故障别拖垮我”的问题。Sentinel则更侧重“流量太猛别打死我”两者思路不一样。Hystrix的信号量隔离本质上是限制并发Sentinel的流控规则可以按QPS做时间维度的速率控制也可以按并发线程数做资源维度控制粒度更细。再加上热点参数限流和系统自适应保护这两类Hystrix没有的能力Sentinel在高并发网关和核心链路治理上更顺手。还有一个实用层面的区别Hystrix的规则默认静态配置为主想动态调整要么改代码重启要么额外开发配置中心对接。Sentinel天生支持从Nacos、Apollo、Redis等外部数据源动态加载规则控制台还能实时查看每个资源的流量曲线。生产环境里“规则可动态调整”几乎是刚需这也是我最终选型Sentinel的重要原因。1.2 Sentinel的Slot Chain设计想排查“规则为什么不生效”必须了解Sentinel的执行链。每个资源被调用时会经过一系列SlotNodeSelectorSlot维护调用树ClusterBuilderSlot维护集群节点统计StatisticSlot做实时指标统计FlowSlot执行流控规则DegradeSlot执行熔断降级ParamFlowSlot执行热点参数限流SystemSlot执行系统自适应保护。这个顺序解释了几个现象统计先行、规则判断在后所以规则判断用的都是上一个时间窗口的数据某个Slot如果异常后续Slot基本不会执行。遇到“阈值明明没到却被拦截”优先怀疑是不是多个Slot叠加判断导致比如接口自带流控规则同时又命中了系统保护规则。很多诡异问题追根溯源最后都落在Slot之间的配合上。2. Sentinel流控规则QPS和线程数怎么选流控规则是Sentinel最基础也最常用的能力核心是FlowRule。配置一条流控规则需要搞清楚的第一个决策就是阈值类型选QPS还是线程数。QPS模式很好理解就是每秒最大通过请求数超过阈值直接拒绝适合读多写少、响应时间稳定的接口比如商品查询、配置拉取。线程数模式限的是并发处理中的线程数量同一时刻最多允许多少个线程并行处理该资源适合响应时间波动大、依赖外部服务或者数据库连接的接口。一个RT响应时间200ms的接口如果QPS限制1000理论上并发也就200但实际上大量线程可能阻塞在慢调用上线程一堆积后面的请求全部排队所以慢接口用并发线程数来保护更直接。这里有个常见误区很多人把QPS当成“并发量”来配比如觉得“我能撑100并发就限100 QPS”这是错位理解。QPS是速率线程数是水位。判断该用哪个建议直接问自己一个问题这个接口的RT是否稳定RT稳定的接口用QPS更直观RT波动大的接口用并发线程数更安全因为它限制的是“同时占用线程资源的数量”而不是“每秒放进来多少”对下游的连接池、线程池更友好。2.1 流控模式直接、关联、链路确定了阈值类型下一步是选流控模式FlowRule里的strategy字段控制。默认的“直接”模式只针对当前资源本身做统计超过阈值就拦当前资源简单粗暴适合绝大多数接口兜底。“关联”模式针对的是两个有主次关系的资源。经典的场景是“读多写少保护写”当关联资源比如读接口的QPS超过阈值时对当前资源比如写接口启动限流目的是优先保证读接口可用牺牲一部分写流量。配置时要指定refResource为关联资源名统计维度和当前资源隔离各自保留各自的统计节点。“链路”模式是针对调用来源的精细控制。同一个资源可能被多个入口调用比如订单详情接口既被App端调用又被内部定时任务调用你只想限制定时任务这一路流量。此时需要把资源按调用链拆开并设置web-context-unify为false让每个入口生成独立的调用上下文。链路模式能精准限制“从某个入口进来”的流量不会误伤其他来源但配置成本也高需要前端埋点配合ContextUtil.enter做好链路透传否则上下文串了规则会失效。2.2 三种流控效果的适用场景controlBehavior字段决定超阈值后的表现方式三种效果对应三种不同的算法思想。快速失败CONTROL_BEHAVIOR_DEFAULT最直白一旦超出阈值直接抛出BlockException。它的好处是响应快、实现简单、不会堆积请求坏处是流量曲线是“砍头式”的短暂突发流量会被一刀切适合对延迟极其敏感、不希望排队拖慢的核心接口。预热模式WARM_UP解决的是“冷系统被热流量直接打瘫”的问题。系统刚启动时缓存是空的、连接池是冷的如果立刻放行大量流量很可能瞬间压垮依赖。预热会从低阈值开始放行逐步逼近设定阈值。默认冷启动因子coldFactor是3也就是说初始阈值是最终阈值的三分之一比如设QPS阈值3000刚启动时只放1000 QPS经过warmUpPeriodSec配置的时间比如20秒慢慢升到3000。这个模式对重启后的服务、缓存重建场景特别有用。匀速排队RATE_LIMITER本质是漏桶算法请求先放入队列以固定的速率逐个通过排队时间超过maxQueueingTimeMs的请求会直接丢弃。它能把突发流量整形为平稳流量适合削峰填谷典型场景是消息推送、订单回调这类可以接受几秒延迟的业务。缺点很明显如果业务要求高实时性排队带来的延迟不可接受而且队列本身会占用内存长时间占不满时阈值形同虚设。2.3 阈值怎么拍别拍脑袋要压测流控规则配置里最没把握的是阈值设多少。我见过不少项目上线前直接把阈值写成1000、5000这种“感觉值”结果大促第一波流量就直接全拒或者阈值设太高根本没起到保护作用。更靠谱的做法是先压测再设阈值。压测时从低并发开始逐渐加压记录每个阶段的QPS、P99 RT、错误率、CPU使用率找到“RT明显上涨”或者“错误率开始抬头”的拐点这个拐点就是服务的容量上限。生产阈值建议保守一点参考“拐点值×0.8”或者“预估峰值×1.2取小值”。比如压测结果显示最大可支撑800 QPS预估峰值流量是500 QPS那么线上阈值可以先设600 QPS留出缓冲同时盯着监控在白天逐步调优而不是一步到位。这句经验值很重要限流阈值不是一次配完就完事它应该是一个动态值。大促期间临时调低常态运行时逐步调高需要一套可动态调整规则的手段这就是后面第5章要说的规则持久化和数据源。2.4 代码配置一条QPS流控规则开发环境调试流控规则可以直接用FlowRuleManager加载规则不需要启动控制台Configuration public class SentinelRuleConfig { PostConstruct public void initFlowRules() { FlowRule rule new FlowRule(); rule.setResource(order:create); // 按QPS限流 rule.setGrade(RuleConstant.FLOW_GRADE_QPS); rule.setCount(1000); // 直接模式 rule.setStrategy(RuleConstant.STRATEGY_DIRECT); // 快速失败 rule.setControlBehavior(RuleConstant.CONTROL_BEHAVIOR_DEFAULT); FlowRuleManager.loadRules(Collections.singletonList(rule)); } }注意几点resource的名称必须和被保护点一致如果接口是Spring MVC的URL路径资源名默认是请求路径如果是自定义方法需要用SentinelResource注解指定资源名。FlowRuleManager.loadRules是整表替换逻辑意思是每次调用都会用新列表覆盖旧规则所以多规则建议一次性组装好List再加载别一条条去调。生产环境通常不会用代码硬编码规则而是走数据源动态加载。但理解这段代码的字段语义对接下来的控制台配置、Nacos配置字段都会很有帮助因为JSON格式里grade、strategy、controlBehavior这几个字段和代码是一一对应的。3. 热点参数限流把额度花在刀刃上流控规则有一个先天不足它只能对“资源整体”做限制区分不了请求里的参数值。商品详情接口普通商品每秒100个请求热门商品每秒几千个请求如果用流控规则把整个接口限制在2000 QPS热门商品一个请求可能就把额度吃掉一大半普通商品反而被误伤。热点参数限流就是来解决这个问题的。它按照“请求参数的具体值”做统计和限流比如配置paramIdx0也就是第一个参数作为维度那么Sentinel会按第一个参数的值分别统计QPS。参数值是sku_001的请求有自己的计数器参数值是sku_002的请求也有自己的计数器互不影响。这样就能做到普通参数值限制100 QPS热门参数值独立提升到5000 QPS谁热就精准管控谁。3.1 热点规则配置与参数索引配置热点规则用的是ParamFlowRule核心字段是resource、paramIdx和count。paramIdx表示你要针对请求的第几个参数做维度从0开始。假设你的方法签名是queryGoods(String skuId, Long userId)想按skuId限流paramIdx就是0想按userId限流paramIdx就是1。这里有容易踩的坑paramIdx是从0开始的数组下标很多同学下意识把第一个参数写成1结果规则加载成功但永远不生效。还有一个坑是参数类型不匹配热点规则在做参数值统计时是按类型区分的如果你的方法参数是Long类型但rule里配置的paramType没对上或者从HTTP请求参数里解析出来的字符串和对象类型对不上也会出现“规则加了但拦不住”的情况。配置示例ParamFlowRule hotRule new ParamFlowRule(); hotRule.setResource(goods:query); // 针对第一个参数skuId做统计 hotRule.setParamIdx(0); // 默认针对任意参数值限制100 QPS hotRule.setCount(100); // 精确参数例外项当skuId等于sku_100001时单独给5000 QPS ParamFlowItem special new ParamFlowItem(); special.setParamType(String); special.setParamValue(sku_100001); special.setCount(5000); hotRule.setParamFlowItemList(Collections.singletonList(special)); ParamFlowRuleManager.loadRules(Collections.singletonList(hotRule));注意ParamFlowItem用于配置“参数例外项”也就是针对特定参数值单独放大或缩小阈值。paramValue必须和实际请求中的参数值类型一致比如请求里传的是字符串“sku_100001”paramType就是StringparamValue就是sku_100001。3.2 热点参数的例外项和兜底策略这里顺便展开讲一下例外项逻辑如果某个参数值命中了paramFlowItemList里的精确项就使用精确项里的count作为该参数值的阈值如果没命中任何精确项就用规则上层的count作为默认阈值。也就是说默认阈值是兜底用来限制绝大多数参数值例外项是放量给重点参数值更高的额度。这套机制特别适合秒杀场景。秒杀商品详情接口所有商品共用接口但只有活动商品需要高并发放行。配置一个默认count100的兜底规则再给秒杀商品id配一条count5000的例外项平时流量轻松通过秒杀流量来了也顶得住。反过来如果某个参数值是爬虫重点抓取的对象你也能把它配成例外项并设置一个低于默认值的阈值做到精准打压。需要特别补充的是热点参数限流目前只支持QPS模式不支持线程数限流流控效果也只支持快速失败不支持预热线速和匀速排队。这是官方明确的能力边界在控制台配置时会发现可选选项就是有限的如果你从网上教程里看到“热点参数也能排队等待”的说法那多半是把流控规则和热点规则搞混了。3.3 热点限流的使用经验我实际用下来热点参数限流最适合的三个场景是按用户ID限流防刷、按商品ID/店铺ID做精细化流量管控、按订单号保护下游查询。但真正落地时有一个前置条件被限流的方法必须能通过Sentinel识别到参数。如果用的是Spring MVC接口Sentinel内置支持从请求参数里提取参数值如果自定义方法请结合SentinelResource注解声明资源名并保证参数类型一致。还有一种情况需要自定义参数提取器。比如入参是包装对象OrderQuery里面有个字段shopId热点规则默认没法解析“对象里的某个字段”。Sentinel提供了ParamRequestorAdapter扩展点可以实现从对象中提取特定字段。这个场景在复杂业务里经常遇到官方文档提得比较少我在对接旧项目时专门为参数封装写过一次适配器才把热点规则用起来。4. 系统自适应保护从单点限流到全局兜底流控规则和热点参数限流解决的都是“某一个资源”的问题但系统是一个整体。如果一个服务实例上同时跑着几十个接口每个接口都配了2000 QPS的限额合起来可能是几万QPS直接把CPU和内存打满。这时候单独看任何一个接口都没超阈值但整个机器已经快不行了。系统自适应保护就是给整个进程装上的“最后一道安全阀”。它借鉴了TCP拥塞控制的思路不再只是机械地对单个资源计数而是根据系统整体指标动态判断当前状态如果系统已经过载就直接对入口流量进行全局拦截。Sentinel官方叫它“自适应”主要是因为阈值判断会结合系统容量和实时的流量形态不是简单的一刀切。4.1 触发器指标详解系统自适应保护的规则由SystemRule承载支持五类指标可以在一个SystemRule里同时配多个highestSystemLoad系统1分钟负载load值仅在Linux/Unix类系统上有效。设置要根据机器核数来评估比如4核机器设4.0表示load超过4就认为系统过载。highestCpuUsageCPU使用率取值范围0到1比如0.8表示CPU使用率超过80%触发系统保护。相比load它在容器环境下更可靠。avgRt所有入口流量的平均响应时间超阈值触发保护用于防止系统因慢调用堆积而整体崩溃。maxThreads所有入口流量的并发线程总数超过阈值触发保护相当于全局的线程并发上限。qps所有入口流量的总QPS超过阈值触发保护相当于一个全局的总入口限流。这里的“入口流量”指的是Dashboard上的入口资源通常是网关路由入口或者Spring MVC的根路径不是某个具体的业务接口。如果某个服务只被内部RPC调用没有走HTTP入口系统保护依然能作用于所有统计到的入口调用但建议结合实际的入口梳理清楚否则会漏掉部分流量。4.2 系统规则配置代码示例开发阶段可以直接用SystemRuleManager加载系统规则SystemRule sysRule new SystemRule(); // load阈值按机器核数评估 sysRule.setHighestSystemLoad(4.0); // CPU使用率80%触发 sysRule.setHighestCpuUsage(0.8); // 入口平均RT不超过1000ms sysRule.setAvgRt(1000); // 全局并发线程不超过500 sysRule.setMaxThreads(500); // 入口总QPS不超过20000 sysRule.setQps(20000); SystemRuleManager.loadRules(Collections.singletonList(sysRule));注意这些阈值都是针对单机维度的不是集群维度。如果服务开了多个实例每个实例会独立判断自己的系统指标所以配置时要按单机容量来算别把集群的总量除以实例数指望系统帮我们分摊。比如集群总QPS承载是6万三台机器一台2万系统规则qps就配20000不是60000。实际生产经验是系统自适应保护指标的设定宁低勿高。因为它的触发代价是“所有入口流量都被拦截”影响面比单个接口的流控大得多。我通常先按CPU使用率0.7-0.8、load不超过核数来设一个保守值看监控曲线稳定后再逐步放宽绝不会把阈值顶到压测极限留20%余量是底线。4.3 和流控规则怎么分工说了半天系统自适应保护容易给人“规则越多越好”的感觉实际不是。我倾向于把系统自适应保护当作最后一道防线而不是日常限流的主力。日常限流还是靠具体的流控规则和热点参数限流因为它们作用面小、逻辑可控、误伤范围有限。系统自适应保护只在机器整体指标异常时才介入比如CPU飙到90%、load严重超标时全局拦一波给系统喘口气。两层规则的正确分工是流控规则管“单个接口别超量”热点参数限流管“特殊参数值别过载”系统自适应保护管“整个进程别被打垮”。三者互不替代协同生效。排查问题时如果发现某次拦截来自系统保护而非具体流控规则也别惊讶说明系统自己已经先“求救”了优先级反而是调低其他资源的流量。5. 规则持久化与数据源集成Nacos和Redis实操到这里三种限流能力的原理和用法都讲透了。但还有个问题没解决这些规则都存在哪如果只是通过Dashboard控制台手动配置规则是存在Sentinel客户端内存里的服务一重启规则全没了。生产环境要是这样每次重启都要人工重新配一遍规则出了故障根本没法追溯。更常见的是规则要跟随环境变化动态调整大促前批量更换阈值没有配置中心根本做不了。所以规则持久化是生产落地的前提。数据源的核心概念是通过DataSource把规则存储到外部介质Nacos、Redis、Apollo、ZK等客户端启动时读取运行期间根据配置中心的变动实时更新规则。Sentinel支持两种模式PULL模式是客户端定时去外部存储拉取规则实现简单、有延迟PUSH模式是配置中心主动推送规则变更到客户端实时性好但需要Dashboard和控制台配合改造。5.1 Nacos数据源配置样例Spring Cloud Alibaba环境下最顺手的方案是用Nacos做规则持久化。步骤分三步引入依赖、配置数据源、在Nacos里放规则。第一步Maven依赖加入sentinel-datasource-nacosdependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-sentinel/artifactId /dependency dependency groupIdcom.alibaba.csp/groupId artifactIdsentinel-datasource-nacos/artifactId /dependency第二步在application.yml里声明数据源。这里需要区分不同规则类型每种规则类型对应一个数据源标识spring: cloud: sentinel: transport: dashboard: 10.0.0.11:8858 datasource: flowNacos: nacos: server-addr: 10.0.0.12:8848 >[ { resource: order:create, limitApp: default, grade: 1, count: 1000, strategy: 0, controlBehavior: 0, warmUpPeriodSec: 20 } ]字段和前面代码里一一对应grade代表阈值类型0是线程数1是QPSstrategy是流控模式0直接、1关联、2链路controlBehavior是流控效果0快速失败、1预热、2匀速排队。warmUpPeriodSec只有在预热模式下才有意义。配置完成后启动服务时会自动从Nacos拉取规则Nacos里的配置变更后客户端会自动感知并更新规则。这个方案省掉了手动登录Dashboard反复配置的麻烦也方便把规则纳入Git仓库做版本管理。5.2 Redis数据源与集群场景小结如果团队没有Nacos/Apollo这类配置中心Sentinel也支持用Redis做规则数据源属于轻量级PULL模式。在Spring Cloud Alibaba里Redis数据源的配置如下spring: cloud: sentinel: datasource: dsRedis: redis: server-addr: 10.0.0.13:6379 >