最近在梳理限流和熔断相关的东西又把Sentinel的源码翻了一遍。说实话滑动时间窗口这块我前前后后看过几遍每次都有新的理解。刚开始接触Sentinel的时候我以为它就是个简单的计数器限流后来才发现这套窗口设计其实挺精巧的。从申请令牌到统计QPS从窗口滑动到环形数组复用每一层都有值得琢磨的细节。这篇就把我对Sentinel滑动时间窗口算法的理解整理出来从数据结构到源码链路再到实际参数怎么配尽量把“为什么这么设计”讲透。如果你是刚开始接触Sentinel或者用了一段时间但没看过底层实现这篇文章会比较适合你。读完之后你至少能回答这几个问题Sentinel的滑动窗口到底是怎么滑的为什么说它比固定窗口更平滑样本窗口数sampleCount应该配多少以及限流阈值明明设置对了为什么压测结果还是跟预期差很远1. 从固定窗口说起Sentinel为什么非要搞个滑动窗口要理解滑动时间窗口的价值得先知道它是为了解决什么问题出现的。 Sentinel中最基础的限流算法之一是固定时间窗口计数也就是把时间切成固定长度的小段比如每秒钟一个格子。请求进来之后先看当前落在哪个格子里格子里累计的数量如果超过阈值就拒绝后面的请求。这个逻辑很简单执行也很快但它有两个比较明显的缺陷实际用起来很容易踩坑。1.1 固定窗口计数器的两个致命问题第一个是临界突变问题。假设我们设置QPS阈值是100固定窗口是1秒。当请求在第1秒的最后几十毫秒打满了100然后第2秒的前几十毫秒又能再打满100。这两个窗口在时间上是连续的夹在中间的那一段实际时间里系统在极短的瞬间承受了200个请求的突发流量。表面上看每一秒都没超过100但对后端服务来说它面对的却是200 QPS的瞬时冲击这跟限流的目标是相悖的。第二个问题是统计滞后问题。固定窗口在“当前窗口未结束”之前永远不会提前感知到流量是否在加速上涨。窗口是瞬时钟被重置的等新窗口一开一切从零计数。流量如果呈现锯齿形增长固定窗口很难做到平滑控制容易造成系统过载或者限流不够及时。1.2 滑动时间窗口的核心思想滑动时间窗口的思路是把统计区间从“一个固定格子”拓展为“一个持续移动的视野”。我们不再等待当前秒结束才切换而是每时每刻都维护一个覆盖过去一段时间的统计范围。假设窗口总长度是1秒我们把1秒切成若干个样本格子每个格子代表一段更小的时间片。窗口会随着当前时间不停向前移动移动的步长就是样本格子的长度。只要窗口内所有格子的统计值加起来不超过阈值就放行请求。这样做的好处很明显第1秒末的流量高峰和第2秒初的流量高峰如果时间间隔小于窗口长度它们会被算在同一个滑动窗口里不会被拆成两段清零后重新计数。这样就能有效抑制临界突变让限流阈值跟真实负载更匹配。2. Sentinel滑动时间窗口的数据结构设计Sentinel的滑动窗口不是用“创建新窗口-废弃旧窗口”这种朴素方式实现的它为了性能和内存考虑使用了一个固定长度的环形数组配合窗口复用机制。这套设计的核心类有LeapArray、WindowWrap和MetricBucket。2.1 LeapArray环形数组与WindowWrap窗口包装LeapArray是滑动窗口的主数据结构可以理解为一个长度固定的数组数组的每个元素都是一个WindowWrap。WindowWrap里包着一个MetricBucketMetricBucket里就是用LongAdder实现的各项计数器。注意这里有个细节数组长度不是随便选的它由样本窗口数sampleCount决定。比如窗口总长度是1000mssampleCount是2那数组长度就是2每个窗口长度就是500ms。当请求进来先计算当前时间属于哪个窗口如果该窗口不存在就在数组对应下标位置创建一个WindowWrap。数组是环形复用的下标通过位运算计算出来不是用“当前时间-起始时间/窗口长度”这种慢速除法。2.2 窗口定位时间戳为什么非要除以窗口长度Sentinel源码里计算窗口起始时间的核心逻辑是把当前时间戳除以windowLength每个窗口的毫秒数再乘以windowLength。这一步其实就是做了一次下取整。比如windowLength是500ms当前时间戳换算后是1700000000123ms除以500后取整再乘回500得到1700000000000这就是当前窗口的起点。计算当前时间戳所在窗口下标时会用“当前时间戳 / windowLength”跟数组长度取模。这样设计是为了让窗口下标和时间严格对齐。否则如果用一个ArrayList动态创建窗口窗口数量会无限增长时间一长老年代理对象堆积GC压力和内存占用都会上升。Sentinel用定长数组加位运算取模把窗口数量限制在固定范围内性能稳定很多。2.3 窗口复用为什么旧窗口还能被覆盖窗口复用是滑动窗口算法里最巧妙的部分。假设sampleCount等于2每个格子是500ms。当时间从第1秒推进到第2秒时第1秒的第二个格子即500ms到1000ms已经属于过去。此时如果新请求落在第1.6秒计算出来的下标跟那个旧格子的下标一样Sentinel会判断当前时间距离旧窗口起始时间是否已经超过了窗口长度。具体判断逻辑是如果当前时间戳比旧窗口的起始时间戳大且两者之差大于窗口长度说明这个旧窗口已经完全过期可以被覆盖。覆盖时直接重置MetricBucket的计数然后重新设置窗口起始时间戳。如果当前时间还是在旧窗口范围内那就说明这个窗口是当前活跃窗口直接把请求累加到它的计数器上不会再创建新窗口。这个设计的妙处在于子窗口数量始终恒定并且旧窗口在被覆盖之前仍然保留了上一段时间的统计数据。这样任意时刻我们都能通过遍历整个数组算出过去一个完整时间窗口内的总请求数。2.4 MetricBucket的统计维度大家看Sentinel限流监控面板时会看到除了QPS还有异常数、RT、并发占用数等指标。这些指标不是分散统计的而是全部放在MetricBucket里。MetricBucket内部维护了一个LongAdder数组每个LongAdder对应一个统计指标比如当前请求总数、异常请求数、成功请求数、RT总和等。LongAdder是JDK 8提供的并发计数器在高并发写多读少场景下比AtomicLong性能更好因为它把单一热点拆成了多个cell线程各自更新自己对应的cell最后求和时再汇总。Sentinel选择LongAdder作为底层计数器是为了降低计数本身的争用开销。限流框架本身处在请求链路的必经之路上如果计数逻辑太重会明显影响性能和RT。3. 请求计数与限流判断的完整链路拆解理解了数据结构再看一次请求进来之后会经过哪些环节。这里我把Sentinel的流程简化到最核心的部分以FlowSlot的限流检查为例梳理出请求从进入到最终判定是否放行的完整轨迹。3.1 入口方法Entry与Context的初始化Sentinel通过SphU.entry(resourceName)创建一个Entry表示一次资源访问的入口。在真正进入规则校验之前它会根据调用链构造Context把当前调用来源、资源名等信息记录到ThreadLocal里。接着会经过一系列ProcessorSlot每个Slot负责一个维度的检查比如DegradeSlot负责熔断降级FlowSlot负责流量控制。FlowSlot在检查限流时调用的是flowRuleChecker.canPassCheck。这个方法会遍历当前资源关联的所有FlowRule对每一条规则分别做流量统计与阈值判断。如果有一个规则判定不通过请求就会被阻断。这里要注意一条资源可以绑定多条限流规则只要有一条不满足就会触发限流返回。3.2 计数逻辑currentWindow如何拿到当前窗口核心的计数方法是node.incrementAndAddRequest这里的node是StatisticNode内部持有一个Metric对象。Metric的核心存储还是一个LeapArray具体使用的类型取决于它是用于秒级还是分钟级统计。对于秒级统计默认用ArrayMetric它内部持有的是一个sampleCount为2的LeapArray每个窗口500ms。处理当前请求时Sentinel会调用leapArray.currentWindow(timeMillis)这个方法会先根据当前时间戳计算窗口下标然后拿到数组对应位置上的WindowWrap。如果这个位置是空的就创建一个新的WindowWrap用CAS原子操作放进去防止多线程并发创建时重复初始化。如果这个位置上已有WindowWrap就复用它并把请求数加到MetricBucket里。这里有个非常容易被忽略的细节currentWindow返回的其实是“当前样本窗口”不是“整个滑动窗口”。整个滑动窗口的代表值需要在后续获取QPS时把数组里所有非过期窗口的值加起来。3.3 阈值判定从统计值到判断结果的转换每个FlowRule里包含count阈值和grade阈值类型。如果grade是QPS模式那么Sentinel会先计算当前整个滑动窗口内的总请求数。具体是遍历整个LeapArray数组把每个未过期窗口的MetricBucket里的请求总数加在一起。但是这个总数是跨多个样本窗口累计的而秒级窗口有2个格子窗口总长度虽然是1秒但如果按格子来算会出现一个问题当窗口滑到某两个格子各占一半时总计数值其实对应的是“过去两个样本窗口”的请求总量而不是严格意义上过去1秒的请求量。所以Sentinel在计算QPS时做了一个归一化处理它会把窗口内的总请求数乘上窗口数量再除以实际窗口长度换算成“每秒的请求速率”。具体来说在ArrayMetric.getQps()方法里通过leapArray.getIntervalInSecond()和样本数把窗口总数转换为每秒QPS。这样阈值count就能直接按QEQS方式配置不需要用户自己去换算。3.4 快速失败与排队等待FlowRule还有一个controlBehavior字段用来指示限流触发后的处理策略。默认是快速失败也就是直接抛BlockException。在滑动窗口模式下快速失败逻辑相对简单计算出当前QPS后跟阈值比较超过就拒绝没超过就放行。排队等待模式会复杂一些。它允许请求在客户端本地排队以固定速率放行。这个模式对滑动窗口的依赖没那么直接但底层依然会计算当前消耗的令牌数和允许通过的速率。如果配置了排队等待要注意它的前提是“流量是相对均匀的”如果瞬时流量太大排队队列会积压大量请求响应时间反而会上升这种情况下更推荐快速失败加上客户端本地重试。4. 参数配置建议sampleCount到底配多少合适Sentinel支持通过参数来调整滑动窗口的样本数。秒级窗口总长度默认是1000mssampleCount默认为2也就是每个样本窗口500ms。有的同学以为让sampleCount越大越平滑直接设置成10甚至更大然后压测时发现限流效果反而抖动厉害还误以为是不是TimeWindow算法有问题。4.1 样本窗口数与平滑度、内存的关系样本数增加意味着统计粒度变细滑动窗口移动更平滑临界突变抑制得更好。但代价是统计对象变多每个窗口都持有一组LongAdder计数器内存占用和遍历计算成本都会上升。而且如果样本窗口过小很容易出现窗口频繁被覆盖某些短时间窗口内的请求漏统计反而让QPS计算结果更不稳定。这就好比你用尺子量布格子刻度越小理论上量得更精细但如果刻度小到了要频繁换尺子的程度来回对位反而会引入误差。实际调参时我会优先把样本数保持在合理的范围内一般4到8之间是比较稳的选择。极端高并发场景下用默认2也不会有太大问题关键看你的限流目标和流量曲线是否匹配。4.2 与固定窗口的对比实验思路想直观理解sampleCount对限流效果的影响可以自己做一个小压测。准备好一个简单的接口分别配置三组限流规则第一组固定窗口样本数等于1第二组sampleCount2第三组sampleCount8。然后用压测工具以短时间突发流量去打接口观察被拒绝请求的分布和接口的实际吞吐。结果大概率是固定窗口会出现比较明显的脉冲放行比如某几百毫秒内通过请求突然拉高sampleCount2会平滑一些sampleCount8更平滑但不代表效果最好因为不同服务对瞬时限流的敏感度不一样。如果后端本身抗瞬时冲击能力很强就不需要把窗口切得那么碎默认配置完全够用。4.3 秒级窗口与分钟级窗口的配合Sentinel的统计其实是分层的上面说的LeapArray处理的是秒级数据而分钟级数据用的是另一套更长窗口的LeapArray。比如做熔断降级时Sentinel需要评估“最近一分钟的异常比例”这个统计用的不是秒级窗口而是分钟级窗口样本数通常为60每个窗口1秒。我之前踩过一个坑想通过Metrics查看最近一分钟的RT曲线结果只改了秒级LeapArray的配置分钟级统计还是默认值导致监控面板上的趋势图跟实际限流表现对不上。所以调参数的时候要搞清楚具体是哪个统计链路在起作用别把秒级和分钟级的概念搞混。5. 实战中的常见问题与排查技巧滑动窗口算法本身不算复杂真正容易出问题的是它在工程落地时的一些边界情况。这里把我实际遇到过的问题做个记录也整理了排查思路。5.1 常见问题速查表问题现象可能原因排查与解决接口在某一瞬间突然大量被限流随后又恢复流量突增跨过了窗口边界旧窗口过期导致统计值短暂偏高调大sampleCount让窗口移动更平滑或调大阈值留出缓冲QPS限流阈值设置成100实际压测却经常到110以上才拦集群模式或Context维度配置问题单机FlowRule没生效检查规则来源是控制台还是本地配置确认流量命中维度是否正确修改限流规则后不生效控制台推送的是缓存值或动态规则源未刷新检查规则数据源Nacos等配置中心是否正常推送确认规则ID和资源名完全一致限流后提示BlockException的响应格式不一致默认BlockException处理逻辑未覆盖所有场景通过BlockExceptionHandler实现统一响应体监控面板的QPS曲线有毛刺采样周期或统计窗口过小可尝试增加样本数同时确认系统时间是否有跳变5.2 与Feign和Nacos集成时的限流响应问题很多项目里Sentinel是和Feign、Nacos一起用的。Feign做远程调用Nacos做规则存储和配置下发。这种组合很常见但也会带来一个新的问题Feign调用远程服务时如果被限流了BlockException会被包装成Feign的异常默认抛出的是SentinelFeign的callableHandler包装结果。很多团队在这一步才发现限流触发的日志跟业务错误日志混在一起排查起来很费劲。我的做法是单独实现一个BlockExceptionHandler然后在里面区分BlockException类型。如果是FlowException就返回限流提示如果是DegradeException就返回降级提示将业务错误和限流错误分开处理。这样不仅日志干净前端也能拿到更明确的响应码。还有一个小提示从Nacos配置中心动态修改限流阈值时Sentinel会立即刷新内存中的规则但当前滑动窗口内已统计的数据不会立刻清零。也就是说你调高阈值后可能还要等一个窗口周期新阈值才“完全生效”。这点在演练和压测时要注意别调完参数就急着看结果。5.3 源码阅读时的切入点建议如果你接下来想自己看Sentinel源码可以先从LeapArray.class和ArrayMetric.class切入把两个核心类的逻辑看完整个滑动窗口基本就通了。然后再看MetricBucket和LongAdder的配合方式。接着再去看FlowRuleChecker和FlowSlot理解规则怎么跟你看到的统计值关联上。源码阅读时有个技巧先找构造方法看sampleCount和IntervalInMs是怎么传进来的再找currentWindow系列方法看窗口的创建和覆盖逻辑最后看QPS计算逻辑。这个顺序能帮你从参数一路走到实际判断结果比起从头到尾读class的成员变量顺序会更高效。6. 顺着Sentinel往下走还可以研究什么滑动窗口只是Sentinel限流体系中的一个基础模块。如果理解了窗口统计这套机制后面再去刷Sentinel的令牌桶算法会遇到很多相似的设计思路。令牌桶和漏桶算法在Sentinel里被实现在不同的FlowRule控制行为里它们的底层同样依赖Metric的统计能力。另外Sentinel的熔断降级也是建立在滑动统计上的不过它评估的除了QPS还有异常比例、慢调用比例这需要额外统计每个请求的RT和异常标记。源码里的DegradeSlot和ExceptionRatioMetric都是建立在窗口计数之上的。你会发现把窗口数据结构看明白之后熔断降级的逻辑也会变得很顺理成章。我个人的理解是做限流核心不在于某个算法的高深而在于四个问题考虑清楚统计什么、统计多久、怎么判断、超出了怎么办。滑动时间窗口解决的是“统计多久”和“怎么判断”这两件事。只要把这一层逻辑吃透其他模块都是在这个基础上的扩展。