Go语言实现请求频率限制的方法实践

在实际开发中，接口被恶意刷请求是个绕不开的难题。今天，我们就来深入聊聊Go语言里几种主流的请求限流方案，从入门到精通，帮你把服务的稳定性提升一个档次。

一、基础方案：计数器法（固定窗口）

适用场景：简单业务、低并发需求

type CounterLimiter struct {
	mu       sync.Mutex
	count    int
	interval time.Duration
	maxReq   int
	lastReset time.Time
}
func NewCounterLimiter(interval time.Duration, maxReq int) *CounterLimiter {
	return &CounterLimiter{
		interval:  interval,
		maxReq:    maxReq,
		lastReset: time.Now(),
	}
}
func (c *CounterLimiter) Allow() bool {
	c.mu.Lock()
	defer c.mu.Unlock()
	// 检查是否需要重置计数器
	if time.Since(c.lastReset) > c.interval {
		c.count = 0
		c.lastReset = time.Now()
	}
	// 检查是否超过限制
	if c.count >= c.maxReq {
		return false
	}
	c.count++
	return true
}
// HTTP中间件示例
func RateLimitMiddleware(limiter *CounterLimiter) func(http.Handler) http.Handler {
	return func(next http.Handler) http.Handler {
		return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
			if !limiter.Allow() {
				w.Header().Set("Retry-After", "60")
				http.Error(w, "Too Many Requests", http.StatusTooManyRequests)
				return
			}
			next.ServeHTTP(w, r)
		})
	}
}

这个方案的优势很明显：

• 实现起来特别简单，内存占用也低。
• 完全不需要引入任何第三方依赖。

但它的短板同样突出：

• 存在窗口边界问题，比如在时间窗口切换的瞬间，可能承受两倍的突发流量。
• 只适用于单机场景，分布式环境下就无能为力了。

二、进阶方案：Redis滑动窗口

适用场景：分布式系统、需要精确限流

const luaScript = `
local key = KEYS[1]
local now = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
local max = tonumber(ARGV[3])
redis.call('ZREMRANGEBYSCORE', key, 0, now - window)
local current = redis.call('ZCARD', key)
if current >= max then
    return 0
end
redis.call('ZADD', key, now, now)
redis.call('EXPIRE', key, math.ceil(window/1000))
return 1
`
type RedisLimiter struct {
	client   *redis.Client
	script   *redis.Script
	maxReq   int
	window   time.Duration
}
func NewRedisLimiter(client *redis.Client, window time.Duration, maxReq int) *RedisLimiter {
	return &RedisLimiter{
		client: client,
		script: redis.NewScript(luaScript),
		maxReq: maxReq,
		window: window,
	}
}
func (r *RedisLimiter) Allow(userID string) bool {
	ctx := context.Background()
	key := fmt.Sprintf("rate_limit:%s", userID)
	now := time.Now().UnixMilli()
	result, err := r.script.Run(ctx, r.client, 
		[]string{key}, now, r.window.Milliseconds(), r.maxReq).Int()
	return err == nil && result == 1
}

这个方案有几个关键实现点：

1. 利用Redis的有序集合来存储每次请求的时间戳。
2. 通过Lua脚本保证“清理过期记录-检查-写入新记录”这一系列操作的原子性。
3. 自动清理窗口期之前的旧数据，避免内存无限增长。
4. 能够精确统计任意滑动时间窗口内的请求数量。

它的优势在于：

• 实现了真正意义上的滑动窗口计数，精度高。
• 天然支持分布式系统，多个服务实例可以共享同一个计数状态。
• 利用Redis的过期机制，自动处理数据清理，省心省力。

三、高级方案：令牌桶算法

适用场景：需要允许合理突发流量、进行更精细控制的场景

