固定窗口计数限流存在临界突刺问题，适合低精度场景；令牌桶算法通过golang.org/x/time/rate实现平滑限流，支持突发流量；分布式环境下需结合Redis的INCR与EXPIRE命令或Lua脚本实现全局限流，确保多实例间请求控制一致。
在高并发场景下，控制请求频率是保护后端服务稳定的重要手段。Golang 因其高效的并发模型，非常适合实现请求限流。常见的限流策略有固定窗口、滑动窗口、漏桶和令牌桶算法。下面介绍几种实用的 Golang 请求限流技巧，帮助你在 Web 服务中有效控制流量。
使用标准库实现简单的计数器限流
最基础的限流方式是固定时间窗口计数。比如限制每秒最多 100 个请求，可以维护一个每秒重置的计数器。
虽然简单，但存在“临界突刺”问题——大量请求可能集中在窗口切换时通过。适合对精度要求不高的场景。
示例代码：
立即学习“go语言免费学习笔记（深入）”；
var (
requestCount int
lastReset = time.Now()
mu sync.Mutex
)
func rateLimitMiddleware(next http.HandlerFunc) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
mu.Lock()
now := time.Now()
if now.Sub(lastReset) > time.Second {
requestCount = 0
lastReset = now
}
if requestCount >= 100 {
http.StatusTooManyRequests, nil)
return
}
requestCount++
mu.Unlock()
next(w, r)
}
}
基于 Token Bucket 的平滑限流
令牌桶算法允许突发流量，同时控制平均速率，是更灵活的选择。Golang 标准库 golang.org/x/time/rate 提供了开箱即用的实现。
你可以为每个客户端或全局创建一个限流器，控制每秒生成的令牌数和最大突发量。
常见用法：
- 每秒填充 10 个令牌，最多允许突发 50 个请求
- 使用 Allow() 或 Wait() 方法判断是否放行请求
- 结合 context 实现超时控制
import "golang.org/x/time/rate"
var limiter = rate.NewLimiter(10, 50) // 10rps, burst=50
func limitHandler(w http.ResponseWriter, r *http.Request) {
if !limiter.Allow() {
http.StatusTooManyRequests, nil)
return
}
// 处理业务逻辑
}
分布式环境下的限流方案
单机限流无法应对多实例部署。要实现全局限流，需依赖共享存储如 Redis。
利用 Redis 的 INCR 和 EXPIRE 命令，可实现分布式固定窗口限流。Lua 脚本能保证原子性操作。
推荐使用 RediSearch 或直接调用 Lua 脚本实现滑动窗口算法，避免多个命令间的竞争问题。
例如：统计最近一分钟的请求数，超过阈值则拒绝。
// Lua script example for sliding window
local count = redis.call("INCR", KEYS[1])
if count == 1 then
redis.call("EXPIRE", KEYS[1], 60)
end
return count <= tonumber(ARGV[1]) and 1 or 0
在 Go 中使用 go-redis 驱动执行该脚本，实现跨节点一致的限流控制。
中间件方式集成限流逻辑
将限流封装成 HTTP 中间件，便于复用和组合。可以根据路径、IP、用户 ID 等维度设置不同规则。
建议结构：
- 定义限流配置结构体，包含 qps、burst、keyFunc（如获取客户端 IP）
- 使用 map + sync.RWMutex 缓存每个 key 对应的限流器
- 定期清理长时间不用的限流器，防止内存泄漏
这样既能支持个性化限流，又能保持性能开销可控。
基本上就这些。选择合适的算法取决于你的业务需求：追求简单可用选 token bucket，需要精确控制用滑动窗口，分布式系统别忘了引入 Redis。合理限流，既能防刷又能保障核心服务稳定。
