单机rate.limiter在分布式环境下失效，因其纯内存实现导致各pod独立维护令牌桶，10个pod各限100qps则总流量达1000qps；它不共享状态，无法满足api网关等需全局一致性的场景。
单机 rate.Limiter 在分布式环境下完全失效，必须按调用层级拆分限流策略——不是“能不能做”，而是“在哪一层做、用什么存、怎么避免临界崩塌”。
为什么不能直接复用单机 rate.Limiter 做分布式限流
rate.Limiter 是纯内存结构，每个进程独立维护令牌桶。K8s 部署 10 个 Pod，每 Pod 允许每秒 100 请求，实际总流量就是 1000 QPS，远超预期阈值。它不感知其他节点状态，也无法共享计数器或令牌。
- 它适合单实例后台任务（如定时同步、内部批处理）
- 不适合 API 网关、微服务入口、用户行为风控等需全局一致性的场景
- 即使加
sync.Map按 IP 缓存多个rate.Limiter实例，也只是“伪分布式”——不同 Pod 对同一 IP 的限流状态仍不一致
按调用层级选择限流实现方式
不同模块调用深度对应不同限流粒度和存储要求，选错方案会导致性能瓶颈或逻辑错误：
-
HTTP 入口层（如 Gin 中间件）：用 Redis + Lua 脚本实现固定窗口或滑动窗口计数，key 设计为
"ip:192.168.1.100:api:/user/profile"，支持毫秒级精度与原子性 -
服务间 RPC 调用（如 gRPC client）：在 client stub 封装限流逻辑，对下游服务名 + 方法名组合限流，使用 Redis Hash 存储多维度计数（避免 key 泛滥），例如
HINCRBY ratelimit:svc:user-svc:method:GetUser 1 -
数据库/缓存访问层：不依赖外部存储，改用连接池 + channel 控制并发数，例如
sem := make(chan struct{}, 5)控制最大同时执行的 SQL 查询数，防止 DB 连接耗尽 - 异步任务触发（如发短信、写日志）：用带缓冲 channel + ticker 模拟令牌桶，但 burst 必须设为 1，否则多个 goroutine 同时抢到令牌会突破速率上限
Redis 计数器容易踩的三个坑
用 Redis 实现分布式计数看似简单，但生产环境常因细节翻车：
-
INCR+EXPIRE分两步执行？不行——必须用 Lua 脚本保证原子性，否则高并发下可能 key 过期后又被INCR创建，导致计数丢失 - 滑动窗口用 ZSET 实现时，
ZREMRANGEBYSCORE和ZCARD要套在同一段 Lua 里，否则中间插入新请求会漏统计 - 固定窗口时间戳对齐错误：不能用
time.Now().Unix() / 60直接算分钟窗口，而要用now.Truncate(1 * time.Minute).Unix()，否则跨分钟边界请求可能被重复计数或漏计
细粒度限流的 key 设计原则
限流效果取决于 key 是否真正反映“被限对象”的业务边界：
- 按用户限流？key 用
"uid:12345:action:pay"，别只用"uid:12345"——否则用户查订单、改地址、付款全被锁死 - 按租户限流？key 加上
tenant_id，且必须从请求上下文（如 JWT payload 或 header）中提取，不能硬编码或 fallback 到 default - 按接口路径限流？path 必须标准化：去掉 query 参数、统一 trailing slash、小写 host，否则
/api/v1/users和/api/v1/users?会被当成两个 key - 避免 key 过长或含敏感信息：不要把完整 JWT 或手机号明文拼进 key，应先哈希或截取前 8 位
最麻烦的不是写限流逻辑，而是验证它真正在起作用——压测时得同时监控 Redis 的 incr 调用量、各 Pod 的本地 rate.Limiter 命中率、以及下游服务的实际 QPS 曲线。三者不一致，说明某层限流被绕过了，或者 key 设计没覆盖真实调用路径。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
