Go实现Redis分布式限流方案

在 Go 中实现 Redis 分布式限流，最可靠的方式是采用「滑动窗口 + Lua 脚本」方案，彻底规避 INCR 与 EXPIRE 非原子操作引发的 key 永久残留、计数丢失或阈值击穿等高并发陷阱；通过客户端传入精确时间戳、在 Lua 中原子化完成窗口清理、计数递增与过期设置，并结合合理的时间粒度（如 ≥100ms）与 Key 设计策略，兼顾限流精度、系统稳定性与 Redis 内存可控性——这不仅是技术选型的最优解，更是生产环境扛住流量洪峰的关键防线。

Go 用 redis 做分布式限流，最稳妥的路子是「滑动窗口 + Lua 脚本」，不是靠客户端拼逻辑，更不是用 INCR + EXPIRE 两步走——那在并发下会漏统计、超阈值。

为什么不能只用 INCR 和 EXPIRE

因为这两条命令不是原子的。高并发时，可能先 INCR 成功，但 EXPIRE 失败（比如 key 刚被删或网络抖动），导致后续请求永远拿不到过期时间；或者多个客户端同时判断 TTL 为 -2（key 不存在），各自从 0 开始计数，瞬间冲垮阈值。

• 现象：ERR no such key 或限流失效，QPS 突然翻倍
• 根本原因：Redis 命令非原子，客户端无法靠 sleep/retry 补救
• 替代方案必须把「读+写+设过期」锁死在一次 Lua 调用里

用 Lua 脚本实现滑动窗口（固定时间粒度）

不推荐令牌桶（状态难同步）、也不用简单计数器（精度差）。滑动窗口折中了精度和性能，适合大多数 API 限流场景。核心思路：按秒/毫秒切分时间片，用 HSET 存每个窗口的计数，HEXISTS + HINCRBY + EXPIRE 全部塞进一个脚本。

示例脚本（保存为 sliding_window.lua）：

local key = KEYS[1]
local window_ms = tonumber(ARGV[1])
local max_count = tonumber(ARGV[2])
local now_ms = tonumber(ARGV[3])
-- 清理过期窗口（只删比 now_ms - window_ms 更老的）
local old_ts = now_ms - windowms
for , ts_str in ipairs(redis.call('HKEYS', key)) do
local ts = tonumber(ts_str)
if ts < old_ts then
redis.call('HDEL', key, ts_str)
end
end
-- 当前窗口计数 +1
local current_count = redis.call('HINCRBY', key, now_ms, 1)
redis.call('EXPIRE', key, math.ceil(window_ms / 1000) + 1)
if current_count > max_count then
return 0
end
return 1

• 调用时传入：KEYS[1]（如 "rate:login:192.168.1.1"），ARGV[1]（窗口毫秒数，如 60000），ARGV[2]（最大请求数），ARGV[3]（当前毫秒时间戳）
• 注意：脚本里没用 TIME 命令，避免主从时钟不一致；客户端必须传准确时间戳
• EXPIRE 时间要略大于窗口长度（+1 秒），防止 key 过早消失

Go 客户端调用要点（github.com/go-redis/redis/v9）

别手写 Eval 字符串拼接，用 script.Load 预加载，再 Run 执行。错误处理重点抓 redis.Nil（脚本返回 nil，通常因 key 不存在且未触发 HINCRBY）和 Lua 返回值类型。

• 加载脚本：script := redis.NewScript(luaContent)
• 执行时传参：result, err := script.Run(ctx, rdb, []string{key}, windowMs, maxCount, time.Now().UnixMilli()).Result()
• 判断结果：if result == int64(1) { /* 放行 */ } else { /* 拒绝 */ }
• 别忽略 ctx 超时——Lua 脚本卡住会导致整个 Redis 连接阻塞

Key 设计与内存膨胀风险

Key 必须带业务维度（如用户 ID、IP、API 路径），但不能无限制增长。滑动窗口的 HASH 会持续写新字段，如果窗口粒度太细（比如 10ms），或服务长期运行，HKEYS 扫描成本会上升。

• 建议窗口粒度 ≥ 100ms，上限控制在 1000 个字段以内
• 定期用 SCAN + HLEN 监控 key 大小，超过阈值（如 500）就告警
• 避免用时间戳字符串做 key 主体（如 "rate:20240501"），应把时间戳作为 HASH 的 field，主体用稳定标识

滑动窗口的精度和资源消耗是硬币两面，选 1 秒窗口还是 100 毫秒，得看你的错误预算和 Redis 内存水位——这点容易被压测时忽略。

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