Golang微服务如何实现限流_Golang限流方案对比_网络技术

用 rate.Limiter 做单
机限流最稳妥，它基于令牌桶算法、线程安全、可扛突发；需复用实例、用 Wait(ctx) 避免阻塞；按用户/IP/路径限流时须用 sync.Map 缓存并定期清理过期 key；集群场景必须用 Redis+Lua 原子实现。

用 `rate.Limiter` 做单机限流最稳妥，别手写计数器

生产环境首选 golang.org/x/time/rate，它基于令牌桶算法，线程安全、无依赖、能扛突发流量。自己实现计数器（比如用 sync.Map + 时间戳）看似简单，但容易掉进“窗口切换突刺”陷阱——例如固定窗口在 00:59.9s 和 01:00.1s 各来 100 请求，实际一秒内就打了 200 次。

关键点：

rate.NewLimiter(rate.Every(100*time.Millisecond), 5) 表示每 100ms 放 1 个令牌，桶容量为 5 —— 即允许最多 5 次瞬时请求，平均 QPS 是 10
必须复用同一个 *rate.Limiter 实例，不能在 handler 函数里每次 new；否则 goroutine 竞争下限流失效
别用 Allow() 判断后才塞 context 超时；应提前带超时的 ctx 传给 Wait(ctx)，否则可能永久阻塞

按用户/IP/路径做差异化限流，`sync.Map` 缓存要配过期清理

全局一个限流器不够用，真实场景需按 X-Real-IP、X-User-ID 或路由 path 分别限流。这时得用 sync.Map 缓存每个 key 对应的 *rate.Limiter，但要注意：不清理就会内存泄漏。

常见错误：

只写 m.LoadOrStore(key, newLimiter())，没配定时清理逻辑 → key 越积越多，OOM 风险
用 time.AfterFunc 给每个限流器设过期，但 key 失活后无法主动触发清理 → 还是涨内存

推荐做法：后台起 goroutine，定期扫描 sync.Map，对超过 5 分钟未访问的 key 调用 Delete；或者直接用带 TTL 的 LRU 库（如 github.com/hashicorp/golang-lru/v2）。

多实例部署必须上 Redis + Lua，别信两步 INCR+EXPIRE

单机 rate.Limiter 在微服务集群里完全失效。跨节点共享状态只能靠 Redis，但直接用 INCR + EXPIRE 两步走有竞态风险：INCR 成功了，EXPIRE 却失败，key 就永远卡在 Redis 里。

正确姿势是 Lua 脚本原子执行：

-- KEYS[1] 是限流 key（如 "ip:192.168.1.1"）
-- ARGV[1] 是窗口秒数，ARGV[2] 是最大请求数
local current = redis.call("INCR", KEYS[1])
if current == 1 then
  redis.call("EXPIRE", KEYS[1], ARGV[1])
end
return current <= tonumber(ARGV[2])

注意：

Go 调用时用 redis.NewScript(lua)，避免每次 EVAL 计算 SHA；预加载脚本 SHA 更稳，防止 Redis 版本差异导致 EVALSHA 失败回退到慢路径
滑动窗口精度更高，但需用 ZSET + ZCOUNT，比固定窗口多一次网络往返；若 P99 延迟已超 50ms，优先选固定窗口保响应速度

限流不是加个中间件就完事，漏掉监控等于没做

上线后没人看指标，等于裸奔。必须暴露 Prometheus counter，比如 http_requests_limited_total{route="/api/user", reason="per_ip"}，再配 PromQL 告警：rate(http_requests_limited_total[5m]) > 10。

还有几个硬伤常被忽略：

健康检查端点（如 /health）被误限 —— 中间件里要显式放行，别让它走限流逻辑
没打结构化日志记录被限流的 IP、path、时间戳 → 出问题时没法快速定位是攻击还是业务异常
限流阈值写死在代码里，无法热更新 → 至少支持从配置中心（如 etcd / Nacos）动态拉取，不然大促前还得发版

真正难的从来不是“怎么写限流”，而是“怎么知道它正在起作用”。

# redis # git # go # github # golang # ai # 路由 # cos # red # lua # 中间件 # 线程 # map # delete # 算法 # etcd # prometheus # 令牌 # 复用 # 几个 # 就会 # 最多 # 打了 # 能在 # 更高 # 还得 # 越多

相关栏目：【网站优化151355 】【网络推广146373 】【网络技术251813 】【 AI营销90571 】