限流算法核心取舍：令牌桶与漏桶该如何选型

限流算法的核心取舍：令牌桶和漏桶，到底该怎么选

先聊一个大多数后端同学都经历过的场景。某个周三下午，运营那边突然上了一波活动，流量瞬间从平时的几百 QPS 冲到几千甚至上万，服务端监控开始飘红，数据库连接被打满，接口耗时从 30ms 一路涨到 3 秒。你一边看着报警群的消息，一边在想：明明上了限流，怎么还是被打穿了？

问题往往出在限流算法选型上。很多人一听“限流”就随手甩一个令牌桶进去，至于底层是令牌桶还是漏桶、参数怎么定、各自的瓶颈在哪里，完全没深究。等线上真的出事，才发现自己手里那套限流器根本不符合业务场景。

这篇就详细聊清楚限流算法里的两大经典方案：令牌桶和漏桶。我会把原理掰开来讲，不绕弯子，然后给出具体的选型参考、实现思路和线上踩坑实录。适合正在做网关、API 治理、微服务保护的后端开发，以及所有被高并发流量折腾过、准备给系统加保护措施的工程师参考。

1. 先搞清楚限流到底在解决什么问题

限流不是新鲜概念，但很多人一上来就陷入算法细节，反而忽略了它要解决的本质问题。限流的核心目标，是在单位时间内限制请求进入系统的速率，防止突发流量打垮下游资源。它和熔断、降级、隔离共同构成了服务自我保护的基本方法，但四者的切入角度完全不同。

1.1 为什么固定窗口计数不够用

固定窗口是初学者最先接触的限流方式。做法很简单：把时间切成固定大小的时间片，比如 1 秒一片，每个时间片内维护一个计数器，请求进来就加 1，超过阈值就拒绝。

但固定窗口有一个老生常谈的临界问题。假设限制是 100 次/秒，时间片切在 00:00 到 00:01，另一个时间片从 00:01 到 00:02。如果请求在 00:00:00.900 到 00:01:00.100 这 200ms 内冲了 200 个请求，前 100 个落在第一片，后 100 个落在第二片，两个窗口都没超限，但实际 200ms 内后端吃了 200 个请求。系统一样会被压垮。

滑动窗口能部分缓解这个问题，但它本质上仍然是一种“记录历史请求数”的统计方案。要真正做到对流量形态的精细控制——既允许一定的突发，又不能让突发无限放大，还得保证请求输出速率不能超过下游处理能力——光靠计数就不够了。这时候令牌桶和漏桶才体现出真正的价值。

1.2 从“计数”到“整形”的思路转变

计数型限流器像是一个看门人，他检查“过去这段时间你来了多少人”；而令牌桶和漏桶更像是一个水龙头，它在控制“水每秒能流出多少”。后者不做简单的统计，而是通过对“令牌”或“水桶容量”的动态管理，来对流量做出更细粒度的整形。

我见过很多团队从固定窗口迁移到令牌桶之后，最直观的感受是：线上不再因为瞬时毛刺而触发限流误伤，同时后端压力也更平稳了。这不是玄学，而是算法本身的特性带来的差异。接下来我们先从漏桶讲起，再讲令牌桶，因为理解这两者的逻辑差异，是选型的基础。

2. 漏桶算法：把输出速率压成一条直线

漏桶算法在描述上非常形象：想象一个底部有洞的水桶，水从顶部注入，从底部以一个固定速率漏出。如果注水的速度超过了桶的容量，水就会溢出。映射到系统上，请求就是注入的水，桶底部那个洞的漏水速率就是系统处理请求的固定速率，桶的容量就是缓冲积压请求的队列大小，溢出的水就是被拒绝的请求。

2.1 漏桶的工作原理与核心数据结构

漏桶的实现通常依赖一个 FIFO 队列。当一个请求到达时，如果队列未满，请求进入队列等待被“以固定速率”取出处理；如果队列已满，请求直接被丢弃。后端处理器只按照设定的速率从队列头部取请求，不管外面来了多少请求，后端看到的请求速率永远是恒定的。

