如何在Golang中实现接口限流_Web限流策略实现方法_技术教程

Go限流不能只靠time.Sleep，因其会阻塞goroutine、无法应对突发流量、不支持并发统计且难解耦；应使用rate.Limiter令牌桶或Redis+Lua滑动窗口实现分布式限流。

Go 限流为什么不能只靠 time.Sleep

直接用 time.Sleep 模拟“匀速放行”看似简单，但实际会阻塞 goroutine、无法应对突发流量、不支持并发统计，且无法与 HTTP 中间件解耦。真正可用的限流必须基于原子计数、滑动窗口或令牌桶，并能被多个请求共享状态。

使用 golang.org/x/time/rate 实现令牌桶限流

rate.Limiter 是 Go 官方推荐的轻量级限流器，底层是令牌桶算法，线程安全，适合 HTTP 中间件场景。

初始化时指定每秒填充速率（rate.Every(time.Second / 10) 表示 10 QPS）和最大突发量（burst）
每次请求调用 limiter.Wait(ctx)，阻塞直到拿到令牌；也可用 limiter.Allow() 做非阻塞判断
注意：burst 值过小会导致突发请求直接被拒，过大则削弱限流效果；建议设为 QPS 的 2–3 倍

func rateLimitMiddleware(next http.Handler) http.Handler {
    limiter := rate.NewLimiter(rate.Every(time.Second/5), 10) // 5 QPS，允许最多 10 个突发
    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)
    })
}

用 Redis + Lua 实现分布式滑动窗口限流

单机 rate.Limiter 无法跨实例共享状态。生产环境需分布式限流，滑动窗口比固定窗口更平滑，推荐用 Redis 的 ZSET + Lua 脚本保证原子性。

以用户 IP 或 token 为 key，将请求时间戳作为 score 存入 ZSET
Lua 脚本负责：清理过期时间戳（score window）、计算当前窗口请求数、插入新时间戳
避免在 Go 层做多次 Redis 往返，所有逻辑收束到一个 EVAL 调用中
注意：Redis 时间必须与应用服务器时间同步，否则窗口计算偏移

-- lua script: sliding_window.lua
local key = KEYS[1]
local now = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
local max_req = tonumber(ARGV[3])
redis.call('ZREMRANGEBYSCORE', key, 0, now - window)
local count = redis.call('ZCARD', key)
if count >= max_req then
return 0
end
redis.call('ZADD', key, now, now .. ':' .. math.random(1000, 9999))
redis.call('EXPIRE', key, window + 1)
return 1