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

直接用 time.Sleep 模拟“匀速放行”看似简单,但实际会阻塞 goroutine、无法应对突发流量、不支持并发统计,且无法与 HTTP 中间件解耦。真正可用的限流必须基于原子计数、滑动窗口或令牌桶,并能被多个请求共享状态。
rate.Limiter 是 Go 官方推荐的轻量级限流器,底层是令牌桶算法,线程安全,适合 HTTP 中间件场景。
rate.Every(time.Second / 10) 表示 10 QPS)和最大突发量(burst)limiter.Wait(ctx),阻塞直到拿到令牌;也可用 limiter.Allow() 做非阻塞判断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)
})
}单机 rate.Limiter 无法跨实例共享状态。生产环境需分布式限流,滑动窗口比固定窗口更平滑,推荐用 Redis 的 ZSET + Lua 脚本保证原子性。
ZSET
EVAL 调用中-- 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
限流策略常需区分接口粒度(如 /api/pay 限 100 QPS,/api/status 限 1000 QPS),不能全局共用一个 rate.Limiter。
sync.Map 缓存已初始化的 *rate.Limiter
真正难的不是写对一段限流代码,而是决定 burst 值是否该随负载自动调整、Redis 故障时要不要降级为本地漏桶、以及哪些接口该限流哪些不该 —— 这些都得靠线上指标反馈,而不是文档里抄个数字就完事。
来电咨询