限流算法：给游乐园装一扇聪明的闸门

可视化演示

展示三大限流算法：令牌桶按速率生成令牌、漏桶匀速流出请求、滑动窗口统计时间窗内请求数。切换模式对比各算法原理，拖动滑块调节请求速率。

限流基础目标

老周被周末的游客吓怕了，他翻出园区的设备手册：每台过山车每小时最多接待 600 人，小卖部每分钟最多处理 20 笔订单。一旦超过这个数字，系统就会过热、卡顿甚至宕机。老周意识到，他需要的不是“不让游客来”，而是把每一秒进来的游客数量，控制在设备的额定容量之内。这就是限流的第一性原理：保护系统的可用性。

在计算机世界里，这个道理一模一样。你的服务器、数据库、第三方 API 都有各自的“额定容量”——吞吐量上限。平时流量平稳时一切正常，可一旦遇到秒杀、热点事件或恶意爬虫，请求量可能在几秒内飙升十倍。如果不加限制，数据库连接池会耗尽、CPU 会打满、整个服务雪崩式宕机。

限流的核心目标是削峰填谷：把瞬时洪峰削成平缓的长流水，让系统始终工作在安全区间。值得注意的是，限流与“拒绝用户”有本质区别——它更像游乐园门口的“排队缓冲区”，不是把游客赶走，而是让他们有序地等待。理解了这一点，后面所有算法的设计逻辑就都串起来了。

请求 → [限流器：每秒放行 N 个] → 后端服务

令牌桶算法

老周的第一版方案很像“售票积分”：他安排了一台自动售票机，每秒往桶里放入一张新票，桶最多存放 5 张。游客来了，先从桶里取一张票，取到就入园，取不到就过会儿再来。周末人多的时候，机器持续不断地产票；人少的时候，票就攒在桶里，等到人流高峰可以“预支”一部分。这套机制，就是令牌桶算法（Token Bucket）。

令牌桶的两个核心参数是令牌生成速率 \(R\) 和桶容量 \(B\)。每个请求必须消耗一个令牌才能通过；令牌由后台进程以速率 \(R\) 持续补充；桶的容量 \(B\) 限定了最多能积攒多少令牌——也就决定了系统能容忍的瞬时突发上限。

有趣的是，令牌桶巧妙地将“允许突发”和“长期平滑”统一了起来。因为桶里可以预先积攒令牌，所以当流量洪峰来临时，系统能迅速“烧掉”积累的令牌，应对短暂的流量尖峰；只要持续时间超过令牌补充的节奏，速率就会被 \(R\) 牢牢锁住。这就像游乐园里平时没人来的时候攒了一叠票，周末高峰可以快速消化一阵子，但票用完后就只能按每秒一张的速度慢慢进了。

漏桶算法

老周试了几天令牌桶，发现一个问题：令牌桶允许突发，可小卖部的收银员吃不消——一次性涌来 20 个人，虽然系统没崩，但收银员手忙脚乱。老周换了个思路：不搞“攒票”了，直接改成匀速放行。他在入园通道里装了一个“旋转闸机”，无论外面挤了多少人，闸机固定每 2 秒转一圈、放一个人进去。这就是漏桶算法（Leaky Bucket）。

漏桶算法的模型非常直观：把流量想象成倒入漏斗的水，水从漏斗底部的小孔匀速滴出。不管上方一次性倒入多少水，底下滴出的速度永远是恒定的 \(R\)。如果桶里已经积满了水，新来的请求（水）就会溢出被丢弃——这个“溢出”就是限流中的拒绝。

漏桶和令牌桶最大的区别，在于漏桶不允许任何突发。它的输出曲线是一条几乎水平的直线，流量被彻底“抹平”。代价是：当洪峰到来时，来不及处理的请求会被直接拒绝（或者进入一个队列慢慢等）。因此漏桶特别适合那些对流量平滑度要求极高、无法接受突发冲击的下游系统，比如真实世界里的数据库写入、短信发送通道。

