rate.Limiter在多实例下失效，因其仅在本地内存维护令牌桶状态，5个Pod各持10QPS限流即导致实际总流量达50QPS；它无法跨进程同步时间、令牌或计数，任何本地缓存+Redis定时同步方案均会因时钟漂移、网络延迟和并发竞争引发配额错乱或超发。
为什么 rate.Limiter 在多实例下完全失效
它只在当前进程内存中维护令牌桶状态，5 个 pod 各自运行 rate.newlimiter(10, 20)，实际总入口流量就是 50 qps —— 这不是 bug，是设计使然。单机限流器无法跨进程同步时间、令牌或计数，任何试图“本地缓存 + 定时同步 redis”的方案都会因时钟漂移、网络延迟和并发竞争导致配额错乱甚至超发。
Redis + Lua 滑动窗口必须原子执行
用 INCR + EXPIRE 两步走是典型错误：高并发下可能 INCR 成功但 EXPIRE 失败，key 永久存在；或多个客户端同时发现 key 不存在（TTL = -2），各自从 0 开始计数，瞬间冲垮阈值。现象是限流失效、QPS 突然翻倍、ERR no such key 频发。
正确做法是把「读窗口计数 + 写新请求 + 清理过期项 + 设过期」全部压进一个 Lua 脚本，由 Redis 单线程原子执行。脚本里禁用 TIME 命令（主从时钟不一致），客户端必须传入毫秒级时间戳（如 time.Now().UnixMilli()）作为 ARGV[3]。
- key 命名要带维度，例如
"rate:api:/user/profile:192.168.1.1"，避免笼统的"user-get" -
EXPIRE时间设为window_ms / 1000 + 1，防止 key 过早消失 - 清理逻辑必须基于绝对时间比较，不能只靠索引差
redis-cell 是最省心的分布式令牌桶方案
如果你需要支持突发流量平滑放行（比如允许短时 3 倍峰值），又不想手写 Lua 脚本、不操心窗口计算和并发竞争，redis-cell 是目前 Go 生态中最稳的选择。它的 CL.THROTTLE 命令把完整令牌桶逻辑封装在 Redis C 层，Go 客户端只需发一条命令、解析五元组响应。
注意点：
- Redis 实例必须提前加载模块：
redis-server --loadmodule /path/to/redis-cell.so，否则调用报ERR unknown command - 不要用
Eval模拟等效逻辑——C 实现有原子性与性能优化，Lua 版本无法复现 - 响应是长度为 5 的整数切片：
[allowed_tokens, total_allowed, remaining_tokens, reset_time_in_seconds, retry_after]，其中allowed_tokens == 0表示被拒绝 - Go 客户端推荐用
github.com/go-redis/redis/v9，它原生支持Do()调用自定义命令
最容易被忽略的三个降级点
真正难的不是写通限流逻辑，而是让系统在边界条件下依然可控：
-
X-Real-IP或X-Forwarded-For提取失败：没配TrustedProxies，中间件拿到的是内网 IP，导致所有请求挤在一个桶里；或者正则提取不严谨，把代理头拼错成"1.2.3.4, 5.6.7.8"当作 key - 配置热更新 panic：reload 时
sync.Map正在被大量 goroutine 读，又同时被写，引发竞态；应改用读写锁保护 map + 双 buffer 交换 - Redis 故障时无降级：限流中间件直接返回 503，而不是 fallback 到宽松的本地
rate.Limiter（比如每秒 1000 QPS）或直接放行，否则依赖限流的服务会集体雪崩
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
