四种经典限流算法实现与深度解析

限流技术是保障系统稳定性的核心手段，本文通过Go语言实现并深入讲解四种经典限流算法。每种算法都包含实现原理、代码解析和场景建议，帮助开发者选择合适方案。

---

一、计数器固定窗口法

核心原理

将时间划分为固定长度窗口（如1分钟），每个窗口独立统计请求次数。当请求数超过阈值时触发限流。

package limiter

import (
	"sync"
	"time"
)

type FixedWindow struct {
	mu         sync.Mutex
	counter    int
	limit      int
	windowSize time.Duration
	windowEnd  time.Time
}

func NewFixedWindow(limit int, windowSize time.Duration) *FixedWindow {
	return &FixedWindow{
		limit:      limit,
		windowSize: windowSize,
		windowEnd:  time.Now().Add(windowSize),
	}
}

func (f *FixedWindow) Allow() bool {
	f.mu.Lock()
	defer f.mu.Unlock()

	now := time.Now()
	if now.After(f.windowEnd) {
		f.counter = 0
		f.windowEnd = now.Add(f.windowSize)
	}

	if f.counter >= f.limit {
		return false
	}

	f.counter++
	return true
}

关键逻辑

1. 当新请求到达时，检查是否进入新时间窗口
2. 若进入新窗口则重置计数器
3. 比较当前计数与限制阈值

典型问题：临界点穿透

假设窗口长度1分钟，限流100次：

窗口1 [00:00-00:59] 最后1秒涌入100请求
窗口2 [01:00-01:59] 第1秒又涌入100请求
实际在2秒内处理了200请求，超出系统承载

适用场景

• 对流量波动不敏感的系统
• 需要快速实现简单限流的场景
• 内部系统的基础防护层

---

二、滑动窗口法

核心改进

将固定窗口细分为多个时间片（slice），通过动态窗口消除临界问题。统计当前时间向前滑动的时间范围（如1分钟）内的总请求数。

type SlideWindow struct {
	mu          sync.Mutex
	requests    []time.Time
	windowSize  time.Duration
	maxRequests int
}

func NewSlideWindow(maxRequests int, windowSize time.Duration) *SlideWindow {
	return &SlideWindow{
		windowSize:  windowSize,
		maxRequests: maxRequests,
	}
}

func (s *SlideWindow) Allow() bool {
	s.mu.Lock()
	defer s.mu.Unlock()

	now := time.Now()
	// 移除过期请求
	cutoff := now.Add(-s.windowSize)
	var valid []time.Time
	for _, t := range s.requests {
		if t.After(cutoff) {
			valid = append(valid, t)
		}
	}
	s.requests = valid

	if len(s.requests) >= s.maxRequests {
		return false
	}

	s.requests = append(s.requests, now)
	return true
}

工作流程

1. 新请求到达时清理过期时间片（窗口大小之前的数据）
2. 统计剩余有效请求数
3. 判断是否超过阈值

内存优化技巧

• 使用环形缓冲区（ring buffer）替代slice
• 预分配固定容量内存
• 定期清理过期数据

优势对比

相比固定窗口：

• 精准度提升50%以上
• 相同时间维度下，突发流量控制更好
• 流量曲线更平滑

适用场景

• API网关限流
• 微服务接口防护
• 需要精确控制QPS的场景

---

三、漏桶算法

经典流量整形算法

以恒定速率处理请求，类似水桶底部漏水。无论流入速度多快，流出速率保持恒定。

type LeakyBucket struct {
	rate     time.Duration
	capacity int
	bucket   chan struct{}
}

func NewLeakyBucket(rate time.Duration, capacity int) *LeakyBucket {
	lb := &LeakyBucket{
		rate:     rate,
		capacity: capacity,
		bucket:   make(chan struct{}, capacity),
	}

	// 启动漏出协程
	go func() {
		ticker := time.NewTicker(rate)
		defer ticker.Stop()
		for range ticker.C {
			select {
			case <-lb.bucket:
			default:
			}
		}
	}()

	return lb
}

func (lb *LeakyBucket) Allow() bool {
	select {
	case lb.bucket <- struct{}{}:
		return true
	default:
		return false
	}
}

实现要点

1. 初始化时启动定时漏水协程
2. 使用缓冲通道模拟桶容量
3. 请求到达时尝试放入通道
4. 定时从通道取出请求处理

流量特征

• 输出速率恒定：rate = 1s/capacity
• 最大突发量 = 桶容量
• 不支持借用未来令牌