这带来的最直接效果是：输出速率被强制平直。无论上游流量是平稳还是突刺，经过漏桶之后，下游服务感受到的请求节奏完全一样。这种特性在以下场景里特别有用：

• 数据库写入操作，例如订单入库、日志落盘，下游对并发写入非常敏感
• 第三方 API 调用，对方明确约束了 QPS，超了直接封 Key
• 需要严格的流量整形，后端的线程池大小、连接数都是按固定 QPS 来设计的

用代码来表达，漏桶的核心逻辑其实非常直白。假设我们用 Go 来实现一个最简单的漏桶限流器：

type LeakyBucket struct { rate float64 // 每秒处理的请求数 capacity float64 // 桶的容量 water float64 // 当前桶中的水量 lastLeakMs int64 // 上次漏水时间 mu sync.Mutex } func (l *LeakyBucket) Allow() bool { l.mu.Lock() defer l.mu.Unlock() now := time.Now().UnixMilli() // 先漏水：按照速率把这段时间应该漏掉的水减掉 elapsedMs := now - l.lastLeakMs leakAmount := float64(elapsedMs) / 1000.0 * l.rate l.water -= leakAmount if l.water < 0 { l.water = 0 } l.lastLeakMs = now // 尝试注水 if l.water < l.capacity { l.water++ return true } return false }

你注意这段代码的核心逻辑：每次请求进来，并不直接看队列的状态，而是先模拟“漏水”这个过程，把这段空闲时间应该漏掉的水量减掉，然后再判断能不能装下当前这个请求。这个“时间换水量”的思路，其实是所有限流算法里都绕不开的基础操作。

2.2 漏桶的两个关键局限

漏桶最大的优点是输出稳定，但它的局限也同样明显。

第一，它处理突发流量的能力很弱。假设桶容量为 100，速率为 10 QPS。如果突然来了 100 个请求，它们会全部进入桶中，然后以 10 QPS 的速度向后端释放。但这 100 个请求的用户体验是：最后那个请求等了差不多 10 秒才被处理。对于大多数业务接口来说，等待 10 秒已经超出前端超时时间，用户早就放弃了。

第二，队列积压是漏桶绕不开的问题。如果持续有请求进来，桶总是满的，部分请求被拒绝，已进入的请求又需要排队。在超时严格的场景下，大量超时请求累积在队列中，反而可能拖垮后端——因为后端处理它们已经没有意义了。排队的请求浪费了线程池、数据库连接等宝贵资源。

我当时第一次把漏桶用在业务接口上，很快就发现了一个问题：虽然后端压力曲线确实平了，但用户侧的超时率不降反升，原因就是排队时间超过了 HTTP 层的 read timeout。从那以后我对队列有一定的心理阴影，后来再遇到限定输出速率的场景，我优先考虑的是队列长度设置和超时时间的匹配。

3. 令牌桶算法：允许突发，又不失控

接下来是应用最广泛的令牌桶。和漏桶不同，令牌桶的思路是反过来：桶里装的不是请求，而是令牌。请求要进来，必须先拿到一个令牌，拿到令牌就会被放行，拿不到就拒绝或者等待。令牌由后台以固定速率持续生成，桶的容量决定了最多能攒多少个令牌。

3.1 为什么令牌桶能兼顾平均速率和突发流量

令牌桶的妙处在于，它把“平均速率控制”和“突发流量容忍”巧妙地统一在了一起。我们来拆解一下：

• 后台以 rate 的速率往桶里放令牌，每秒放 rate 个
• 桶最多容纳 burst 个令牌。如果桶满了，新生成的令牌直接丢弃
• 请求到达时，从桶里取一个令牌。桶里没令牌，就拒绝请求或阻塞等待

如果系统空闲了一段时间，桶里的令牌就会累积到最大容量。这时候突然来一波流量，所有请求都能立刻从桶里取到令牌——因为它们用的是之前“存下来”的令牌。这就允许系统在短时间内容忍高于平均速率的突发流量。而这笔账很好算：突发流量最多能到多少？答案是桶容量 burst。超过 burst 的请求，才会被限流拒绝。

换句话说，令牌桶的长处在于，它在约束平均速率的同时，允许一定程度的突发，并且把突发值限定在一个明确可规划的范围内。这是漏桶做不到的，也是它在网关、API 网关场景中胜出的核心原因。

用一段 Go 代码来展示令牌桶的“非阻塞取令牌”逻辑：

type TokenBucket struct { rate float64 // 每秒生成令牌数 capacity float64 // 桶容量 tokens float64 // 当前令牌数 lastTimestamp time.Time mu sync.Mutex } func (t *TokenBucket) Allow() bool { t.mu.Lock() defer t.mu.Unlock() now := time.Now() // 先补充令牌 elapsed := now.Sub(t.lastTimestamp).Seconds() t.tokens += elapsed * t.rate if t.tokens > t.capacity { t.tokens = t.capacity } t.lastTimestamp = now // 取令牌 if t.tokens >= 1 { t.tokens-- return true } return false }

注意令牌补充这个动作是惰性计算的，也就是说我们不需要真正起一个 goroutine 定时放令牌，而是在每次请求到达的时候，用当前时间和上次取令牌时间的差值，算出这段时间应该新增多少令牌。这个方法是所有生产级令牌桶实现的通用手法，避免了定时器带来的系统开销和时钟同步问题。

3.2 令牌桶的生产级实现参考

如果你不想自己写，生产环境里可以借助现成的库。以 Go 为例，golang.org/x/time/rate就是官方扩展库里的令牌桶实现，它的使用方式非常简洁：

limiter := rate.NewLimiter(rate.Limit(10), 100) // 每秒 10 个令牌，桶容量 100 if limiter.Allow() { // 放行 } else { // 限流 }

这里有两个参数值得重点关注。第一个是速率 rate，它决定平均 QPS；第二个是容量 burst，它决定瞬时可放行的最大请求数。这两个参数的乘积关系直接左右了限流效果，我一般建议在配置阶段就通过压测把这两个值确定下来，而不是凭感觉拍脑袋。

Java 生态的同学可以用 Guava 的RateLimiter，或者基于 Redisson 的分布式限流方案。Guava 还额外提供了预热的实现方式SmoothWarmUp，它的设计理念是冷启动时不直接把速率拉到最大，而是渐进式提升，避免冷系统被瞬时流量打崩。

3.3 令牌桶的弱点同样不能忽视

令牌桶并非万能。最典型的问题是：如果配置不合理，它可能在一定时间段内输出的总流量超过下游的真实承载能力。比如 rate 设为 10，burst 设为 100，假设系统每过 10 秒来一次突发，那么平均速率其实已经达到 10 + 100 / 10 = 20 QPS，超出了设定的 10 QPS 平均值。

另一个问题是令牌桶不关心请求本身处理耗时的变化。如果后端处理能力下降，比如某个接口走到了慢 SQL 分支，响应时间从 20ms 涨到 500ms，令牌桶依然按原速率放令牌，这时候后端照样会被压垮。所以令牌桶通常要和超时熔断机制配合使用，而不能单独作为系统保护措施。这一点很多人容易忽略。单独靠一个限流器解决所有问题，并不现实。

4. 两大限流算法的适用场景与选型对比

讲了这么多原理，还是要落到选型上。我的建议非常直接：绝大多数场景优先选令牌桶，因为它在控制平均速率的同时保留了突发能力，符合大多数业务接口的真实流量模型。而漏桶更适合对后端稳定性要求极高、完全不允许流量突刺的场景。

4.1 从业务流量模型出发的选型建议

判断标准其实很简单，就看你下游能不能承受突发请求。如果下游是缓存服务、无状态接口，突发请求通常不会造成严重问题，选择令牌桶会带来更好的用户体验；如果下游是关系型数据库、消息队列的消费者任务、或者第三方限流严格的 API，那么漏桶的恒定速率输出能有效兜底，保护下游不被瞬时流量冲垮。

甚至在一些场景下可以考虑组合模式。比如网关层用令牌桶快速放行绝大多数请求，但在进入写数据库的 DAO 层前置漏桶，把写流量的速率严格压住。这样既能保证用户体验，又能守住数据库的底线。这种分层限流的思路在 MySQL 写入场景里非常实用。

我在一个交易系统的订单接口上试过这套组合：应用接入层用令牌桶（rate 1000，burst 2000）做正常准入，底层事务操作入口再用漏桶（rate 200）把数据库请求限死。这样活动来了以后，API 层面不会出现大规模拒绝，用户体验尚可，而数据库的负载曲线变得非常平滑，从根源上避免了连接池被打满的问题。

4.2 选型对照表

为了方便参考，我把两种算法在不同维度下的表现整理成一个表格，这样你在做方案评审时可以直接对着表格判断。

这张表最核心的一条差异，就是“对突发流量的态度”：令牌桶认可突发，漏桶拒绝突发。这不是谁对谁错的问题，而是由业务特性决定的。接口层面允许小突发来提升体验，数据库层面不允许任何突刺来保障安全，两者本质上并不矛盾。

5. 两种限流算法的实现细节与参数整定

选型只是第一步，真正考验功力的是参数怎么设。我见过太多团队把 rate 和 burst 写成 100 和 200，然后就上线了，没有任何压测依据，最后线上效果全凭运气。参数整定是个需要认真对待的工程问题。

5.1 怎么计算限流阈值

我个人的习惯是倒推法：先找到整个链路中最薄弱的那个环节，以它的处理能力为基准来确定限流阈值，而不是自己想当然地设置一个“感觉差不多”的 QPS。

假设你的服务部署了 20 个 Pod，每个 Pod 里面接口的线程池大小为 200，单个请求平均处理耗时 50ms。单 Pod 每秒最多能处理的请求数大约是 200 / 0.05 = 4000。但你不能把限流值直接打到 4000，因为你还要留出 CPU 余量、垃圾回收的影响、慢请求带来的尾部延迟。一般我建议控制在理论峰值的 60%~70%，也就是单个 Pod 限流 2500 左右。如果集群入口做统一限流，就用这个值乘以 Pod 数量，再乘一个 0.8 的冗余系数。

burst 的设置要结合请求来源形态来决定。如果业务天然有秒杀、活动突发，burst 可以适当调大，让令牌桶把流量“匀”出去。如果请求是偏向平稳的，burst 其实不用设太大，过大的 burst 反而会在突发瞬间压垮后端。一般情况下，burst 取 rate 的 1~2 倍是一个可以接受的初始值。之后根据压测结果微调。

5.2 令牌桶和漏桶的实现要点

回到代码层面，无论你用什么语言实现，有几个点必须处理好。

第一，并发安全。限流器必然被多线程/多协程并发访问，如果你的实现没有加锁或者用原子操作，只在本地测试时看不出问题，一旦放量上线，数据竞争会引入各种诡异问题。Go 里建议用 mutex 或者 atomic 配合 cmp 操作。Java 里可以使用AtomicLong或直接使用 Guava、Resilience4j 这些成熟库。

第二，时间的单调性问题。在计算应补充的令牌数时，不要直接用System.currentTimeMillis()这种墙钟时间来计算差值，因为系统时钟调整会导致差值计算错误。Go 里用time.Now()也要注意，最稳妥的方式是只取差值，不要跨系统做时间同步。

第三，令牌桶实现中令牌数不建议用整数。用浮点数保存令牌数，每次补充时按“速率 * 时间差”累加，等到积累足够一个完整的令牌时才允许通过。这样可以做到非常平滑的补充逻辑，而且能减少误差积累。

下面是一段带积分式补充逻辑的 Java 代码示例，我只保留关键部分，方便你参考它的结构：

public class TokenBucketLimiter { private final double rate; // 每秒补充令牌数 private final double capacity; // 桶容量 private double tokens; // 当前令牌数 private long lastRefillTimeNs; // 上次补充时间 public TokenBucketLimiter(double rate, double capacity) { this.rate = rate; this.capacity = capacity; this.tokens = capacity; this.lastRefillTimeNs = System.nanoTime(); } public synchronized boolean tryAcquire() { long nowNs = System.nanoTime(); double tokensToAdd = (nowNs - lastRefillTimeNs) / 1_000_000_000.0 * rate; tokens = Math.min(tokens + tokensToAdd, capacity); lastRefillTimeNs = nowNs; if (tokens >= 1) { tokens -= 1; return true; } return false; } }

一个容易忽略的细节是，tryAcquire用synchronized保证并发安全，这在低并发场景下没问题，但在高 QPS 下会引入一定的锁竞争开销。生产环境可以基于这个结构演化出分段锁或者无锁方案，但在起步阶段，保证正确性比极致性能更重要。

5.3 漏桶实现里的队列长度设定

漏桶实现里最关键的参数有四个：处理速率、桶容量、队列长度、拒绝策略。很多人只关注前两个，忽略了队列长度。队列长度决定了请求最大等待时间：等待时间 = 队列长度 / 处理速率。假设速率为 10 QPS，队列长度 100，那么最后一个请求要等 10 秒。如果业务超时时间只有 3 秒，那这 100 个排队的请求大概率全部超时，白白浪费系统资源。

所以我的建议是：队列长度应该由“最大可接受等待时间”反推。如果业务最多能容忍 1 秒排队，速率是 10 QPS，那么队列长度最多 10。任何超出这个范围的请求，直接拒绝掉而不是排队等待。快速失败永远比让请求带着超时风险排队更好，这一点在微服务架构里尤其重要。

6. 实战案例：从一次线上事故看两种算法的选型决策

讲了这么多理论和代码，不如用一个真实案例来收束。这个案例我在多个场合分享过，它也最能说明为什么“选对算法”比“用好算法”更基础。

6.1 事故背景与排查过程

当时我们维护的是一个偏 C 端的积分查询服务，日常 QPS 大约在 5000 左右。系统架构是 Nginx → 应用网关 → 业务服务 → MySQL。某天下午活动上线后，网关层先是出现大量 503，接着业务服务线程池被打满，MySQL 活跃连接数飙升，最终导致整个集群不可用。

第一反应是扩容。但扩容后问题并没有解决，原因是流量还在不断增长，数据库连接已经超过了极限。后来我们拉取了网关日志和数据库监控，发现一个很有意思的现象：当时网关已经配置了限流，用的是漏桶，速率为 8000 QPS，队列长度 2000。表面上看，8000 的速率远高于日常 5000 的 QPS，不应该出问题。

但问题恰恰出在队列上。活动带来的瞬时流量冲到了 30000 QPS，漏桶放进了 2000 个排队请求，后面的处理速率是死守 8000。这 2000 个请求里，有一部分是极端耗时的用户批量查询，它们的执行时间达到了秒级，拖慢了 MySQL 的整体吞吐。数据库的连接池因此被耗尽，后续所有查询都在等待连接，整个系统进入了雪崩状态。

6.2 调整方案与最终效果

我们后来做的调整分两步。第一步，把网关层的限流算法从漏桶改为令牌桶，rate 设为 8000，burst 设为 8000。这样正常流量完全不受影响，瞬时突发的多余请求会被令牌桶自动拦截，而不是在队列里排队等死。第二步，在数据库访问层之前，单独加了一个令牌桶限流器，rate 设为 5000，一旦超过，直接返回失败，而不是让请求继续打到数据库。

这个方案的核心理念是：外层放宽一部分突发，让用户体验不至于太差；内层严格限制，保证数据库最多只承担 5000 QPS 的查询压力。上线后观察了一周，数据库连接数的曲线变得非常平稳，成功率和可用性都恢复到了 99.99% 以上。

那次事故让我彻底想通了一件事：限流算法不是一个孤立的组件，它必须放在全链路里去考量。你在哪个环节限流、限多大、怎么处理被限的请求，这些决策叠加起来，才是整个系统的真实保护能力。而不是部署一个限流器就万事大吉。

7. 常见问题与避坑建议

最后集中整理一下在生产实践中反复遇到的坑，你按这个清单排查，可以少走很多弯路。

7.1 限流器的常见配置错误

第一个坑是 burst 设置过大。有人为了让系统“更稳”，把 burst 调得很高，结果突发流量进来时，后端还是被瞬间打崩。记住令牌桶的突发上限就是 burst，这个值是你对下游保护的最后一道防线，一定要经过压测验证，而不是拍脑袋。

第二个坑是限流粒度不均匀。网关层做了限流，业务层也做了限流，但两层的参数没有联动设计，导致内外限流不一致，有的请求在网关被放行，到了业务层又被拒绝。建议限流的层级划分要有明确规划：网关层做粗粒度保护，服务层做细粒度业务维度限流，数据库层做最严格保护。

第三个坑是限流器本身成为瓶颈。在高并发场景下，如果限流器使用了分布式锁或中心化存储，那么它本身就是单点。比如用 Redis 做分布式限流时，如果 Redis 超时或连接池打满，限流器可能直接把大量请求拒绝掉。集体橱此类问题，一定要给在 Redis 不可用时设计降级策略。

第四个坑是只对入口做限流，忽略了内部依赖的自我保护。比如外部请求到了服务 A，A 会调用 B，B 会调用 C。如果只在 A 入口做限流，B 和 C 依然可能被内部调用流量打垮。全链路都要有保护意识。

第五个坑是静态限流值不适配动态流量。日常流量 1000，活动流量 5000，如果你把限流值固定为 1000，活动来了全被限，用户骂声一片。建议限流参数支持动态配置，配合监控数据做实时调整，而不是每次发版改配置。

7.2 线上优化的几条实操经验

关于参数调整，我一般建议每次只改一个参数，改完后观察至少一个业务周期。不要同时动 rate 和 burst，否则你根本不知道是哪个参数的功劳。

补充一个和限流关系密切但经常被忽略的操作：被限流的请求一定要记录足够多的上下文信息。当时我们排查那场事故时，一开始根本不知道是漏桶队列积压导致的，后来是因为我们额外打印了限流器的队列长度和拒绝原因，才定位到问题。良好的限流日志是线上排障的第一手资料。

还有一条经验：限流器一定要有可视化的监控面板，至少包含允许量、拒绝量、当前桶水位三个指标。拒绝量突增能直接反映流量异常，桶水位的实时值则能告诉你当前系统的“容量余量”。有了这些数据，你在做容量规划时就不会凭空猜测。

最后说说压测。很多人只在单体压测时测限流器，却不测全链路。要求限流器在 3 倍总流量下保持稳定，是基本要求。压测场景最好包含长尾请求、慢请求、超时请求，这样你才能真实了解限流器在恶劣条件下扮演的角色，而不只是它号称的参数。

限流这东西，看起来每个字都认识，但真正进入生产环境，你才会意识到它和业务模型、系统拓扑、下游能力有多深的耦合。我个人的体会是：不要迷信某个算法是最好的，也不要只认一个限流组件，把它放到整个系统的吞吐模型里去看，参数和行为才有意义。令牌桶和漏桶，一个给了你灵活性，一个给了你确定性，选哪一个，取决于你想保护什么，以及你愿意在用户体验上做出多大的牺牲。如果下次再被问“限流算法选哪个”，我希望你能不只是回答“令牌桶”，而是能说出背后这层取舍逻辑。