4. 常见限流算法详解（下）：令牌桶算法、漏桶算法

在上一节中，我们深入剖析了计数器算法与滑动窗口算法的实现原理与边界问题。本节将聚焦于两种在金融低延迟系统中应用最广泛的“桶”模型算法——令牌桶算法与漏桶算法。理解它们在应对突发流量与平滑流量时的本质差异，是设计高可用限流架构的关键。

4.1 令牌桶算法（Token Bucket）

令牌桶算法允许一定程度的突发流量，同时保证长期的平均速率。其核心思想是：系统以恒定速率向一个桶中放入令牌，每个请求必须从桶中获取一个或多个令牌才能被处理。如果桶中没有足够的令牌，请求将被拒绝或等待。

4.1.1 核心参数与工作原理

算法流程如下：

1. 令牌补充：每次请求到达时，根据当前时间与上次补充时间的差值，计算应补充的令牌数（delta = (now - lastRefillTime) * rate / 1000），并将令牌数更新为 min(capacity, tokens + delta)。
2. 令牌消耗：如果当前令牌数 ≥ 请求所需令牌数（通常为1），则消耗对应令牌，允许请求通过；否则拒绝请求。
3. 突发处理：当桶满时，多余的令牌被丢弃，但桶中已有的令牌可以支撑瞬时高流量。

4.1.2 令牌桶算法流程图

4.2 漏桶算法（Leaky Bucket）

漏桶算法与令牌桶算法相反，它强制一个恒定的输出速率，不允许突发。其核心思想是：将请求看作水滴，桶底部有一个固定大小的漏洞，水以恒定速率流出。当桶满时，新进入的水滴会溢出（即请求被拒绝）。

4.2.1 核心参数与工作原理

算法流程如下：

1. 漏水计算：每次请求到达时，根据当前时间与上次漏水时间的差值，计算应漏出的水量（delta = (now - lastLeakTime) * leakRate / 1000），并将水量更新为 max(0, water - delta)。
2. 入桶判断：如果当前水量 + 1 ≤ 桶容量，则允许请求入桶（水量+1），请求被排队等待处理；否则请求被拒绝。
3. 恒定输出：无论入桶速率如何，出桶速率始终为 leakRate，实现绝对平滑。

4.2.2 漏桶算法流程图

4.3 突发流量 vs 平滑流量：性能差异对比

两种算法在应对不同流量模式时表现出截然不同的特性。下表从多个维度进行对比：

4.3.1 流量模式对比图

4.4 金融场景选型建议

• 交易核心链路（订单、支付、风控）：推荐使用 令牌桶算法。这些场景需要应对秒杀、行情波动等突发流量，同时要求低延迟。令牌桶可以在系统空闲时积攒令牌，在突发时快速释放，最大化资源利用率。
• 数据库/缓存保护：推荐使用 漏桶算法。数据库连接池、Redis 实例等对请求速率波动非常敏感，漏桶的恒定输出特性可以有效防止“惊群效应”和连接池打满。
• 第三方接口限流：根据第三方接口的 SLA 选择。如果第三方允许突发，使用令牌桶；如果第三方强制 QPS 上限且不接受突发，使用漏桶。