令牌桶算法是一种限流策略，其核心思想是系统以固定速率向桶中添加令牌，请求需获取令牌才能被处理；它允许令牌积累，从而支持突发流量。漏桶算法则是按固定速率处理请求，无论输入如何波动，输出始终平稳。实现上，令牌桶可使用golang.org/x/time/rate包，设置填充速率和容量，如每秒100个请求、突发200；漏桶可通过channel或自定义结构体实现，保持稳定输出。选择时，令牌桶适合前端应对突发流量，漏桶适合后端平滑处理；分布式场景下可用redis+lua全局计数器、滑动窗口算法或服务网格工具如istio实现跨节点限流。
在go语言构建的微服务中，限流是保障系统稳定性的重要手段。令牌桶和漏桶算法是最常见的两种限流策略，它们通过控制请求处理的速度，防止系统被突发流量压垮。这两种算法虽然原理不同，但在实际应用中都十分有效。
什么是令牌桶算法？
令牌桶算法的核心思想是：系统以固定速率往桶里“添加令牌”，每个请求需要获取一个令牌才能被处理。如果桶满了，多余的令牌不会被保存；如果没有请求使用，令牌可以积累起来，用于应对短时间内的流量高峰。
这种方式更适合应对突发流量，因为只要桶中有足够的令牌，多个请求可以在短时间内被同时处理。
立即学习“go语言免费学习笔记（深入）”；
实现建议：
- 使用
golang.org/x/time/rate
包中的
Limiter
类型，它本质上就是一个令牌桶实现。
- 设置合适的填充速率（burst）和初始容量（rate），比如每秒允许处理100个请求，但允许最多200个请求的突发流量。
- 在http中间件中加入限流逻辑，对所有入口请求进行统一限制。
limiter := rate.NewLimiter(rate.Every(time.Second/100), 200) func limit(next http.HandlerFunc) http.HandlerFunc { return func(w http.ResponseWriter, r *http.Request) { if !limiter.Allow() { http.Error(w, "Too many requests", http.StatusTooManyRequests) return } next(w, r) } }
漏桶算法的基本思路
漏桶算法则是将请求放入一个“桶”中，然后按照固定的速率从桶中取出处理。无论请求是否连续到达，系统的处理速度始终保持一致。当桶满时，新的请求会被丢弃或排队等待。
这种机制更适合平滑流量输出，避免后端服务受到波动影响。
应用建议：
- 漏桶算法适合做接口调用频率控制，比如对外部API的访问。
- 可以自己实现一个基于channel的简单漏桶模型。
- 如果使用第三方库，可以选择类似
github.com/ulule/limiter
这样的包，支持多种限流策略。
type LeakyBucket struct { rate float64 // 每秒出水速率 capacity float64 // 桶容量 water float64 // 当前水量 lastLeakMs int64 // 上次漏水时间戳 } func (b *LeakyBucket) Allow() bool { now := time.Now().UnixNano() / int64(time.Millisecond) delta := (now - b.lastLeakMs) * int64(b.rate) / 1000 if delta > 0 { b.water = max(0, b.water-delta) b.lastLeakMs = now } if b.water+1 <= b.capacity { b.water += 1 return true } else { return false } }
如何选择令牌桶还是漏桶？
两者各有适用场景：
- 令牌桶更灵活，支持突发流量，适用于前端接收用户请求的场景。
- 漏桶更稳定，输出流量更均匀，适用于后端任务调度、数据库连接池等场景。
有时候也可以结合使用，比如外层用漏桶控制整体吞吐量，内层用令牌桶处理局部突发请求。
分布式限流需要注意什么？
在单机部署的场景下，使用上述算法已经足够。但如果是在分布式微服务架构中，还需要考虑跨节点的一致性问题。
常见做法包括：
- 使用redis + Lua脚本实现全局计数器限流。
- 使用滑动窗口算法替代固定窗口，提高精度。
- 集成服务网格如Istio，在Envoy层面做限流控制。
例如，使用redis记录某个用户的请求次数，并设置过期时间：
key := "rate_limit:user_123" count, _ := redis.Int(conn.Do("GET", key)) if count >= MaxRequests { return false } conn.Do("INCR", key) conn.Do("EXPIRE", key, 60) // 一分钟过期 return true
当然，这种方式会有网络开销，适合对一致性要求较高的场景。
基本上就这些。限流本身不复杂，但要根据业务需求选择合适的算法和实现方式，否则容易出现误拦或放行过多的问题。