滑动窗口算法

老周后来又遇到一个刁钻的漏洞。他规定“每分钟最多入园 100 人”，但发现有人在第 59 秒的最后一刻冲进来 90 人，第 61 秒又冲进 90 人——在短短 3 秒内，园内多了 180 人，完全失控。问题出在哪？因为他用的是“固定窗口”：每分钟重置一次计数器，窗口交界处的请求可以绕过限制。于是老周想到了滑动窗口（Sliding Window）：把一分钟切成 6 个 10 秒的小格子，每过 10 秒整个窗口就往前挪一格，始终统计“最近 60 秒”的总人数。

滑动窗口的核心思想是用细粒度的时间切片来逼近“任意连续窗口内不超过限制”这一理想目标。格子越细，统计越精确，但内存开销也越大。一个常用的简化实现是“滑动日志”：记录每个请求到达的时间戳，清理掉超出窗口范围的时间戳，剩下的计数就是当前窗口的请求数。

滑动窗口的优势在于精确且不会出现边界突刺，特别适合登录失败次数限制、验证码发送频率这类“固定周期内次数敏感”的场景。它的短板在于需要维护连续时间段的计数状态，内存开销比前两种算法略高。对老周来说，滑动窗口就像一本“滚动记账本”——每时每刻都只看最近十分钟入园了谁，超了就在门口拦一下。

算法选型对比

集齐了三种闸门方案，老周把它们摆在一起对比，发现各有各的脾气。他总结出一张简单的“选型口诀”：要容忍瞬时爆发，选令牌桶；要强制匀速稳定，选漏桶；要精确控制周期内次数，选滑动窗口。

从设计目标看，令牌桶有“两个旋钮”（生成速率 \(R\) 和桶容量 \(B\)），灵活性最高。桶容量越大，对突发流量的容忍度越高；比如电商大促开场前可以预热令牌，让商品页扛住第一波抢购。漏桶只有“一个旋钮”——流出速率 \(R\)，一切突发都被队列吸收或丢弃，适合对接无法抗峰的下游依赖，比如调用银行接口或发送短信。而滑动窗口提供的是“精确到秒级”的计数能力，不关心速率快慢，只关心“在任意一个窗口里别超过 N 次”。

具体到工程实践，选型的判断依据可以归纳为三点：业务对突发是否敏感、系统能接受多大的状态存储开销、统计口径是速率还是次数。Nginx 的 limit_req 模块用的是漏桶变体，它强调平滑地处理请求；Google Guava 的 RateLimiter 是经典的令牌桶实现；而社交平台的“每分钟最多发送 5 条私信”这类限制，用的则是滑动窗口。没有绝对最好的算法，只有当前业务场景下最合适的选择。

代码实现要点

老周打算把这套逻辑写成代码，他找到了园区的程序员小刘。小刘提醒他：实现限流器有三个容易踩坑的地方。第一是原子性——多线程或分布式环境下，多个请求同时检查并扣减令牌，必须保证操作是原子的，否则会出现两人合用一张票的情况。单机可以用锁（Lock），分布式则要用 Redis 的 Lua 脚本。

第二是时间源。很多人用 System.currentTimeMillis() 获取当前时间，但系统时钟可能被 NTP 校准而回调，导致限流失灵。正确做法是使用单调时钟（如 Java 的 System.nanoTime()、Python 的 time.monotonic()），它只保证“向前走”，不受墙钟跳变影响。

第三是内存与精度的权衡。滑动窗口如果每个请求都记录时间戳，内存开销会随请求量线性增长；工程上常用“分桶计数”来压缩——比如按秒分桶、只存每个桶的计数器，牺牲少量精度换取稳定的内存占用。对于令牌桶，实现时不必真的开一个后台线程去生成令牌——只需要记录上次补充时间，用“惰性计算”在每次请求时补算增量即可，这与我们前面讲的“生成本质是时间函数”完全一致。