type TokenBucket struct {
	capacity    int           // 桶容量
	tokens      int           // 当前令牌数
	fillRate    time.Duration // 添加令牌间隔
	lastRefill  time.Time     // 上次添加时间
	mu          sync.Mutex
}
func NewTokenBucket(capacity int, rate time.Duration) *TokenBucket {
	return &TokenBucket{
		capacity:   capacity,
		tokens:     capacity,
		fillRate:   rate,
		lastRefill: time.Now(),
	}
}
func (b *TokenBucket) Allow() bool {
	b.mu.Lock()
	defer b.mu.Unlock()
	// 补充令牌
	now := time.Now()
	elapsed := now.Sub(b.lastRefill)
	newTokens := int(elapsed / b.fillRate)
	if newTokens > 0 {
		b.tokens += newTokens
		if b.tokens > b.capacity {
			b.tokens = b.capacity
		}
		b.lastRefill = now
	}
	// 检查令牌是否足够
	if b.tokens <= 0 {
		return false
	}
	b.tokens--
	return true
}

令牌桶算法的特点很鲜明：

• 它允许短时间内的突发流量（只要桶里有足够的令牌）。
• 能够非常精确地控制请求的平均速率。
• 当然，实现起来比前面的方案要稍微复杂一些。

四、生产级方案：使用成熟中间件

如果追求快速落地和稳定性，直接使用社区成熟的限流库是更明智的选择。这里推荐两个经过大量项目验证的库：

• Tollbooth：功能丰富，配置灵活，与各种Web框架集成方便。
• Uber-go/ratelimit：Uber开源的漏桶算法实现，性能出色。

下面以Tollbooth为例，看看集成有多简单：

func main() {
	r := chi.NewRouter()
	
	// 创建限流器：每分钟1000次
	limiter := tollbooth.NewLimiter(1000/60.0, nil)
	limiter.SetIPLookups([]string{"X-Real-IP", "RemoteAddr", "X-Forwarded-For"})
	
	// 应用中间件
	r.Use(tollbooth_chi.LimitHandler(limiter))
	
	r.Get("/api/protected", func(w http.ResponseWriter, r *http.Request) {
		w.Write([]byte("Protected content"))
	})
	
	http.ListenAndServe(":8080", r)
}

五、方案选型指南

六、最佳实践

1. 分层防御：
   别把鸡蛋放在一个篮子里。一个健壮的限流体系应该是多层次的：

   • 前端：最基本的按钮防重复点击，减少无效请求。
   • 网关/入口层：进行基于IP或基础身份的粗粒度限流，挡住大部分异常流量。
   • 业务层：根据用户ID、API Key等进行精细化的控制，保护核心业务逻辑。

2. 动态调整：
   限流阈值不应该是一成不变的。根据系统负载动态调整，才能在保障稳定的同时最大化资源利用率。

   // 动态调整限流阈值
   func adjustLimitBasedOnSystemLoad() {
       load := getSystemLoad()
       if load > 0.8 {
           limiter.SetMaxRequests(500) // 高负载时降低阈值
       }
   }

3. 熔断机制：
   限流是“婉拒”，熔断则是“紧急制动”。当某个下游服务异常时，快速失败并进入熔断状态，避免雪崩。

   // 使用hystrix实现熔断
   hystrix.ConfigureCommand("my_api", hystrix.CommandConfig{
       Timeout:               1000,
       MaxConcurrentRequests: 100,
       ErrorPercentThreshold: 50,
   })
   

4. 监控指标：
   没有监控，限流就是盲人摸象。务必关注这些核心指标：

   • 请求拒绝率：直观反映限流效果。
   • 系统负载（CPU、内存、IO）：限流的重要依据。
   • 限流阈值命中率：帮助调整阈值设置。
   • Redis等外部组件的内存使用量和QPS：确保限流组件本身不会成为瓶颈。

总结

说到底，在Go语言中实现请求限流，关键在于匹配场景：

• 单机简单场景：计数器法就能搞定，省时省力。
• 分布式系统：Redis滑动窗口是更可靠的选择，保证全局一致性。
• 需要允许合理突发：令牌桶算法提供了这种灵活性。
• 追求快速上线和稳定：直接集成成熟的限流中间件，站在巨人的肩膀上。

最后记住一个黄金法则：没有所谓“最好”的限流方案，只有“最适合”当前业务场景的方案。建议从简单的实现开始，随着业务规模和复杂度的增长，逐步升级和叠加你的限流策略，最终构建一个包含多层防御、能动态调整的完整限流体系。