redis incr配合expire实现限流需用lua脚本保证原子性，避免竞态；推荐每60秒最多100次的lua方案，go中通过redis.newscript调用；令牌桶更优但需redis+lua实现，注意超时、连接池与健康检查。
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免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
