rate.limiter在微服务中失效，因其仅为单机内存态实现，各实例独立维护令牌桶，无法感知全局流量；部署4个实例且每例限100 qps时，总入口流量可达400 qps，远超下游承载能力；并发、网络延迟导致allow()判断失准；且缺乏调用方或接口粒度控制；真正可用的分布式限流需依赖redis+lua原子操作实现跨实例状态共享。
单机 rate.Limiter 在微服务中基本限不住真实流量，它只管本实例的请求时间戳，完全不知道其他实例正在放行多少请求。
为什么 rate.Limiter 在微服务里会失效
它本质是本地内存状态，每个服务实例都独立维护自己的令牌桶。比如你配置了每秒 100 QPS，部署了 4 个实例，理论上入口总流量可能飙到 400 QPS —— 后端数据库或下游服务根本没准备承受这个量。
- 并发请求 + 网络延迟会导致
Allow()判断失准：同一毫秒内多个 goroutine 可能同时拿到 true -
rate.Every(100 * time.Millisecond)表示“每 100ms 放 1 个 token”，但实际吞吐取决于 handler 处理耗时，不是硬性 QPS 封顶 - 没做调用方/接口粒度区分：所有请求共用一个桶，无法对 /pay 接口限得严、对 /health 限得松
真正可用的分布式限流必须用 Redis + Lua
核心是把「计数 + 过期设置」压进一个原子操作，避免 INCR 和 EXPIRE 分开调用产生的竞态。Go 侧只需传参调用，不操心锁和重试。
- 限流 key 建议包含三要素：
"limit:svc:user-service:/user/profile:192.168.1.100"（服务名+路径+客户端 IP） - Lua 脚本里用
redis.call("INCR", KEYS[1])计数，首次命中才redis.call("EXPIRE", KEYS[1], ARGV[1]) - Go 调用用
redisClient.Eval(ctx, script, []string{key}, windowSec, maxReq).Int()，返回 1 表示放行，0 表示拒绝 - Redis 连接池大小要够：限流逻辑本身不能成瓶颈，建议 minIdle ≥ 20，maxTotal ≥ 100
别在 handler 最外层裸调 Allow()
它不阻塞也不等待，只是立刻返回 bool。如果写成 if !limiter.Allow() { log.Warn("rejected") } 而不 return，后续逻辑照常执行，等于限了个寂寞。
- 正确写法是：
if !limiter.Allow() { http.Error(w, "too many requests", http.StatusTooManyRequests); return } - 更稳妥的做法是封装成中间件，在
http.Handler的 ServeHTTP 开头就判断并提前终止 - 注意 context 透传：限流判断应基于原始请求到达时间，别被内部重试或超时重置干扰
跨实例共享状态这件事，没有取巧办法——要么用 Redis 这类外部存储兜底，要么上服务网格（如 Istio 的 RateLimitService），自己实现分布式令牌桶成本远高于收益。最容易被忽略的是限流 key 的设计粒度：IP + 接口路径只是起点，真实场景往往还得叠加用户 ID 或 app key 才能防住定向攻击。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
