3、令牌桶实现：Go标准库rate.Limiter详解

Go 标准库 golang.org/x/time/rate 包提供了基于令牌桶算法的限流实现 rate.Limiter。它是生产环境中最常用的限流组件之一，具有线程安全、低延迟、接口简洁的特点。本节从核心结构、构造方法、阻塞等待与即时判断三个维度进行深度解析。

3.1 令牌桶模型与Limiter结构

rate.Limiter 内部维护一个令牌桶，其行为由三个核心参数决定：

下图展示了令牌桶的核心工作流程：

3.2 NewLimiter：构造限流器

NewLimiter 函数用于创建 Limiter 实例，其签名如下：

func NewLimiter(r Limit, b int) *Limiter

参数说明：

• r：rate.Limit 类型，本质是 float64，表示每秒允许的事件数。传入 rate.Limit(100) 即每秒100个令牌。
• b：int 类型，令牌桶最大容量，即突发上限。

常用构造方式：

import "golang.org/x/time/rate"

// 每秒10个请求，突发上限20
limiter := rate.NewLimiter(10, 20)

// 每秒0.5个请求（每2秒1个），突发上限1
limiter := rate.NewLimiter(rate.Limit(0.5), 1)

// 使用 Every 辅助函数：每100ms允许1个请求
limiter := rate.NewLimiter(rate.Every(100*time.Millisecond), 1)

3.3 Wait 方法：阻塞等待令牌

Wait 是阻塞式限流方法，适用于调用方可以等待的场景（如 RPC 调用、任务队列消费）。

func (lim *Limiter) Wait(ctx context.Context) error
func (lim *Limiter) WaitN(ctx context.Context, n int) error

行为特征：

• 当桶内令牌足够时，立即消耗 n 个令牌并返回 nil。
• 当令牌不足时，阻塞等待直到令牌补充足够，或上下文超时/取消。
• 如果 n > Burst，直接返回错误 rate.ErrLimitReservation。
• 如果上下文被取消，返回 ctx.Err()。

典型用法：

ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel()

if err := limiter.Wait(ctx); err != nil {
    // 超时或取消，执行降级逻辑
    log.Printf("限流等待超时: %v", err)
    return fallback()
}
// 正常处理请求
processRequest()

3.4 Allow 方法：非阻塞即时判断

Allow 是非阻塞方法，适用于不能等待的场景（如 HTTP 中间件、实时响应系统）。

func (lim *Limiter) Allow() bool
func (lim *Limiter) AllowN(t time.Time, n int) bool

行为特征：

• 如果桶内当前有足够令牌，消耗 n 个并返回 true。
• 如果令牌不足，直接返回 false，不阻塞、不等待。
• Allow() 等价于 AllowN(time.Now(), 1)。

典型用法：

// HTTP 中间件中的限流判断
func rateLimitMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        if !limiter.Allow() {
            http.Error(w, "Too Many Requests", http.StatusTooManyRequests)
            return
        }
        next.ServeHTTP(w, r)
    })
}

3.5 Wait 与 Allow 对比

下图展示了两种方法在调用链中的位置差异：

3.6 审计基线检查清单

• Burst 合理性：Burst 是否与业务峰值匹配？过小会导致正常突发被拒，过大会削弱限流效果。
• 上下文超时：使用 Wait 时是否设置了合理的 context timeout？无超时的 Wait 可能导致 goroutine 永久阻塞。
• Allow 误用：在需要严格限流的场景（如支付、写库）使用 Allow 可能导致限流失效，因为 Allow 不保证请求最终被处理。
• Limit 动态调整：Limiter.SetLimit() 和 Limiter.SetBurst() 可在运行时调整参数，审计时需确认调整逻辑是否线程安全且符合预期。
• 资源泄漏：Wait 内部创建的定时器在上下文取消时是否及时释放？Go 1.15+ 已修复相关泄漏问题，但旧版本需关注。