4、漏桶算法详解：算法数学模型、与令牌桶的区别、Go实现思路

4.1 漏桶算法数学模型

漏桶算法（Leaky Bucket）是一种流量整形与限流算法，其核心思想是将突发流量“削峰填谷”，强制请求以恒定速率被处理。算法名称来源于一个底部有漏洞的水桶：水（请求）可以以任意速率倒入桶中，但水只能从漏洞中以固定速率流出；当桶满时，新倒入的水会溢出（被拒绝）。

数学模型：漏桶算法可以用一个简单的积分模型描述。

• 桶容量（Capacity, C）：桶的最大容量，代表系统允许的最大突发请求积压量。
• 漏水速率（Leak Rate, R）：单位时间内从桶底漏出的请求数，即系统处理请求的恒定速率。
• 当前水量（Water, W）：当前桶中积压的请求数。
• 上次漏水时间（Last Leak Time, T）：上一次执行漏水操作的时间戳。

算法在每次请求到达时执行以下步骤：

1. 先漏水：根据当前时间与上次漏水时间的时间差，计算应漏掉的水量：leaked = (now - T) * R，更新 W = max(0, W - leaked)，更新 T = now。
2. 再判断：如果 W + 1 <= C，则请求通过，W += 1；否则请求被拒绝（溢出）。

4.2 漏桶算法与令牌桶算法的核心区别

漏桶算法与令牌桶算法（Token Bucket）是两种最经典的限流算法，常被混淆。下表从多个维度对比两者的本质差异：

4.3 漏桶算法 Go 实现思路

Go 语言实现漏桶算法有两种主流方式：基于时间戳计算（无锁或原子操作）和 基于定时器 + channel（goroutine 安全）。下面分别给出核心实现思路。

4.3.1 基于时间戳计算（高效、无额外 goroutine）

这种方式利用每次请求时计算时间差来模拟漏水，无需后台协程，适合高并发场景。

package leakybucket

import (
    "sync"
    "time"
)

type LeakyBucket struct {
    capacity   float64   // 桶容量
    rate       float64   // 漏水速率（请求/秒）
    water      float64   // 当前水量
    lastLeak   time.Time // 上次漏水时间
    mu         sync.Mutex
}

func NewLeakyBucket(capacity, rate float64) *LeakyBucket {
    return &LeakyBucket{
        capacity: capacity,
        rate:     rate,
        water:    0,
        lastLeak: time.Now(),
    }
}

func (lb *LeakyBucket) Allow() bool {
    lb.mu.Lock()
    defer lb.mu.Unlock()

    now := time.Now()
    elapsed := now.Sub(lb.lastLeak).Seconds()
    // 1. 先漏水：根据时间差计算漏掉的水量
    leaked := elapsed * lb.rate
    if leaked > 0 {
        lb.water -= leaked
        if lb.water < 0 {
            lb.water = 0
        }
        lb.lastLeak = now
    }

    // 2. 判断是否允许请求
    if lb.water+1 <= lb.capacity {
        lb.water++
        return true
    }
    return false
}

4.3.2 基于定时器 + channel（精确控制、适合消息队列）

这种方式启动一个后台 goroutine 以固定速率从 channel 中消费请求，适合需要精确控制处理节奏的场景。

package leakybucket

type LeakyBucketChan struct {
    bucket chan struct{} // 有缓冲 channel 模拟桶
    done   chan struct{}
}

// NewLeakyBucketChan 创建一个漏桶，capacity 为桶容量，rate 为每秒处理数
func NewLeakyBucketChan(capacity int, rate int) *LeakyBucketChan {
    lb := &LeakyBucketChan{
        bucket: make(chan struct{}, capacity),
        done:   make(chan struct{}),
    }

    // 后台 goroutine 以固定速率漏水
    go func() {
        ticker := time.NewTicker(time.Second / time.Duration(rate))
        defer ticker.Stop()
        for {
            select {
            case <-ticker.C:
                // 从桶中取出一个请求（漏水）
                select {
                case <-lb.bucket:
                default:
                    // 桶空，无事可做
                }
            case <-lb.done:
                return
            }
        }
    }()
    return lb
}

// Allow 尝试将请求放入桶中，桶满则拒绝
func (lb *LeakyBucketChan) Allow() bool {
    select {
    case lb.bucket <- struct{}{}:
        return true
    default:
        return false
    }
}

// Stop 停止后台漏水 goroutine
func (lb *LeakyBucketChan) Stop() {
    close(lb.done)
}

4.4 漏桶算法核心流程（SVG）

下图展示了漏桶算法在单次请求到达时的完整判断流程：

4.5 漏桶算法与令牌桶算法对比（SVG）

下图从系统架构视角对比两种算法的核心差异：

4.6 生产环境选型建议

• 数据库连接池限流：使用漏桶算法，防止突发查询打垮数据库。
• 消息队列消费端：使用基于 channel 的漏桶实现，精确控制消费速率。
• HTTP API 网关：优先使用令牌桶算法，允许用户短时突发请求。
• 视频流/音频流输出：必须使用漏桶算法，保证输出码率恒定。
• 微服务间 RPC 调用：根据下游 SLA 选择——下游有保护机制用令牌桶，否则用漏桶。