后端接口被流量打爆这回事我干了七八年还是经常遇到。限流方案倒是一抓一大把但很多人一开口就是“滑动窗口”真把网关的监控曲线拉出来看QPS照样跟锯齿似的。问题不在滑动窗口这个思路本身而是你只抄了个“窗口”的外壳没把“滑动”落实到位。这篇文章我想把滑动窗口限流的原理、实现和调优一次讲透目标只有一个让限流后的流量曲线不再像心电图。先给不熟悉的朋友定个位滑动窗口限流解决的是“单位时间最多放行多少请求”但它比固定窗口计数器多做了一个动作——窗口不是每隔一秒归零而是随着当前时间持续向前平移。适合谁看网关/中间件开发者、后端服务负责人、对流量治理有要求的高并发项目。如果你已经在用固定窗口被压测打穿过或者用Redis ZSET限流却遇到内存暴涨这篇内容应该能帮上忙。1. 先搞清楚你的限流方案为什么不平滑1.1 固定窗口计数器的“临界点”问题最早我做限流就是Redis INCRkey设为分钟级。比如limit1000每分钟一个key。这个方案最致命的是所有流量可以在“跨分钟”瞬间打进来。假设1分59.99秒时已经到1000服务开始拒绝2分0.01秒时key重置又进来1000。两次突发之间只隔了几十毫秒相当于把一分钟的配额压缩到几毫秒内消耗掉。下游服务本来按每分钟1000估算容量结果被双倍流量冲洗。这就是固定窗口的临界点问题。为什么业务一定会遇到因为流量是连续到达的不是按时钟边界均匀到达。任何以相对时间起点划分的桶都会在桶边界上产生断层。用生活类比一个水闸每60秒开一次每次流1升但如果闸门开关周期和上游水流不同步某个瞬间可能有两升同时涌过。限流也一样时钟边界和流量突发错开就会漏过超阈值的请求。1.2 滑动窗口到底解决了什么滑动窗口不依赖固定的起始边界。它站在“当前时刻”向前数1个窗口长度只关心这段时间内的累计。这样就不会出现“上一秒刚清零下一秒又来了几百个”的情况。比如当前时间为00:01:02.300窗口长度1分钟那么检查的是00:00:02.300到00:01:02.300之间的请求。这里要强调滑动窗口解决的是时间对齐而不是消除突发。它允许窗口内前900ms很闲、后100ms瞬间把1000个请求全打进来只要你总量不超过上限。所以不要对滑动窗口抱有不切实际的期待它保证的是“每个窗口边界处不会重置配额”而不是“任意时间点的瞬时速率”完全恒定。1.3 “平滑”是有等级的我习惯把平滑分成三个等级。第一级是“不漏过窗口边界的双倍流量”大部分滑动窗口实现都能做到。第二级是“任意短时间内的流量不超过一定比例”这时候要关注滑动窗口的检查步长。第三级是“瞬时速率无限接近设定值”这级基本要靠令牌桶、漏桶或者加权滑动窗口才能实现。为什么分级很重要因为很多人一上来就说“我要平滑滑动窗口”但产品需求其实只是第一级你用了第二级的实现成本高很多反过来如果业务要求三级平滑你又拿一个粗粒度滑动窗口去糊弄压测时照样被打挂。所以动手前先问清楚你要消除的到底是窗口重置尖刺还是瞬时超卖。这个问题直接决定了你要用多少桶、要不要上加权窗口。2. 主流的滑动窗口实现逐个拆开2.1 时间片分割法精度和内存的博弈最直观的实现是把整个窗口切成多个小桶例如1秒窗口分成10个桶每个桶100毫秒。请求到达时先计算它属于哪个桶给该桶计数加1同时维护一个“窗口内总计数”。时间一到旧桶滑动出去总计数减去旧桶的值再加新桶的值。这就是时间片分割法。关键参数是桶数N。窗口长度固定时N越大每个桶代表的步长越小检查窗口的时刻越密集平滑度越高但数组也要更长而且每个桶对应的“过期检查”更频繁。以1秒窗口、每秒1000个请求为例N10时步长100ms极限情况下可能瞬时放行1000×(11/10)1100个请求即10%的超限毛刺N100时这个毛刺降低到1%但数组长度、清理频率也变成10倍。后面的3.3节我会给具体的计算公式这里先记住一个结论桶数决定了你能接受的峰值超限比例。常见误区是桶数只追求大结果GC频繁、锁竞争加剧。其实很多场景下N2050就够了先算清楚业务能容忍的“瞬时突刺”是多少再反推N。技术社区里那些“把窗口切成10000片”的炫技方案往往只适合特定场景。2.2 滑动日志法精确但也很贵如果不用桶聚合直接把每个请求的时间戳记录下来窗口内就是一条条日志。判断是否放行时统计当前时间往前一个窗口内有多少条记录这就是滑动日志法。滑动日志法在时间精度上是完全精确的只要时间戳一致任意毫秒都能正确计算。代价同样明显。首先内存每个请求至少存时间戳和标识假设一条记录16字节10万QPS、窗口1分钟那就是96MB实际还要加对象开销单机可能吹爆其次统计时要遍历或二分查找不是严格的O(1)。所以这个方案只适合低并发、高精度要求的内部接口或者在本地做小规模限流。生产环境中我很少见人直接用滑动日志一般会用时间片分割法去近似它。当然滑动日志法有一个优势可以任意回溯比如支持“过去5分钟里最多1000次”这种动态窗口而不需要预定义桶。在一些统计需求里很有用但作为限流器性能不划算。2.3 分布式场景的Redis ZSET方案分布式限流绕不开Redis。最常见的实现是ZSETkey是接口名score是毫秒时间戳member是唯一请求标识。每次请求来时先用ZREMRANGEBYSCORE把窗口外的旧元素清掉ZADD新元素再ZCARD看当前数量超过limit就拒绝。这个方案能保证分布式的全局统计而且成员唯一不会把同一请求重复计数。但有两个地方必须小心第一每请求都要执行清理写入高并发下Redis的CPU和网络开销很高第二ZSET的member只增不减如果清理不及时内存会持续膨胀。用Lua脚本把它们打包在一个原子操作里可以解决并发超卖但无法解决ZSET元素量本身偏大的问题。更优的做法是“分桶聚合”不存每个请求的时间戳而是把时间戳对桶长取模后作为member比如member为秒级槽位score为槽位结束时间每次请求对该槽ZINCRBY 1。这样ZSET的元素数量被限制在窗口除以桶长几分钟窗口只有几十个元素内存极小。代价是窗口的检查精度下降也就是2.1讲的桶的效果。2.4 近似滑动分层与聚合还有一类工程化方案为了平衡内存和精度用多层时间桶做近似。例如把1秒切成10个100ms桶又额外维护4个250ms桶、2个500ms桶统计时根据当前时间从不同层取对应范围内的值再进行加权合并。这类似监控系统里HDR直方图的思路。分层滑动窗口的好处是既能覆盖一个较大的时间跨度又不用存全量请求。缺点是实现复杂、边界条件多而且仍然是近似压测时要验证毛刺是否还能接受。如果团队没有专门的中间件经验我不建议一开始就上分层方案先用均匀时间片分割观察曲线再决定要不要进一步优化。分布式限流的热点问题也可以通过分层本地缓存先扛住一层但这已经属于网关限流架构的范畴了。3. 手写一个平滑的滑动窗口限流器3.1 内存版实现环形数组加O(1)计数先看单机内存版这是理解后面所有变体的地基。我给出一段Python实现核心是用环形数组保存固定数量的小桶import threading import time class SlidingWindowRateLimiter: def __init__(self, limit: int, window_ms: int, bucket_count: int 100): self.limit limit self.window_ms window_ms self.bucket_count bucket_count self.bucket_ms window_ms // bucket_count self.buckets [0] * bucket_count self.total 0 self.current_bucket_index 0 self.current_bucket_start self._now_ms() self.lock threading.Lock() def _now_ms(self): return int(time.time() * 1000) def _advance(self, now_ms: int): elapsed now_ms - self.current_bucket_start if elapsed self.bucket_ms: return steps int(elapsed / self.bucket_ms) if steps self.bucket_count: steps self.bucket_count for i in range(steps): idx (self.current_bucket_index 1 i) % self.bucket_count self.total - self.buckets[idx] self.buckets[idx] 0 if steps 0: self.current_bucket_index (self.current_bucket_index steps) % self.bucket_count self.current_bucket_start self.bucket_ms * steps def allow(self) - bool: with self.lock: now self._now_ms() self._advance(now) if self.total self.limit: self.total 1 self.buckets[self.current_bucket_index] 1 return True return False解释一下关键点allow时先推进当前时间对应的桶把超出窗口的桶清掉判断total是否小于limit若放行则total和当前桶都加1。用锁解决并发问题。这个实现的时间复杂度是O(1)只涉及少数桶的减法和数组写入空间是O(N)。实际压测中单机每秒万级请求用这个逻辑完全没有问题。注意_advance里steps可能有多个比如进程被暂停了很久一次性跨过多个桶。此时需要把过期桶全部清掉但不能把当前桶之后的未来桶也清掉。环形数组索引计算要仔细简单起见这里只处理最多一个完整窗口长度超过窗口长度说明窗口内已经没有有效请求直接把total清零重置更干净。3.2 分布式版实现Lua脚本保证原子性Redis版我分两种写法。先给经典的逐请求精确版-- KEYS[1]: 限流key -- ARGV[1]: limit -- ARGV[2]: window_ms -- ARGV[3]: now_ms毫秒时间戳 -- ARGV[4]: 唯一请求ID redis.call(ZREMRANGEBYSCORE, KEYS[1], 0, ARGV[3] - ARGV[2]) local count redis.call(ZCARD, KEYS[1]) if count tonumber(ARGV[1]) then redis.call(ZADD, KEYS[1], ARGV[3], ARGV[4]) redis.call(PEXPIRE, KEYS[1], ARGV[2]) return 1 end return 0为什么一定要Lua因为如果没有原子性两个并发请求同时读到count999都会放行最终变成1001个限流失效。Redis的单线程模型保证Lua脚本内命令连续执行不会穿插其他客户端命令。把member设为唯一ID是为了防止同一请求重复计数PEXPIRE设置过期时间则是防止窗口内没有新请求时旧key一直占着内存。如果你想用分桶聚合降低ZSET元素量可以改成下面这种思路member固定为“时间戳对桶长取整后的值”score也是这个值请求到达时ZINCRBY 1。但是要注意这种写法需要额外维护桶的轮转否则一个旧桶的计数会一直留在窗口里。所以在生产上我更推荐用Lua管理多个key或者使用一个ZSET但定期清理具体要根据你的并发和内存预算取舍。逐请求精确版简单、正确2万QPS以下的场景都能用。3.3 参数怎么定窗口、桶数、毛刺的数学关系这是我觉得最值得收藏的一节。假设窗口长度为W桶数为N那么检查步长sW/N。每个步长内最多可能到达的新请求数量大约是QPS×s。如果我们假设流量是均匀的窗口总计数刚好处在limit边缘时由于一个步长的滞后窗口内最大瞬时计数近似为limit limit × s / W limit × (1 1/N)。所以N10时最多允许超出上限10%N100时是1%N1000时是0.1%。这就是“平滑度”的量化表达。如果你要求超限小于2%N至少取50如果要求小于0.5%N至少要200。下面是我常用的参数参考场景窗口长度桶数内存/元素规模峰值超限普通API限流1s2020个槽5%高精度核心接口1s200200个槽0.5%Redis分桶限流60s6060个member1.7%内存方面内存版数组占用N个整数假设8字节1000个桶也才8KB可以忽略。但Redis分桶版中N直接决定每个key的member数量这个要重点控制建议N不要超过几百。我平时定参数会先写一行公式if limit * (1 1/N) 下游最大容忍QPS: print(N need bigger)然后折中内存和延迟定一个最小值。另外还要考虑窗口W和步长s是否符合业务的“突发容忍时间”。例如一次营销活动允许每秒突增200%但持续时间不超过500ms那么你的步长最好小于500ms这样才能把短突发限制在可控范围内。步长越小系统响应越灵敏但代价是锁粒度更细、Redis调用更频繁需要压测验证。3.4 进阶平滑方案微步进与加权窗口如果连1%的毛刺都受不了有两个进阶方向。第一个是微步进把N设得很大甚至直接用单调时钟逐个时间戳判断但用数组索引来减少排序成本。窗口1秒、N10000时步长0.1ms内存约80KB单机完全扛得住问题是每次请求都要检查是否跨桶锁竞争会更明显。实测下来这种极细粒度适合核心接口不是所有接口都有必要。第二个是加权窗口。每个桶不再是一过即弃而是根据它离当前时刻的距离按指数方式衰减。例如当前窗口计数 Σ bucket_i × exp(-(now - bucket_end_i)/decay)其中decay是衰减常数。这样“过去的一桶水不会在一个瞬间突然全部消失”而是像一块被慢慢风化的石头总计数平滑地过渡。加权窗口对业务语义有影响比如限流阈值要从整数变成“权重和”运维看到报警会懵。我建议只在内部限流组件里用并且要有清晰的监控指标。4. 生产环境实测四个必须避开的坑4.1 时钟回拨会毁掉整个窗口限流依赖时间时钟一旦回拨窗口逻辑全线崩溃。单机版用time.time()时如果系统从NTP服务器同步时间突然倒退几百毫秒_advance会算出一个负的elapsed窗口可能被错误地“归位”导致放行大量请求。分布式版更危险不同实例时间偏移同一个Redis key里的score边界不一致限流结果就完全不可控。我的做法是单机内存版优先用单调时钟Java里是System.nanoTimePython里可以用time.monotonic但单调时钟不能直接和外部时间戳对齐所以需要记录一个启动时的墙钟偏移。Redis版本统一取Redis服务器的TIME命令避免各实例本地时间不一致如果不能改至少要把本地时钟偏差监控起来超过50ms就告警。4.2 并发检查-然后-更新一定会超卖这是最常见的坑。很多同学用Redis时先ZCARD取数量判断小于limit后再ZADD中间没有原子性。并发一上来两个请求同时读到999各自ZADD最终count变成1001限流失效。单机版如果用ConcurrentHashMap的get然后put同样会有这个问题。正确做法就是把“检查更新”塞进同一个原子操作单机用锁或AtomicInteger分布式用Lua脚本。如果你受限于环境不能写Lua至少用Redis的WATCHMULTI/EXEC乐观锁通过CAS方式重试。但实测下来WATCH在高争用下会大量重试效果不如Lua稳定。4.3 ZSET无限膨胀内存爆炸前的征兆精确ZSET方案最大的隐患是key内存只增不减。虽然我写了PEXPIRE但它只能保证整个key在窗口内没有请求时会过期不能保证窗口内每分钟有请求时窗口外的member会被及时清理。每个请求都执行ZREMRANGEBYSCORE按理说可以清理干净但如果你把清理和不清理的逻辑混在一起或者用了一个多长时间的key而没有调用清理命令内存就会悄悄涨上去。我遇到过一次线上事故QPS三万ZSET成员数在一个小时后涨到几百万Redis内存直接冲到4GB然后触发淘汰策略大量限流数据被逐出限流形同虚设。解决办法一是定期监控ZSET的ZCARD超过阈值自动扩容或降级二是使用分桶聚合把member数量限制到桶数级别三是给key设置一个合理的空闲过期时间比如窗口长度的两倍避免key常驻。不要依赖客户端清理Redis最好像一台冷酷的机器用完即丢。4.4 边界毛刺仍然存在的真相说句大实话即使你用了滑动窗口只要还是“离散桶”就一定有边界毛刺。因为total只在桶边界处更新桶内到达请求并不会立即被识别。举个极限例子N10窗口1秒0.5秒到0.6秒之间突然来了100个请求而且total已经接近limit这100个请求可能全部被放进去直到下一个桶边界才被计算。这就是为什么压测曲线还会有锯齿。要消除这个层面的毛刺只有两条路一是缩短步长让“不被识别”的时间窗口变小二是改成连续衰减的加权窗口或者令牌桶。如果产品和你说“要绝对平滑”我的建议是别用滑动窗口直接上令牌桶或漏桶那种匀速输出才是真正的平滑。滑动窗口更适合做“窗口内总量限制”的防护需求它本身不是匀速器。最后再分享一个我常用的调优套路。压测时我会看两个指标一个是窗口总计数曲线一个是每50ms的瞬时QPS。前者看是不是平稳贴着limit走后者看有没有超过limit×(11/N)的尖峰。如果尖峰都能压进预期范围就说明这个滑动窗口的“平滑度”已经达标。千万不要只盯着平均QPS平均曲线再平滑也掩盖不了单点毛刺给下游带来的压力。该说的坑都说得差不多了。我个人在实际项目里通常会把滑动窗口和令牌桶结合短时间突发用滑动窗口卡总量长时间输出用令牌桶做均速。你踩过的坑越多越会发现“平滑”不是一种算法而是你对自己的流量特征、对算法近似误差以及压测结果有多少敬畏。