Golang实现Redis限流计数器教程

本文深入探讨了在Golang中基于Redis实现高可靠限流计数器的实战方案，直击INCR+EXPIRE组合易引发的竞态与失效风险，强调必须通过Lua脚本将“自增、设过期、超限判断”三步操作原子化执行；不仅给出了每60秒最多100次的精简可落地Lua示例及go-redis/v9调用范式，还对比分析了窗口计数器与令牌桶的适用边界，指出跨服务共享令牌桶仍需Redis+Lua配合ZSET等结构实现，并系统提醒连接池配置、上下文超时策略、健康检查及压测中的RT敏感性等易被忽视却决定稳定性的关键细节——帮你避开线上限流失效的深坑。

Redis INCR 命令配合 EXPIRE 是最简限流计数器核心

Go 里用 redis.Client.Incr() + redis.Client.Expire() 组合，就能实现带过期时间的原子计数器。关键不是“能不能做”，而是“怎么避免竞态和误失效”。

常见错误是先 Incr() 再判断返回值，然后才调用 Expire() —— 如果服务在两次调用之间崩溃，计数器就永久存在了。

• 必须用 redis.Client.Incr() 获取当前值后，立刻用 redis.Client.SetNX("key:expire", "1", time.Second*60) 或更稳妥的 Lua 脚本保证原子性
• 推荐直接用 Lua：一次请求完成“加一、设过期、判断是否超限”，避免客户端与 Redis 多次往返
• 注意 INCR 对不存在的 key 会自动初始化为 1，无需预设

用 Lua 脚本封装限流逻辑，规避多命令竞态

Go 标准 redis 客户端（如 github.com/go-redis/redis/v9）支持 Eval() 执行 Lua。下面这段脚本实现“每 60 秒最多 100 次”的计数器：

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

对应 Go 调用：

script := redis.NewScript(luaScript)
result, err := script.Run(ctx, rdb, []string{"rate:ip:192.168.1.100"}, "60", "100").Int64()
// result == 0 表示被限流，>0 是当前计数值

• KEYS 和 ARGV 必须显式传入，不能拼接字符串，防止注入
• 脚本里用 redis.call("EXPIRE", ...) 而非 PEXPIRE，兼容 Redis 2.6+
• 不要在 Lua 里做复杂计算或循环，它会阻塞 Redis 单线程

用 redis.Cell（令牌桶）替代简单计数器更贴近真实场景

纯 INCR 计数器只能做“窗口限流”（比如 60 秒内最多 N 次），但无法平滑放行请求。要支持“每秒 10 个，允许突发 30 个”，得用令牌桶。

github.com/bsm/redislock 不适合；推荐直接用 github.com/go-redis/redis/v9 配合 github.com/oleiade/redislock 或更轻量的 github.com/uber-go/ratelimit（内存版）——但注意后者不跨实例。

• 真正跨服务共享的令牌桶，仍需 Redis + Lua 实现，例如用 ZSET 存储令牌发放时间戳
• 简单起见，多数业务用“滑动窗口”近似令牌桶：用 GETRANGE + SETRANGE 操作 bitmap，或用多个 key 分片（如按秒哈希）
• 别低估序列化开销：用 json.Marshal 存结构体到 Redis，比存纯数字慢 3–5 倍

注意 go-redis v9 的 context 超时和连接池配置

限流是高频操作，ctx 超时设太短会导致误判（比如 Redis 延迟突增时把正常请求干掉），设太长又拖垮整个请求链路。

• 建议限流操作单独配 context.WithTimeout(ctx, 50 * time.Millisecond)，比主请求 timeout 短得多
• redis.Options.PoolSize 默认 10，高并发下容易打满，可设为 CPU 核数 × 4（如 16），但别超过 Redis maxclients
• 务必启用 redis.Options.MinIdleConns（如 5），避免每次限流都建新连接
• 别忽略 redis.Client.Ping() 健康检查 —— 限流失败时，优先查 Redis 是否假死

真正的难点不在写几行 Lua，而在于压测时发现：当 Redis RT 从 0.3ms 涨到 8ms，限流误判率从 0.01% 跳到 12%。这时候要么调小超时、要么加本地缓存兜底，而不是改算法。

以上就是《Golang实现Redis限流计数器教程》的详细内容，更多关于的资料请关注golang学习网公众号！