做后端服务的同学应该没人敢说自己没碰过限流。不管是给开放平台写接口还是给大促活动做保障流量一上来第一个想的就是“先把入口掐住”。在 Spring Cloud 体系里Sentinel 基本是首选因为它是阿里开源的和 Nacos、Spring Cloud Alibaba 生态契合度极高开箱即用。但很多人在用 Sentinel 时其实只用了默认的 QPS 模式也就是每秒允许通过多少请求。真正遇到接口响应慢、下游抖动、线程池被打满这类问题时却发现 QPS 限流并不好使于是才想起来还有一种叫“线程数”的限流模式。这篇文章就把 Sentinel 的这两种限流方式讲透它们分别限的是什么、适合什么样的业务场景、性能差异有多大、实际怎么配置、有哪些坑需要绕开。目标是让读者看完之后能根据自己服务的实际情况做出合理选择而不是背参数。1. 先搞清楚两种限流模式到底在限什么很多人对限流有个误解觉得只要限制了 QPS服务就安全了。其实远不是这么回事。QPS 限制的是“入口流量密度”也就是每秒能进来多少请求而线程数限制的是“并发占用”也就是同一时刻有多少请求正在被处理。这两个概念在系统高负载时的表现差别非常大。1.1 QPS 限流限制的是速度不是容量Sentinel 的 QPS 限流核心是一个滑动窗口计数器。它把当前时间切成一个个小格子默认是 1 秒内的若干小窗口统计这个时间窗口内通过的请求数达到阈值就直接拒绝或者触发排队等待。打个比方一条高速公路的收费站QPS 限流就是规定“每小时只能放行 1000 辆车”。它不管你后面堵了多少辆车也不管每辆车通过收费站之后还要走多远。只要当前这一小时放进来了 1000 辆后面的车就被拦在门外。这个模式的优点是直观、好理解也容易做预热和排队控制。但它有个天生的短板它只统计“放行了多少请求”完全不管“这些请求被处理得有多快”。如果接口本身的响应时间从 50ms 涨到了 2sQPS 还是那个 QPS但系统内部的积压请求会越来越多最终导致线程池满、内存飙升、CPU 被打满。1.2 线程数限流限制的是并发容量也就是同时占用资源的请求数线程数限流的原理完全不同它用的是信号量机制类似 Java 里面的Semaphore。Sentinel 会为受保护的资源维护一个计数器每个请求进来时计数器加 1请求结束时减 1。一旦计数器的值超过了设定阈值新请求直接被拒绝。还是拿高速公路打比方这次收费站不看“每小时放行多少辆”而是规定“同时在这条路上行驶的车最多只能有 100 辆”。只要路上已经有 100 辆在跑不管时间过了多久新来的车一律拦住。只有路上有车到达终点腾出位置才允许新的车进去。这个模式盯住的是“系统中同时存在的在途请求数”。对于慢接口来说线程数限流比 QPS 限流更精准因为哪怕请求特别慢只要并发占用控制在某个范围请求就始终在能消化的水平。1.3 两种模式对比一张表看懂核心差异我整理了两种模式在几个关键维度上的对比做技术选型时可以直接参考对比维度QPS 限流线程数限流统计对象每秒请求数当前并发调用数本质算法滑动窗口计数信号量计数器适合接口快速响应接口毫秒级慢响应接口百毫秒以上应对响应变慢无感可能继续放流量有感知自动拦截新流量相对性能开销有窗口数组维护成本更低原子计数即可阈值语义每秒进来的请求量同时占用的请求量控制台体现每秒曲线热点并发曲线看到这里你应该能感受到QPS 限流是“入口视角”线程数限流是“容量视角”。入口限流再严格只要下游变慢容量就可能在短时间内被打满容量限流再宽松只要请求处理得够快QPS 可以冲出很高的值。2. 按场景选模式QPS 与线程数分别该用在哪儿在实际业务中这两种限流模式各自有非常典型的适用场景也存在一些反直觉的地方。我之前帮很多团队做过限流方案设计总结了不少可以作为参考的选型经验。2.1 QPS 限流的典型主场网关、读接口、短平快业务QPS 限流最适合的核心场景是对“流量陡增”做整体控制。比如秒杀活动、消息推送、热点事件带来的突发流量这种场景下请求处理本身很快系统的瓶颈在于“每秒能收下多少请求”而不是“同时能并行多少请求”。网关层也是 QPS 限流的主场。在 Spring Cloud Gateway 或者 Zuul 上用 Sentinel 对某个路由配置一个 QPS 阈值比如“每秒最多 5000 次”能在入口处把超大流量先削掉一层保护后面的业务服务和数据库。因为网关本身不处理复杂业务请求几乎都是瞬间转发QPS 模式在网关上的真实开销非常低。还有一个容易被忽略的场景读多写少的查询接口尤其是 Redis、缓存、本地内存能直接扛住的接口。这种接口响应时间通常在 10ms 以内用 QPS 限流既直观又高效配个每秒 3000 的 QPS 阈值系统整体平稳。写过这种服务的人应该都有体会如果非要在这个场景用线程数限流反而容易误伤因为 3000 QPS 对应到并发可能只有几个线程在跑线程数阈值设 50 都嫌多。2.2 线程数限流的典型主场慢调用、IO 密集、下游不稳线程数限流的不可替代性体现在所有“响应时间不可控”的场景里。典型的比如调用外部第三方接口对方响应经常在 300ms 到 3s 之间波动再比如查询一个复杂的聚合报表里面要拼多个数据库查询慢的时候一条 SQL 就得好几秒。这种请求如果只用 QPS 限流你会发现即使入口 QPS 被限制在很低的值比如 50系统的线程池还是很快被占满因为每个请求都赖在池子里不出去。我之前处理过一个真实案例一个订单详情接口要查订单主表、子表、物流信息、优惠券信息正常情况 200ms 返回但高峰期经常跑到 2s 以上。团队起初给这个接口配了 QPS 1000 的限流你以为很安全了但接口响应一慢Tomcat 默认 200 个线程直接被占满CPU 一路飙升别的接口也跟着遭殃。后来换成线程数限流阈值设为 60表面上 QPS 上限变得很低但系统整个稳了线程池永远有富余核心接口的 P99 反而降下来了。IO 密集场景也一样。文件上传、导出 Excel、批量下载这些接口往往不是计算慢而是在等 IO。请求进来之后线程一直阻塞在 IO 上QPS 限流完全不管用必须用线程数限流去限制并发占用把“正在忙的请求数”压住。2.3 我的选型心法不要二选一要组合用做限流方案时我经常说的一句话是QPS 管入口线程数管容量。两者不是互斥关系而是协同关系。一个典型的高可用限流配置是在网关层用 QPS 限流挡住突发流量在服务层用线程数限流保护线程池和下游依赖在数据库层面再辅以连接池限制兜底。比如一个核心的交易接口我可能会这么配网关层QPS 限流 2000防止瞬时大流量打进来。服务层线程数限流 100确保同时处理中的请求不超过 100 个线程池永不堆积。下游保护对关键数据库操作加一个线程数限流 50避免慢 SQL 把连接池耗尽。三层各司其职。入口的 QPS 决定能进来的流量上限中间的线程数决定系统能承受的并行处理量底层的线程数保护关键依赖。实际效果比单用任何一种模式要好得多。3. 性能差异实测从原理到数据一次说清很多人关心 QPS 限流和线程数限流到底哪个性能更好。这个问题不能简单回答“谁快谁慢”得从底层实现说起再结合压测数据才能得到一个有参考价值的结论。3.1 从源码实现看两种限流的开销差异Sentinel 的 QPS 限流在统计层面用的是一套滑动窗口数据结构。默认情况下它会把当前秒切分成多个时间片每个时间片维护一组计数器包括总请求数、通过数、拒绝数等。一个请求进来需要计算当前时间属于哪个窗口、更新对应计数、判断阈值是否被突破。这套逻辑本身并不重但相比简单的原子加法多了一些内存访问和时间换算成本。我在压测中注意到一个细节当 QPS 达到几万级别时滑动窗口的统计操作会出现在火焰图里虽然占比不大但确实贡献了几个百分点的 CPU 开销。如果开启的是“精确”采样模式而不是“粗略”模式窗口数组的维护频率更高开销会更明显。线程数限流就纯粹得多。Sentinel 的线程数计数器本质上是给每个资源维护了一个AtomicInteger请求进来时incrementAndGet判断是否超过阈值请求结束通过回调时decrementAndGet。所有操作的耗时基本可以忽略不计相对于一次完整的 HTTP 请求处理它的开销连零头都算不上。3.2 我压过的真实数据两种模式的开销对比我这里分享一组基于 Spring Boot 应用、本地压测的参考数据。测试环境是 4 核 8G 的机器基准接口是纯内存计算、返回 JSON压测工具用的 JMeter。在单机 QPS 达到 12000 时不开启限流的基线 CPU 占用大概是 45% 左右。开启 QPS 限流阈值设置得非常高、基本不拦截请求之后CPU 占用大约涨了 23 个百分点开启线程数限流阈值设 2000之后CPU 占用几乎看不出变化涨幅在 1 个百分点以内。多跑了几轮之后可以得出一个稳定的结论在单机十万 QPS 以内这两种限流模式造成的性能差异都小到可以忽略。真正造成性能差距的不是限流本身而是“被拒绝请求的处理策略”。比如 QPS 限流配上排队等待会导致请求被挂起挂起请求本身会占线程资源和内存线程数限流通常配合快速失败拒绝成本就是一个异常抛出反而更干净。3.3 为什么线程数限流在压力下“看起来”更稳除了统计数据上的差异线程数限流在整体稳定性表现上也有一个天然优势它直接保护了系统的并发资源。想象一个极端情况系统线程池总共 200 个线程某个接口因为下游故障每次调用要卡 5 秒才超时。如果只配了 QPS 限流 500意味着每秒可以放 500 个新请求进来这些请求在 5 秒内全部挂在线程池上不到 1 秒就会把 200 个线程全部占满然后整个应用进入“排队地狱”所有线程都卡在等待上CPU 还会因为线程切换和超时处理飙升。如果同样的场景配的是线程数限流 50那么最多只有 50 个请求在卡着剩下的 150 个线程依然是空闲的其他接口的业务完全不受影响。这种情况下线程数限流不只是“省了一点 CPU”它直接把故障隔离在一定范围里让服务还有能力处理其他流量。所以我不太建议大家过度纠结两种模式在 CPU 开销上的那点差异真正要紧的是负载模式的区别。限流的本质是“丢车保帅”先保住系统的整体可用性再谈流量吞吐。4. 实操Sentinel 两种限流模式的完整配置案例讲原理讲了这么多下面进入真正能“抄作业”的环节。我分别用控制台、代码注解、动态数据源三种方式演示如何配置 QPS 限流和线程数限流。4.1 控制台可视化配置最简单的方式如果项目中已经接了 Sentinel Dashboard可视化配置是最快的路径。在控制台的“流量控制”页面新增规则资源名可以是接口路径也可以是自定义的资源名。选择“QPS 模式”时填一个阈值比如 100。这里额外注意一下“流控效果”的选择快速失败默认超过阈值立刻报Blocked by Sentinel异常。Warm Up 预热从较小的阈值逐渐增长到设定阈值避免冷启动时瞬间打满。适合启动后需要 JIT 预热和缓存预热的服务。排队等待超过阈值的请求会排队按固定速率放行。适合需要削峰填谷的接口。选择“线程数模式”时阈值填的是允许的并发调用数。比如填 50表示同一时刻最多允许 50 个请求同时在处理中超过的直接拒绝。线程数模式下的流控效果一般用快速失败因为它的目的就是快速止损不需要预热和排队。控制台配置虽简单但线上环境建议不要手动在控制台点点点。规则默认只存在内存里服务一重启就没了。想把规则持久化建议用下面的动态数据源方式。4.2 代码注解方式适合把规则和业务绑定对于核心接口我比较推荐用代码注解SentinelResource配合blockHandler来配置限流。这样规则和资源的关系在代码层面是可见的维护起来更清晰。SentinelResource(value order:detail, blockHandler handleBlock) public OrderVO getOrderDetail(Long orderId) { // 业务逻辑 } // blockHandler 方法必须和原方法在同一个类中或者用 blockHandlerClass 指定 public OrderVO handleBlock(Long orderId, BlockException ex) { if (ex instanceof FlowException) { // 流量控制的兜底逻辑 return OrderVO.buildFallback(系统繁忙请稍后再试); } return OrderVO.buildFallback(请求被拦截); }光有SentinelResource还不够还需要把规则加载进来。在项目初始化时可以通过FlowRuleManager给指定资源加载规则ListFlowRule rules new ArrayList(); // QPS 限流规则 FlowRule qpsRule new FlowRule(); qpsRule.setResource(order:detail); qpsRule.setGrade(RuleConstant.FLOW_GRADE_QPS); qpsRule.setCount(500); qpsRule.setControlBehavior(RuleConstant.CONTROL_BEHAVIOR_DEFAULT); rules.add(qpsRule); // 线程数限流规则 FlowRule threadRule new FlowRule(); threadRule.setResource(order:detail); threadRule.setGrade(RuleConstant.FLOW_GRADE_THREAD); threadRule.setCount(80); rules.add(threadRule); FlowRuleManager.loadRules(rules);两个规则指向同一个资源order:detail时两者会同时生效任一规则的阈值超过都会被拦截。这样就能实现我前面说的“QPS 管入口、线程数管容量”的组合效果。4.3 动态数据源规则存到 Redis 集群或数据库生产环境里规则直接loadRules到本地内存修改规则要重新发布服务这在长期维护上很不现实。Sentinel 官方提供了spring-cloud-starter-alibaba-sentinel-datasource扩展支持把规则存到 Nacos、Zookeeper、Redis 等外部存储。如果你的公司已经有用 Redis 集群推荐直接把限流规则放在 Redis 里。核心思路是应用启动时从 Redis 读取规则文件规则变更时可以定期拉取或者通过发布订阅模式动态刷新。spring: cloud: sentinel: datasource: flow: redis: server-addr: ${REDIS_HOST}:${REDIS_PORT} database: 0 password: ${REDIS_PASSWORD} type: redis rule-type: flow把规则放到 Redis 集群之后运维同事在控制台改规则应用侧可以直接感知。我们生产上就是这样操作的限流阈值做成可配置项每次大促前动态调整不用发版也不用重启。注意 Redis 数据源默认读取的是 key 对应的规则字符串需要把 Sentinel 规则以 JSON 格式存到 Redis具体格式可以参考 Sentinel 官方文档中的规则配置示例。4.4 热点参数限流比普通 QPS 更细粒度的补充如果单纯配置 QPS 限流所有请求都是同一个资源统一限流但在实际业务中经常遇到“某个商品ID、某个用户ID”被集中访问的情况。这时候还需要补一个热点参数限流。比如同样是一个商品详情接口商品 A 是爆款每秒访问量上万商品 B 长期无人问津。如果对整个接口做 QPS 限流 2000爆款商品会把额度全部占掉其他商品请求反而被误伤。这适合通过SentinelResource配合热点规则来处理热点参数作为限流维度针对具体的参数值单独统计和限流避免群体流量互相挤占。同样热点参数也支持按 QPS 维度做限流但不建议对参数热点也用线程数模式语义会绕。热点参数限流本质上解决的还是“入口流量不均匀”的问题它和线程数限流处于不同维度可以搭配使用。5. 常见问题与排查技巧实录最后这部分集中写一写我在接入 Sentinel 双限流模式时踩过的坑以及总结出来的排查思路。这些内容在官方文档里基本找不到对实际使用非常有价值。5.1 QPS 限流不生效的经典原因限流规则不生效这是新手最容易遇到的问题。排查时按照下面的顺序来检查SentinelResource的value和控制台里配置的资源名是否完全一致大小写、中划线、点号都要一字不差。检查服务是否成功连接了 Sentinel Dashboard如果没有sentinel-transport依赖和对应的spring.cloud.sentinel.transport.dashboard配置控制台操作不了规则也推不进去。看看是不是规则保存在内存里被覆盖了。如果后来调用了FlowRuleManager.loadRules()加载了另一套规则之前控制台配的规则会被整体替换。还有一个隐蔽问题只有SentinelResource块内的代码才受 Sentinel 保护。很多人在 Controller 方法上加了注解但blockHandler却放到了别的地方或者 method 签名对不上导致被拒绝请求直接抛异常而不是走兜底逻辑。blockHandler 方法必须是 public、参数必须包含BlockException并且返回类型要和原方法一致。5.2 线程数阈值设置多少才合理线程数阈值没有万能公式但可以用一个简单估算口径来定系统允许的最大 RT响应时间× 期望的并发吞吐量 / 1000。举个例子一个接口允许的最大响应时间是 500ms期望每秒能处理 1000 个请求那么大致需要的并发处理能力是1000 × 0.5 500。如果库里面只有 200 个线程那阈值直接设 200 就行实际设到 150 更保守。另一个更直接的方法看监控里的活跃线程数。用 SkyWalking 或者 Prometheus 监控线程池的activeCount取一周内的 P99 值再留 20% 余量就是比较合理的并发阈值。比如监控显示这个接口高峰期活跃线程在 80 左右那阈值可以设成 100。我个人的建议是线程数阈值宁可偏小不要偏大。因为限流拦截的是超出容量的请求多一点拒绝也不至于让整个服务的线程池被拖垮。拒绝请求的成本是毫秒级的后续还可以通过重试、降级来补偿。5.3 限流阈值设置中的反向思维响应慢了先降 QPS很多人在做限流时喜欢用一个固定 QPS 阈值然后一劳永逸但线上流量是动态的响应时间也是动态的。真正的动态调整思路应该是当接口的平均 RT 开始上升主动调低 QPS 阈值当 RT 恢复正常再把阈值调回来。原因也不难理解QPS × RT 并发数。这是一个恒等式。假设并发数是 100RT 是 100msQPS 能到 1000当 RT 变成 500msQPS 还维持在 1000并发数就变成 500系统必然超载。这时候如果仍然死守 1000 QPS其实就是在制造雪崩。反过来如果通过线程数限流把并发锁在 100即使 RT 涨到 500msQPS 也会自动跌到 200但系统不会有灾难性后果。5.4 限流和熔断降级的配合误区最后一个非常常见的误区只配了限流没有配熔断降级。我在文章前面强调过线程数限流能够保护线程池但它保护不了“在途请求一直失败”带给用户的体验问题。如果下游已经故障比如数据库连接池满了健康时间超过阈值这时候最好的做法是快速熔断直接走降级逻辑而不是继续放量进来再靠限流去拒绝。Sentinel 的熔断降级和限流是独立的两套维度。通常入口流量比较平稳时主要靠限流做“削峰”靠降级做“兜底”。比如核心接口的线程数阈值一旦触发同时把熔断规则打开设置一个短时间窗口比如 5 秒内错误率超过 50% 就熔断让调用方直接从缓存中拿降级数据而不是反复去触发慢调用。我在生产中看到太多团队限流规则一大堆熔断规则一个没有结果限流是挡住了新流量但已经在处理中的请求还是把系统拖垮。记住一件事限流是保护系统的第一道防线熔断是第二道降级是第三道。三道防线配合起来才能真正做到流量治理上的“稳”。最后说点实在的根据我个人实际使用 Sentitnel 多年的体会QPS 限流和线程数限流不是竞争关系而是互补关系。早期我也是只懂 QPS 限流直到线上发生了一次慢接口拖垮整个应用的故障才真正理解了线程数限流的意义。如今我在设计限流方案时已经把“入口按 QPS 卡、资源按线程数卡”当成了默认思路网关层用 QPS 挡住突发流量核心服务用线程数锁住并发上限再配合热点参数与熔断降级整条链路基本不需要熬夜看监控了。如果你正在搭建限流方案建议先把这两种模式的原理吃透再对照自己接口的响应时间和平峰曲线做一次真实的压测验证。哪怕是从最简单的“线程数 50 QPS 500”开始运行一段时间观察监控曲线再逐步调参也远比套一个大神的模板要可靠得多。流量治理这件事核心思路永远是保证系统能用再谈用得满。