适用场景

• 网络流量整形
• 秒杀系统下单排队
• 需要严格限制处理速率的场景

---

四、令牌桶算法

弹性限流典范

系统以固定速率向桶内添加令牌，请求需要获取令牌才能被处理。允许突发流量消耗累积令牌。

type TokenBucket struct {
	mu          sync.Mutex
	tokens      float64
	maxTokens   float64
	refillRate  float64 // tokens per nanosecond
	lastRefill  time.Time
}

func NewTokenBucket(maxTokens float64, refillRatePerSec float64) *TokenBucket {
	return &TokenBucket{
		maxTokens:  maxTokens,
		refillRate: refillRatePerSec / 1e9,
		lastRefill: time.Now(),
	}
}

func (tb *TokenBucket) Allow() bool {
	return tb.AllowN(1)
}

func (tb *TokenBucket) AllowN(n float64) bool {
	tb.mu.Lock()
	defer tb.mu.Unlock()

	now := time.Now()
	elapsed := now.Sub(tb.lastRefill).Nanoseconds()
	tb.lastRefill = now

	// 补充令牌
	refillAmount := float64(elapsed) * tb.refillRate
	tb.tokens = min(tb.tokens+refillAmount, tb.maxTokens)

	if tb.tokens >= n {
		tb.tokens -= n
		return true
	}
	return false
}

func min(a, b float64) float64 {
	if a < b {
		return a
	}
	return b
}

关键算法

func (tb *TokenBucket) Allow() bool {
	// 1.计算时间差
	elapsed := now.Sub(lastRefill).Nanoseconds()
	
	// 2.补充令牌（惰性计算）
	refillAmount := float64(elapsed) * tb.refillRate
	tb.tokens = min(tb.tokens + refillAmount, tb.maxTokens)
	
	// 3.判断令牌是否足够
	if tb.tokens >= need {
		tb.tokens -= need
		return true
	}
	return false
}

核心优势

• 突发流量处理 = 桶容量
• 平均速率 = 令牌生成速率
• 支持预消费和平滑过渡

适用场景

• 开放平台API限流
• 云计算服务配额管理
• 需要弹性应对流量波动的场景

---

方案对比决策树

维度	固定窗口	滑动窗口	漏桶算法	令牌桶算法
时间复杂度	O(1)	O(n)	O(1)	O(1)
空间复杂度	O(1)	O(n)	O(k)	O(1)
突发流量处理	不支持	部分支持	有限支持	完全支持
流量平滑度	差	中等	优	良
实现难度	简单	中等	中等	较高

---

生产环境实践建议

1. 组合使用：网关层使用令牌桶应对突发，内部服务使用滑动窗口精确控制
2. 动态配置：结合配置中心实现限流参数的动态调整
3. 监控对接：集成Prometheus等监控系统，实时观测限流状态
4. 分级策略：区分API重要等级实施不同限流策略
5. 熔断降级：与熔断机制（如Hystrix）配合使用
6. 集群限流：在分布式场景下结合Redis实现全局限流

示例：电商系统限流方案设计

// API网关层使用令牌桶
gatewayLimiter := NewTokenBucket(1000, 500)

// 订单服务使用滑动窗口
orderLimiter := NewSlideWindow(200, time.Minute)

// 支付接口使用漏桶
paymentLimiter := NewLeakyBucket(100*time.Millisecond, 50)

---

性能优化技巧

1. 原子操作：令牌桶的token计数可使用atomic包优化
2. 时间缓存：在高并发场景缓存time.Now()值
3. 内存复用：滑动窗口使用sync.Pool管理请求记录
4. 批量处理：支持AllowN()方法处理批量请求
5. 预热机制：令牌桶支持冷启动时的线性增长

优化后的令牌桶实现：

type OptimizedBucket struct {
	atomicToken uint64
	// 其他字段...
}

func (b *OptimizedBucket) Allow() bool {
	return b.allow(1)
}

func (b *OptimizedBucket) allow(n uint64) bool {
	// 使用atomic操作实现无锁
	for {
		old := atomic.LoadUint64(&b.atomicToken)
		if old < n {
			return false
		}
		if atomic.CompareAndSwapUint64(&b.atomicToken, old, old-n) {
			return true
		}
	}
}

---

通过深入理解各算法特性，结合实际业务场景选择合适的限流策略，并配合监控和动态调整，才能构建出既弹性又稳定的流量控制系统。建议读者在理解本文示例代码的基础上，根据具体需求进行扩展和优化。