Go 实现 Redis 分布式限流方法

本文深入剖析了在 Go 语言中基于 Redis 实现高可靠分布式限流的关键陷阱与最佳实践：直击 `INCR + EXPIRE` 非原子操作导致的 key 永久残留、计数错乱等线上高频问题，提出以 Lua 脚本封装“判断-自增-续期”三步原子逻辑的解决方案，并给出适配固定窗口与滑动窗口（ZSET 实现）的生产级代码范式；同时强调连接池调优、超时控制（≤50ms）、key 分片防热点、错误快速熔断等易被忽视却决定系统稳定性的工程细节——真正考验架构功力的，从来不是算法多精巧，而是每一个竞态路径是否被严丝合缝地覆盖，每一次限流失败能否不拖垮业务主链路。

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

因为 INCR 本身不带过期逻辑，如果只调用 redis.Incr 然后手动 Expire，在并发高时可能 INCR 成功但 EXPIRE 失败，导致 key 永久存在，后续所有请求都被误拒。更糟的是，INCR 和 EXPIRE 不是原子操作，中间可能被其他客户端干扰。

正确做法是：用 SET key value EX seconds NX 初始化窗口，再配合 Lua 脚本完成「判断 + 自增 + 过期续命」三步原子操作。Go 客户端（如 github.com/go-redis/redis/v9）必须用 Eval 或 EvalSha 执行脚本，不能拆成多条命令。

用 Lua 脚本实现原子限流的核心逻辑

以下脚本适用于「固定窗口」模型（例如每分钟最多 100 次），key 格式为 rate:uid:202405:12（按用户+年月+小时分片），避免单 key 热点：

local current = redis.call("INCR", KEYS[1])
if current == 1 then
    redis.call("EXPIRE", KEYS[1], tonumber(ARGV[1]))
end
if current > tonumber(ARGV[2]) then
    return 0
end
return current

说明：
– KEYS[1] 是限流 key（需由 Go 代码拼好）
– ARGV[1] 是窗口秒数（如 60）
– ARGV[2] 是最大请求数（如 100）
– 返回值：0 表示被限流，>0 表示当前计数

Go 中调用示例：

script := redis.NewScript(luaScript)
result, err := script.Run(ctx, rdb, []string{key}, windowSec, maxReq).Int64()
if err != nil {
    // 注意：redis.Nil 表示 key 不存在且未执行 INCR，不是错误
    if !errors.Is(err, redis.Nil) { ... }
}
if result == 0 {
    return errors.New("rate limited")
}

go-redis/v9 的连接池与超时配置要点

分布式限流是高频低延迟场景，连接池和超时设置不当会导致阻塞或误判：

• PoolSize 建议设为 CPU 核心数 × 4～8（非默认 10），避免大量 goroutine 等待连接
• MinIdleConns 至少设为 5，防止突发流量时频繁建连
• Timeout 和 ReadTimeout 必须 ≤ 50ms，否则限流本身成为瓶颈
• 禁用 MaxRetries（即设为 0）：限流失败应立即返回，重试只会放大雪崩风险

错误示范：ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) —— 这个 5 秒会卡住整个请求链路，应改为 100 * time.Millisecond 并快速 fallback。

滑动窗口限流的现实取舍

严格意义上的滑动窗口（如“过去 60 秒内最多 100 次”）需要维护时间序列，纯 Redis 实现成本高。生产中更推荐：

• 用「时间分片 + 滑动求和」近似：例如按秒存 60 个 key（rate:uid:1715000000 到 rate:uid:1715000059），每次请求对当前秒 key INCR 并 EXPIRE 60，再用 GET 批量读最近 60 个 key 求和 —— 但要注意 MGET 可能跨 slot，集群模式下会报 CROSSSLOT
• 更稳的做法：退回到精度稍低的「滑动日志」—— 用 ZSET 存时间戳，ZREMRANGEBYSCORE 清理旧记录，ZCARD 计数。虽然内存略高，但原子性好、集群兼容。

真正难的不是写脚本，而是 key 设计是否抗倾斜、Lua 是否覆盖所有竞态路径、以及限流失败时业务层能否优雅降级 —— 这些细节往往比算法本身更容易引发线上事故。

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