分布式限流实战

单机限流再成熟，也解决不了老周的新烦恼：游乐园开了三个入口，每个入口各自数人头，结果三扇门加起来放进了三倍的人。这就是分布式限流要解决的问题——多个实例共享同一个全局计数器，谁也不能各自为政。最通用的方案是引入 Redis 作为集中式存储，所有实例的请求都到 Redis 里换取放行资格。

但这里有个隐忧：Redis 操作不是天然原子的。“检查计数是否超限”和“计数加一”是两步操作，多实例并发执行时会产生竞态条件。小刘给出的解法是用 Lua 脚本——把检查、计数、扣减三个动作封装进一个 Redis 的 Lua 脚本，Redis 保证脚本整体的原子性。这样一来，无论多少台机器并发请求，只要发给 Redis 的脚本是同一个，最终的计数就是精确的。

分布式限流最常见的落点，是API 网关（如 Kong、Nginx + Lua、Spring Cloud Gateway）上的全局限流插件。网关前置在服务集群入口，统一配置限流策略，按用户 ID、IP 或接口维度限流。比如在秒杀场景中，网关层用令牌桶限定“每秒最多放行 5000 个请求”进入后端，后端再叠加滑动窗口限制“每个用户每分钟最多下单 1 次”——多级限流各司其职，系统才能在高并发洪峰中安稳运行。老周的故事也终于有了圆满结局：游乐园三个入口共享同一个“总闸”，设备和游客都得到了最好的安排。

AI 应用场景

Python 演示

import threadingimport timefrom collections import deque  class TokenBucket:    """令牌桶限流器"""     def __init__(self, rate, capacity):        self.rate = rate        self.capacity = capacity        self.tokens = capacity        self.last_refill = time.monotonic()        self.lock = threading.Lock()     def try_acquire(self, need=1):        with self.lock:            now = time.monotonic()            self.tokens = min(                self.capacity,                self.tokens + (now - self.last_refill) * self.rate            )            self.last_refill = now            if self.tokens >= need:                self.tokens -= need                return True            return False  class SlidingWindowCounter:    """滑动窗口限流器：按秒分桶统计"""     def __init__(self, window_sec, limit):        self.window_sec = window_sec        self.limit = limit        self.buckets = deque()        self.lock = threading.Lock()     def try_acquire(self):        with self.lock:            now = time.time()            while self.buckets and self.buckets[0][0] <= now - self.window_sec:                self.buckets.popleft()            total = sum(cnt for _, cnt in self.buckets)            if total >= self.limit:                return False            if self.buckets and self.buckets[-1][0] == int(now):                sec, cnt = self.buckets[-1]                self.buckets[-1] = (sec, cnt + 1)            else:                self.buckets.append((int(now), 1))            return True  def simulate_requests(name, limiter, total):    allowed = 0    for i in range(total):        if limiter.try_acquire():            allowed += 1        time.sleep(0.01)    print(f"{name}: {total} 次请求，放行 {allowed} 次")  if __name__ == "__main__":    bucket = TokenBucket(rate=5, capacity=3)    window = SlidingWindowCounter(window_sec=10, limit=3)    simulate_requests("令牌桶(速率5,容量3)", bucket, 20)    simulate_requests("滑动窗口(10秒限3次)", window, 20)

1. time.monotonic()获取单调时钟时间，避免系统时钟跳变导致限流计算错误。
2. self.tokens + (now - self.last_refill) * self.rate惰性补充令牌：不靠后台线程，只在请求时按时间差补算。
3. min(self.capacity, ...)令牌数不能超过桶容量，超出的令牌直接丢弃。
4. with self.lock:加锁保证多线程环境下“检查-扣减”两步的原子性。
5. self.buckets.popleft()清理超过窗口时间范围的过期时间桶，控制内存占用。
6. sum(cnt for _, cnt in self.buckets)把窗口内所有分桶的计数加起来，判断是否超限。

常见误区

面试题