令牌桶算法允许突发流量，以固定速率添加令牌，请求需消耗令牌；漏桶算法严格按固定速率处理请求，平滑流量。1. 令牌桶实现包括设定桶容量、定时补充令牌、请求取令牌；2. 漏桶通过channel模拟队列，固定速率处理请求。适用场景上，令牌桶适合web api限流，漏桶适合后台任务队列。实现时需注意并发安全、精度问题和资源占用。
在微服务架构中，限流是保障系统稳定性的关键手段之一。Golang 作为构建高性能后端服务的热门语言，天然适合用来实现限流策略。其中，令牌桶（Token Bucket）和漏桶（Leaky Bucket）算法是最常见的两种限流机制，它们各有适用场景，实现方式也有明显差异。
下面我们就来看看这两种算法在 Golang 中如何实现，以及它们之间的区别和使用建议。
什么是令牌桶算法？
令牌桶算法的核心思想是：以固定速率往桶里添加令牌，请求需要消耗一个令牌才能被处理，如果桶里没有令牌，则拒绝请求或等待。
立即学习“go语言免费学习笔记（深入）”；
实现要点：
- 桶有容量上限，防止无限堆积。
- 定时补充令牌，比如每秒加 N 个。
- 请求到来时尝试从桶中取出一个令牌，取不到就拒绝。
适用场景：
- 需要应对突发流量（burst）的场景，比如短时间内的高并发访问。
- 希望允许一定程度的“突发”请求通过，而不是完全按固定速率限制。
Golang 示例代码片段：
type TokenBucket struct {
rate float64 // 每秒放入令牌数量
capacity float64 // 桶的最大容量
tokens float64
lastTime time.Time
mu sync.Mutex
}
func (tb *TokenBucket) Allow() bool {
tb.mu.Lock()
defer tb.mu.Unlock()
now := time.Now()
elapsed := now.Sub(tb.lastTime).Seconds()
tb.lastTime = now
tb.tokens += elapsed * tb.rate
if tb.tokens > tb.capacity {
tb.tokens = tb.capacity
}
if tb.tokens >= 1 {
tb.tokens -= 1
return true
}
return false
}什么是漏桶算法？
漏桶算法的核心逻辑是：请求进入“桶”中，桶以固定速率排水（处理请求），超出桶容量的请求被丢弃。
实现要点：
- 请求到来时先入桶排队。
- 固定速率处理请求，比如每秒处理 N 个。
- 如果桶满了，后续请求直接拒绝。
适用场景：
- 对请求处理速率要求非常稳定、不允许突增的场景。
- 更注重平滑流量，比如后台任务队列等。
Golang 实现思路：
通常可以用一个带缓冲的 channel 来模拟桶，生产者发送请求到 channel，消费者定时取出处理。
type LeakyBucket struct {
capacity int // 桶的大小
interval time.Duration // 排水间隔
queue chan struct{}
wg sync.WaitGroup
}
func (lb *LeakyBucket) Start() {
lb.wg.Add(1)
go func() {
ticker := time.NewTicker(lb.interval)
for range ticker.C {
select {
case <-lb.queue:
default:
}
}
lb.wg.Done()
}()
}
func (lb *LeakyBucket) Allow() bool {
select {
case lb.queue <- struct{}{}:
return true
default:
return false
}
}令牌桶 vs 漏桶：有什么不同？
| 特性 | 令牌桶 | 漏桶 |
|---|---|---|
| 控制维度 | 控制请求是否能通过 | 控制请求处理速率 |
| 是否允许突发流量 | 是，桶未满时可突发 | 否，严格按固定速率处理 |
| 实现复杂度 | 相对简单，计算时间差 | 略复杂，需维护队列 |
| 适用场景 | Web API 限流、用户访问控制 | 任务调度、后台队列限速 |
总的来说：
- 令牌桶更灵活，适合前端服务、API 网关这类需要一定容错能力的场景。
- 漏桶更平稳，适合后台服务、消息队列消费等对稳定性要求极高的场景。
小贴士：实际使用中的几个注意点
- 令牌桶要注意精度问题，比如用
time.Since
计算时间差时可能因浮点数误差导致累积偏差。 - 漏桶的 channel 大小设置要合理，太大可能浪费资源，太小容易触发限流。
- 可以结合 Redis 实现分布式限流，把令牌桶状态保存在 Redis 中。
- 在高并发场景下，记得加锁保护共享变量，比如用
sync.Mutex
或原子操作。
基本上就这些了。这两个算法虽然原理不复杂，但在实际落地时细节很多，特别是要考虑并发安全和性能损耗的问题。
