17370845950

令牌桶算法适合控制平均速率和突发流量，Go可用rate.Limiter实现；支持按用户/IP精细化限流；分布式场景推荐Redis+Lua脚本；需增强可观测性与降级能力。

基于令牌桶的限流实现

令牌桶算法适合控制请求的平均速率和突发流量。Golang标准库没有直接提供，但可用 golang.org/x/time/rate 包轻松实现。

核心是 rate.Limiter，它内部维护一个按固定速率填充令牌的桶。每次请求调用 Allow() 或 Wait() 判断是否可被处理：

• Allow() 立即返回 true/false，不阻塞
• Wait() 阻塞等待令牌（可设超时），适合需强控延迟的场景

示例：每秒最多允许 10 个请求，最大突发 5 个：

limiter := rate.NewLimiter(10, 5)
http.HandleFunc("/api/data", func(w http.ResponseWriter, r *http.Request) {
    if !limiter.Allow() {
        http.Error(w, "Too many requests", http.StatusTooManyRequests)
        return
    }
    // 处理业务逻辑
})

按用户或IP维度做精细化限流

全局限流不够灵活，常需区分来源。可在中间件中提取标识（如 X-Forwarded-For、Authorization 或自定义 header），为每个标识维护独立限流器。

使用 sync.Map 缓存限流器，避免高频新建对象：

• 键为用户ID或IP字符串
• 值为 *rate.Limiter，带过期机制（如用 time.AfterFunc 清理闲置项）
• 注意并发安全：sync.Map 的 LoadOrStore 可原子完成“查+建”逻辑

简单示意：

var limiters sync.Map
func getLimiter(key string) *rate.Limiter {
    if lim, ok := limiters.Load(key); ok {
        return lim.(*rate.Limiter)
    }
    lim := rate.NewLimiter(5, 2) // 每用户每秒5次，突发2次
    limiters.Store(key, lim)
    return lim
}

结合Redis实现分布式限流

单机限流在多实例部署下失效，需共享状态。Redis 的 INCR + EXPIRE 原子组合是常用方案，或用 Redis Lua 脚本保证操作完整性。

推荐使用 github.com/redis/go-redis/v9，配合 Lua 脚本一次完成计数、设置过期、判断阈值：

• 脚本接收 key、窗口时间（秒）、最大请求数作为参数
• 返回 1 表示放行，0 表示拒绝
• Golang 中用 rdb.Eval(ctx, script, []string{key}, windowSec, maxReq) 调用

优势是状态集中、各节点行为一致，且支持按用户/IP/接口路径等任意维度组合限流键。

限流结果的可观测与降级响应

限流不是终点，而是服务治理一环。建议在拦截时记录日志或上报指标（如 Prometheus Counter），便于分析攻击特征或容量瓶颈。

• HTTP 响应头中添加 X-RateLimit-Limit、X-RateLimit-Remaining、X-RateLimit-Reset，提升客户端友好度
• 对关键接口，可配置“熔断+限流”双策略：当错误率持续超标时，自动降级为更宽松限流或返回兜底数据
• 避免限流器本身成为性能瓶颈——缓存限流器、复用 Redis 连接、限制 Lua 脚本复杂度

不复杂但容易忽略。