漏桶与令牌桶算法：流量控制的核心差异与应用场景

1. 流量控制的两大经典算法

上周排查线上服务抖动问题时，我发现一个有趣的现象：当突发流量达到正常值的5倍时，采用漏桶算法的服务直接丢弃了超限请求，而使用令牌桶的服务则出现了响应时间陡增。这促使我系统梳理了两种算法的核心差异，今天就用最直白的比喻和代码示例，说清楚它们各自的适用场景。

想象你正在管理一个游乐园：漏桶就像固定宽度的旋转门，每分钟只放行固定人数；令牌桶则是售票处，游客可以提前囤票（但不能超过上限），在任意时刻凭票入场。这两种机制在API限流、秒杀系统、云平台配额管理等场景中，直接决定了服务在高负载时的表现形态。

2. 漏桶算法深度解析

2.1 核心工作原理

漏桶（Leaky Bucket）的运作机制可以用物理模型完美解释：

1. 所有请求像水一样流入桶中
2. 桶底有个固定大小的孔洞，以恒定速率漏出请求（处理请求）
3. 当水量超过桶容量时，新的请求会被丢弃

用Go实现的核心逻辑：

go复制type LeakyBucket struct {
    capacity  int       // 桶总容量
    remaining int       // 当前剩余容量
    rate      time.Duration // 漏水间隔
    lastLeak  time.Time // 上次漏水时间
}

func (b *LeakyBucket) Allow() bool {
    now := time.Now()
    elapsed := now.Sub(b.lastLeak)
    
    // 计算这段时间应该漏掉的水量
    leaks := int(elapsed / b.rate)
    if leaks > 0 {
        b.remaining = min(b.capacity, b.remaining + leaks)
        b.lastLeak = now
    }
    
    if b.remaining > 0 {
        b.remaining--
        return true
    }
    return false
}

2.2 典型应用场景

• 视频转码服务：需要严格保证输出帧率不超过30fps
• 工业控制系统：PLC执行机构必须间隔≥100ms触发
• 金融交易网关：遵守交易所每秒订单数限制

关键特性：输出速率绝对平稳，但突发流量会导致大量请求被直接丢弃。去年我们电商大促时，支付系统用漏桶就损失了15%的订单请求。

3. 令牌桶算法实现细节

3.1 动态配额机制

令牌桶（Token Bucket）的精妙之处在于：

1. 令牌以固定速率生成（如每秒10个）
2. 每个请求需要消耗1个令牌
3. 令牌可累积，但不超过桶容量
4. 无令牌时请求可被拒绝或排队

Python示例展示突发流量处理：

python复制class TokenBucket:
    def __init__(self, capacity, fill_rate):
        self.capacity = float(capacity)
        self._tokens = float(capacity)
        self.fill_rate = float(fill_rate)
        self.timestamp = time.time()

    def consume(self, tokens=1):
        now = time.time()
        elapsed = now - self.timestamp
        
        # 先补充令牌
        self._tokens += elapsed * self.fill_rate
        self._tokens = min(self._tokens, self.capacity)
        self.timestamp = now
        
        # 检查令牌是否足够
        if self._tokens >= tokens:
            self._tokens -= tokens
            return True
        return False

3.2 实际应用案例

• API网关限流：允许短时突发（如秒杀前3秒）
• 带宽限制：TCP BBR算法的基础
• 微服务熔断：配合滑动窗口统计

某社交平台的数据显示，改用令牌桶后，其消息推送服务的峰值吞吐量提升了40%，同时保证99分位延迟可控。

4. 关键差异对比手册

5. 生产环境选型指南

5.1 必须选择漏桶的情况

• 医疗设备ECG信号处理（间隔必须≥50ms）
• 工业机器人控制指令下发
• 任何可能引发物理风险的场景

5.2 令牌桶更优的场景

• Web API网关限流
• 短视频feed流推送
• 实时游戏状态同步

去年我们迁移物联网平台时，对控制指令采用漏桶（保障设备安全），对日志采集采用令牌桶（利用带宽空闲时段），这种混合方案使整体吞吐量提升了27%。

6. 高级调优技巧

6.1 动态参数调整

现代云原生体系下，可以基于监控指标动态调整参数：

yaml复制# K8s Annotation示例
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  annotations:
    limiter.autoAdjust: "true"
    limiter.maxAdjustment: "200%"
    limiter.metric: "latency_p99"

6.2 混合模式实践

在Spring Cloud Gateway中组合使用：

java复制@Bean
public RateLimiter customLimiter() {
    return new AbstractRateLimiter() {
        @Override
        public Mono<Response> isAllowed(String routeId, String id) {
            // 关键接口用漏桶
            if(routeId.equals("payment")) {
                return leakyBucketCheck(id);
            }
            // 普通接口用令牌桶
            return tokenBucketCheck(id);
        }
    };
}

7. 性能压测数据参考

使用JMeter对两种算法进行对比测试（4核8G实例）：

可以看到：漏桶在超限时坚决丢弃请求，保证系统不崩溃；令牌桶则会尝试处理突发流量，但可能造成队列堆积。

8. 常见踩坑实录

1. 时间精度问题：早期用Redis实现时，发现时间回拨导致令牌激增

   • 解决：改用单调时钟（CLOCK_MONOTONIC）

2. 分布式一致性：集群环境下计数器不同步

   • 方案：采用Redis+Lua原子操作或分片计数

3. 预热策略缺失：冷启动时令牌桶为空导致大量拒绝

   • 改进：初始填充50%令牌，如Guava RateLimiter的warmupPeriod参数

去年某次大促，我们因为没设置预热参数，导致活动开始瞬间有8%的合法请求被误杀，这个教训值200万。