4. 令牌桶算法深度解析：算法原理、参数配置、优缺点与适用场景

令牌桶算法（Token Bucket）是业界应用最广泛的限流算法之一，其核心思想是通过一个“桶”来平滑突发流量，同时允许一定程度的突发请求通过。与漏桶算法的强制恒定速率不同，令牌桶在限制平均速率的同时，保留了应对流量尖峰的能力。

4.1 算法原理与工作流程

令牌桶算法基于以下三个核心概念运作：

• 令牌桶：一个虚拟容器，用于存放固定容量的令牌。
• 填充速率（r）：系统以恒定速率向桶中添加令牌，单位为“个/秒”。
• 桶容量（b）：桶最多能容纳的令牌数量，决定了允许的最大突发流量。

当请求到达时，算法执行以下判断：

1. 检查桶中是否有可用令牌。
2. 如果有，则取出一个令牌，请求被放行。
3. 如果没有，则请求被拒绝（或排队等待）。

4.2 核心参数配置详解

令牌桶算法的两个核心参数——填充速率（r）和桶容量（b）——共同决定了限流效果。合理配置这两个参数是系统稳定性的关键。

4.3 算法变体与实现考量

在实际工程中，令牌桶算法存在多种变体，以适应不同的分布式场景：

• 标准令牌桶：单机内存实现，令牌生成使用定时任务或延迟计算。
• 分布式令牌桶：使用 Redis 等中间件存储令牌计数，通过 Lua 脚本保证原子性。
• 预热令牌桶：系统启动时，桶从空开始缓慢填充，避免冷启动瞬间被突发流量打满。

以下是一个基于 Redis 的分布式令牌桶核心逻辑示例（Lua 脚本）：

-- KEYS[1]: 令牌桶 key
-- ARGV[1]: 当前时间戳（毫秒）
-- ARGV[2]: 填充速率 r（个/秒）
-- ARGV[3]: 桶容量 b
-- ARGV[4]: 请求消耗令牌数（通常为1）

local key = KEYS[1]
local now = tonumber(ARGV[1])
local rate = tonumber(ARGV[2]) / 1000.0  -- 转换为每毫秒速率
local capacity = tonumber(ARGV[3])
local tokens_needed = tonumber(ARGV[4])

-- 获取当前桶状态
local bucket = redis.call('hmget', key, 'tokens', 'last_refill_time')
local tokens = tonumber(bucket[1]) or capacity
local last_refill = tonumber(bucket[2]) or now

-- 计算时间差并补充令牌
local elapsed = now - last_refill
tokens = math.min(capacity, tokens + elapsed * rate)

-- 判断是否允许请求
if tokens >= tokens_needed then
    tokens = tokens - tokens_needed
    redis.call('hmset', key, 'tokens', tokens, 'last_refill_time', now)
    return 1  -- 放行
else
    redis.call('hmset', key, 'tokens', tokens, 'last_refill_time', now)
    return 0  -- 拒绝
end

4.4 优缺点分析

令牌桶算法并非万能，它在提供灵活性的同时，也引入了特定的复杂性。以下从多个维度进行对比：

4.5 适用场景与选型建议

令牌桶算法因其灵活性和对突发流量的友好性，在以下场景中表现尤为出色：

• API 网关限流：允许用户在短时间内调用多次（如刷新页面），但长期平均调用次数受控。
• 消息队列消费速率控制：消费者可以批量拉取消息，但整体消费速率不超过处理能力。
• 数据库连接池保护：允许短时间内的连接峰值，但防止连接池被持续打满。
• CDN 回源限流：允许突发回源请求，但控制平均回源带宽。

以下决策树可帮助你在不同场景下选择限流算法：