Golang限流算法详解：令牌桶、漏桶与滑动窗口

本文深入对比了Go语言中三种主流限流算法——令牌桶、漏桶与滑动窗口的实际应用差异，重点剖析了官方`golang.org/x/time/rate`包中`rate.Limiter`这一生产级令牌桶实现的正确用法：它线程安全、无锁高效、支持突发流量，但极易因误解速率与桶容量关系（如将`Every(200ms), 3`误读为“每秒5次”）而配置失当；文章明确指出应全局复用Limiter而非按请求新建，并强调`Allow()`适合快速失败场景、`Wait()`需配合超时控制；同时澄清漏桶虽不适合用户侧HTTP接口（因削峰过于刚性、损害体验），却在后台异步任务（如日志上报、消息消费）中大放异彩——整篇以实战经验为锚点，帮你避开常见坑、选对算法、写出稳定高并发的限流逻辑。

用 rate.Limiter 做令牌桶，90% 场景够用了

Go 官方扩展库 golang.org/x/time/rate 提供的 rate.Limiter 就是生产级令牌桶实现，不是玩具。它支持突发、线程安全、无锁核心路径，且已通过大量高并发服务验证。

常见错误是误以为 rate.NewLimiter(rate.Every(200*time.Millisecond), 3) 表示“每秒 5 次”，其实它等价于“每 200ms 放 1 个令牌，桶最多存 3 个”——即允许瞬间连发 3 次，之后必须等 200ms 才能再发第 4 次。

• 用 limiter.Allow() 非阻塞判断：适合快速拒绝，但不保证后续请求立刻能过（可能刚被抢光）
• 用 limiter.Wait(ctx) 阻塞等待：适合对延迟敏感的接口，比如支付回调，但需设好 ctx.WithTimeout，否则可能卡死
• 别为每个请求 new 一个 Limiter：它是并发安全的，全局复用即可；按 IP 或用户 ID 区分限流时，才用 sync.Map 或 map[string]*rate.Limiter 缓存

漏桶不适合 HTTP 接口，但适合后台任务调度

漏桶强调“恒定输出速率”，天然不支持突发，HTTP 用户连点刷新、重试等行为会被硬性削峰，体验差。它真正的用武之地是内部异步任务，比如日志批量上报、消息队列消费、数据库写入批处理。

纯 Go 实现不需要 Redis 或外部依赖，核心就两行逻辑：time.Ticker 定期从 channel 取任务，select { case ch 控制入桶。桶容量 = channel 缓冲区大小，漏速 = Ticker.C 的间隔。

• 别拿漏桶做 API 限流：用户看到的是“点了没反应”，而不是“稍等一下”，容易引发重试风暴
• 慎用 time.Sleep 模拟漏出：会阻塞 goroutine，高并发下 goroutine 泄漏风险大
• 如果真要用，优先封装成函数式提交接口 Submit(func()) bool，而非暴露 channel 给业务层

滑动窗口要自己写，uber-go/ratelimit 不是你要的那个

很多人搜到 go.uber.org/ratelimit，发现它其实是“原子时钟版的令牌桶”，不是滑动窗口。它用 unsafe.Pointer + atomic 实现纳秒级精度的单次请求间隔控制，适用于低延迟微服务间调用限流，但**不统计请求数，也不支持“1 分钟内最多 100 次”这种语义**。

真正滑动窗口得自己维护时间戳队列或环形缓冲区。简单可靠的做法是用 []time.Time + sync.Mutex，每次请求时删掉过期时间戳再追加当前时间。注意：这不是 O(1)，但只要窗口粒度 ≥ 100ms、最大请求数 ≤ 1000，实际压测中 CPU 开销可忽略。

• 别用 map 按秒 key 存计数：固定窗口有临界突增问题（如 00:59.9s 和 01:00.1s 的两个请求会被算作不同窗口）
• 别在循环里调 time.Now() 多次：窗口判断只调一次，所有比较基于同一个 now
• 若需高并发无锁，可用 ringbuffer + CAS，但绝大多数业务没必要——先跑通带锁版本，再看 metrics 是否真成瓶颈

分布式限流绕不开 Redis + Lua，但别一上来就上

单机 rate.Limiter 在多实例部署时完全失效。此时必须引入外部协调，Redis 是最现实的选择：用 EVAL 执行 Lua 脚本保证“读+写+判断”原子性，配合 INCR + EXPIRE 模拟滑动窗口，或用 zset 存时间戳做精确滑动。

但代价明显：每次请求多一次网络 RTT，Redis 成为单点依赖，脚本写错会导致全局限流失效。所以务必遵守“先单机，再集群”的演进节奏。

• 别在 Lua 脚本里做复杂计算：只做计数和过期判断，业务逻辑留在 Go 层
• 别省略 fallback：Redis 不可用时，降级到本地 rate.Limiter，避免雪崩
• 限流 key 设计要合理：比如 rate:ip:req.RemoteAddr 或 rate:uid:userID，避免用完整 URL（易被构造恶意长 key）

限流不是越严越好，也不是算法越新越好。真正难的是定义清楚“谁该被限、为什么限、限多少”，以及把 Allow() 的返回值转化成用户能理解的响应（比如带 Retry-After header）。算法只是工具，别让它反客为主。

理论要掌握，实操不能落！以上关于《Golang限流算法详解：令牌桶、漏桶与滑动窗口》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！