Go实现Redis分布式限流方案

本文深入剖析了在 Go 语言中基于 Redis 实现高可靠分布式限流的关键陷阱与最佳实践，直击直接使用 `INCR` + `EXPIRE` 两步操作引发的竞态条件、计数失效和重复设过期等致命问题，明确指出唯一健壮方案是通过 Lua 脚本原子封装递增与过期逻辑；不仅给出了固定窗口限流的最小可行代码，还详解了支持平滑流量控制的滑动窗口 ZSET 实现，并强调了生产环境必须严查的三大配置雷区——连接池容量、Lua 脚本复用及内存淘汰策略，助你避开上线即崩的限流“深坑”。

为什么直接用 redis.Incr 做限流会出错

因为 INCR 本身不带过期逻辑，如果只调用 redis.Incr 再手动 Expire，在高并发下极易出现「计数器已增但过期没设上」的情况，导致限流失效。更糟的是，多个客户端可能同时读到旧值、各自 +1、再写回，造成漏判。

正确做法是把「原子递增 + 设置过期」合并成一条命令。Redis 6.2+ 支持 INCR 的 EX 选项，但 Go 客户端（如 github.com/redis/go-redis）尚未原生封装该语法，得手写 Eval 脚本。

• 用 INCR + EXPIRE 两步走 → 不安全，竞态明显
• 用 SET key 1 EX 60 NX 判断是否新建 → 只能用于首次请求，无法累计计数
• 用 Lua 脚本封装 INCR 和 EXPIRE 原子操作 → 唯一可靠方案

用 Lua 脚本实现原子限流的最小可行代码

核心逻辑：先 INCR，若返回值为 1（即刚创建），立刻 EXPIRE；否则不管。这样既避免重复设过期，又保证所有 key 都有 TTL。

const luaScript = `
if redis.call("INCR", KEYS[1]) == 1 then
  redis.call("EXPIRE", KEYS[1], ARGV[1])
end
return tonumber(redis.call("GET", KEYS[1]))
`

Go 中调用：

script := redis.NewScript(luaScript)
count, err := script.Run(ctx, rdb, []string{"rate:login:192.168.1.100"}, "60").Int64()
if err != nil {
    // 处理连接或脚本错误
}
if count > 10 {
    return errors.New("too many requests")
}

• KEYS[1] 是限流 key，建议包含业务维度（如用户 ID、IP、接口路径）
• ARGV[1] 是 TTL 秒数，必须传字符串，Lua 中用 tonumber() 转换
• 脚本返回当前计数值，方便上层判断是否超限
• 注意 Run 返回的是 Cmd，需用 .Int64() 提取结果，否则 panic

如何支持滑动窗口（比如每分钟最多 100 次，不是整点重置）

固定窗口（上面的方案）简单但有临界问题：用户在窗口末尾发 100 次，下一秒又发 100 次，实际 2 秒内就 200 次。滑动窗口需要记录每次请求时间戳，通常用 Redis 的 ZSET 实现。

思路：以请求时间为 score 存入 ZSET，每次先 ZREMRANGEBYSCORE 清理过期项，再 ZCARD 查数量，最后 ZADD 新条目。这三步也必须原子化，同样靠 Lua：

const slidingWindowScript = `
local key = KEYS[1]
local window = tonumber(ARGV[1])
local now = tonumber(ARGV[2])
redis.call("ZREMRANGEBYSCORE", key, 0, now - window)
local count = redis.call("ZCARD", key)
if count 

• ARGV[2] 必须由 Go 层传入 time.Now().Unix()，不能在 Lua 里用 redis.call("TIME")（精度低且集群模式不可靠）
• ARGV[4] 是唯一标识（如请求 ID 或毫秒级时间戳），防止同一秒内多次请求被 ZSET 去重
• EXPIRE 设为 window + 1 秒，确保 key 在窗口结束后至少存活 1 秒，避免提前消失
• 性能比计数器差，QPS 过万时需压测评估延迟

生产环境必须检查的三个配置点

限流一旦上线就直接影响用户体验，以下三点不验证清楚，上线等于埋雷：

• Redis 连接池大小：默认 MaxIdleConns=10，高并发下会阻塞，建议设为 QPS 的 2–3 倍（如 500 QPS 至少配 1000）
• 脚本缓存：redis.NewScript 每次都注册新 SHA1，高频调用会挤占 Redis script cache，应全局复用一个 *redis.Script 实例
• key 过期策略：确认 Redis 配置了 maxmemory-policy=volatile-lru 或类似策略，否则内存满时可能误删限流 key

滑动窗口的 ZSET key 如果不加 EXPIRE，长期积累会撑爆内存；而固定窗口的 string key 即使没设过期，只要用的是 Lua 原子脚本，也能保证 TTL 正确 —— 这个细节很容易被忽略。

今天关于《Go实现Redis分布式限流方案》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！