当前位置：首页 > 文章列表 > Golang > Go教程 > Go实现Redis分布式限流方案

Go实现Redis分布式限流方案

2026-05-06 10:26:30 0浏览收藏

在 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])
<p>-- 清理过期窗口（只删比 now_ms - window_ms 更老的）
local old_ts = now_ms - window<em>ms
for </em>, 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</p><p>-- 当前窗口计数 +1
local current_count = redis.call('HINCRBY', key, now_ms, 1)
redis.call('EXPIRE', key, math.ceil(window_ms / 1000) + 1)</p><p>if current_count > max_count then
return 0
end
return 1</p>

调用时传入：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 连接阻塞