单机内存限流在 Kubernetes 多 Pod 场景下不可靠，因其将全局限流决策拆分为各 Pod 局部计数，导致 LB 随机分发请求时出现漏放或误拒；HPA 扩容后阈值需手动重算，运维成本高；真正可靠的方案必须依赖 Redis 等共享状态源，依靠其原子命令（如 INCR、ZADD）和 Lua 脚本规避竞态，结合 ZSet 实现滑动窗口精确限流，并显式设置 TTL 防内存泄漏。
为什么单机内存限流在 Kubernetes 里根本不可靠
多 Pod 场景下，每个实例用 map[string]int 计数，本质上是把“全局决策”拆成了 N 个局部判断。用户请求被 LB 随机分发，某 Pod 累计到阈值就拒绝，但其他 Pod 根本不知道——这不是限流，是随机拦截。更麻烦的是，HPA 扩容后阈值得手动重算，运维成本指数级上升。
真正能落地的方案，必须依赖一个所有实例都信任的共享状态源。Redis 就是那个角色，不是因为它快，而是因为它的原子性 + 单线程执行模型天然规避了竞态。
-
INCR、ZADD、EXPIRE这些命令本身是原子的，不需要客户端加锁 - 哪怕 100 个 Goroutine 同时调用
INCR rate:192.168.1.1，结果也只可能是一个递增后的整数，不会丢请求 - 别用
GET + IF + SET组合——网络往返 + 条件竞争，必然出错；Lua 脚本才是安全边界
滑动窗口限流：用 ZSet 实现精确时间切片
固定窗口（比如每分钟清零）有严重边界效应：00:59 和 01:00 各来 1000 请求，瞬间就是 2000 QPS，直接打穿下游。滑动窗口靠 Redis ZSet 的 score 排序能力解决这个问题，以毫秒时间戳为 score，member 可设为请求 ID 或纳秒时间戳保证唯一。
关键逻辑不是“加进去再查总数”，而是“先清理过期项，再查当前窗口内数量，再决定是否写入”：
- 用
ZRemRangeByScore清除score 的旧记录（注意：score 是毫秒时间戳，字符串格式要一致） -
ZCard获取当前窗口内请求数，和限流阈值比对 - 允许时才
ZAdd新条目，并配Expire防止 key 永久堆积（ZSet 本身不自动过期） - 别漏掉
ctx超时控制——Redis 响应慢时，整个 HTTP 请求不能卡死
令牌桶 vs 滑动窗口：选型要看你的业务毛刺容忍度
令牌桶（如 golang.org/x/time/rate 或 go-rate）适合需要平滑放行的场景，比如 API 调用配额；但它是单机模型，分布式下需配合 Redis 存储桶状态，复杂度陡增。滑动窗口更贴近真实流量分布，尤其适合防刷、秒杀等对瞬时峰值敏感的业务。
- 令牌桶的
AllowN返回bool，不阻塞，适合“超了就拒”的硬策略 - 滑动窗口天然支持“最近 N 秒内最多 M 次”，语义更直观，调试时直接
ZRANGE key -inf +inf WITHSCORES就能看到原始数据 - 性能上，ZSet 的
ZRemRangeByScore在数据量大时会有 O(log N) 开销，但实际业务中窗口长度有限（如 60 秒），影响可控 - 如果用
INCR + EXPIRE简单计数，只能做固定窗口，且EXPIRE在INCR后执行存在竞态风险——必须用 Lua 封装成原子操作
别忽略熔断联动：限流只是第一道防线
限流器返回 false 不等于事情结束。下游服务响应变慢时，大量 Goroutine 堆积在 redis.Client.Do 上，内存会线性增长直至 OOM。真正的生产级限流必须和熔断器联动。
- 在
RateLimiter.IsAllowed返回false后，不要直接返回 429，先检查下游健康度（比如最近 30 秒错误率 > 50%） - 用
context.WithTimeout包裹 Redis 调用，超时即触发降级，避免协程泄漏 - Redis 连接池本身也要限流：
PoolSize设为 CPU 核心数 × 10，MaxActiveConns控制并发上限，否则 Redis 客户端反而成瓶颈 - 最易被忽略的一点：ZSet key 的 TTL 必须显式设置。否则窗口外数据虽被删，key 本身永存，内存缓慢泄漏
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
