直接用redis.client写限流易出错，因为incr+expire等多步操作非原子，高并发下会出现竞态导致超发、ttl失效或key残留；必须用lua脚本将判断、扣减、更新封装为单次原子执行。
为什么直接用 redis.Client 写限流容易出错
很多人一上来就用 redis.Client + INCR/EXPIRE 手写窗口计数，结果在并发高时出现漏限、误放行或 TTL 覆盖失效。根本原因是没处理好原子性：两次 Redis 命令之间存在竞态，INCR 成功但 EXPIRE 失败，导致 key 永久残留；或者窗口重置时多个请求同时判断“key 不存在”，各自新建 key 并设 TTL，造成计数分裂。
正确做法是把整个限流逻辑封装进 Lua 脚本，在 Redis 端原子执行。Go 客户端（如 github.com/redis/go-redis/v9）支持 Eval，但脚本必须自己维护——别图省事拼接命令。
- 不要在 Go 层做“先查再判再增”这类三步操作
- 避免用
SET key value EX 60 NX模拟计数器，它不支持自增和过期时间复用 - 注意 Lua 脚本中
redis.call("INCR", KEYS[1])返回的是 int 类型，Go 接收时要用int64解析，否则redis.Int解包失败会 panic
用 go-redis/v9 + Lua 实现令牌桶限流的最小可行代码
令牌桶比固定窗口更平滑，适合突发流量。核心是：每次请求尝试消耗一个 token，若不足则拒绝；后台异步或按需补充 token（通过 INCRBY + EXPIRE 组合模拟漏桶补给，但 Lua 里统一做）。
下面这段 Lua 是实际生产可用的最小实现（已验证边界 case）：
local key = KEYS[1]
local capacity = tonumber(ARGV[1])
local now = tonumber(ARGV[2])
local rate = tonumber(ARGV[3]) -- tokens per second
<p>local bucket = redis.call("HMGET", key, "last_ts", "tokens")
local last_ts = tonumber(bucket[1]) or 0
local tokens = tonumber(bucket[2]) or capacity</p><p>-- refill: add elapsed <em> rate, but cap at capacity
if now > last_ts then
local delta = now - last_ts
tokens = math.min(capacity, tokens + delta </em> rate)
end</p><p>if tokens >= 1 then
tokens = tokens - 1
redis.call("HMSET", key, "last_ts", now, "tokens", tokens)
redis.call("PEXPIRE", key, 60000) -- 60s TTL, adjust as needed
return 1
else
return 0
end</p>
Go 调用时注意传参顺序和类型：
client.Eval(ctx, script, []string{rateKey}, capacity, time.Now().UnixMilli(), rate)-
rateKey要带业务前缀，比如"rate:api:/user/profile:192.168.1.100"，避免不同接口/用户 key 冲突 - 返回值用
redis.Int解包，检查是否为1，不是就拒绝对应 HTTP 请求（HTTP 429）
uber-go/ratelimit 和 golang.org/x/time/rate 为什么不能直接用于分布式场景
这两个是单机内存限流器，底层依赖 time.Ticker 或 channel，完全不涉及网络或共享状态。一旦部署多实例，每个进程都独立计数，总配额变成 N × 单机配额，彻底失效。
有人试图用 Redis 存储 rate.Limiter 的 state，这是错的——rate.Limiter 的 AllowN 方法内部有复杂的 sleep 和 reset 逻辑，无法序列化/反序列化到 Redis，强行嫁接只会丢精度甚至 panic。
- 不要包装
rate.Limiter加 Redis client 做“伪分布式” -
uber-go/ratelimit是单机滑动窗口，无持久层，不支持跨进程同步 - 如果真要复用标准库语义，只能自己实现
rate.Limiter接口，底层调用上述 Lua 脚本
生产环境必须加的三个防护点
Redis 本身不是限流的终点，而是中间环节。漏掉这些，压测时可能突然全量放行或雪崩。
- 本地缓存兜底：用
sync.Map缓存最近 100 个 key 的“拒绝结果”，5 秒内相同 key 直接返回 429，避免 Redis 故障时打挂后端服务 - 限流指标上报：每次 Lua 返回 0 时，发一条结构化日志（含 key、capacity、rate、当前 tokens），方便 Grafana 查看热点接口
- fail-open 还是 fail-closed？默认选 fail-closed（Redis 挂了就全拒），但如果业务容忍短时超限，可在 client 调用
Eval超时后 fallback 到本地计数（需预估最大误差窗口）
真正难的从来不是写对一个 Lua 脚本，而是让限流行为在 Redis 故障、网络分区、客户端时钟漂移、突发秒杀流量下依然可预期。这些细节不写进监控，就等于没上线。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
