限流是保障高并发golang微服务稳定的关键，常用方法包括：1. 计数器限流（固定窗口）实现简单但存在突刺效应；2. 滑动窗口限流通过细分时间窗口避免流量突增；3. 令牌桶限流支持突发流量，golang.org/x/time/rate包已封装；4. 漏桶限流以恒定速率处理请求，适合平滑输出；5. 分布式限流结合redis与lua脚本实现集群环境下的原子操作。应根据场景选择策略：单机用rate.Limiter，突发选令牌桶，平滑用漏桶，集群配redis。
在构建高并发的 Golang 微服务系统时，限流是保障服务稳定性的关键手段。当请求量超出系统处理能力时，不限制流量会导致服务雪崩。Golang 因其高并发支持和轻量级特性，非常适合实现高效的限流策略。以下是几种常见的限流方法及其在 Golang 中的具体实现方式。
1. 计数器限流（固定窗口）
计数器是最简单的限流算法，设定一个时间窗口内的最大请求数，超过则拒绝请求。
例如：限制每秒最多处理 100 个请求。
缺点：存在“突刺效应”，即在窗口切换瞬间可能承受双倍流量。
实现示例：
立即学习“go语言免费学习笔记（深入）”；
type CounterLimiter struct { count int limit int window time.Duration startTime time.Time } func NewCounterLimiter(limit int, window time.Duration) *CounterLimiter { return &CounterLimiter{ limit: limit, window: window, startTime: time.Now(), } } func (c *CounterLimiter) Allow() bool { now := time.Now() if now.Sub(c.startTime) > c.window { c.count = 0 c.startTime = now } if c.count >= c.limit { return false } c.count++ return true }2. 滑动窗口限流
滑动窗口是对固定窗口的优化，将时间窗口划分为多个小格子，通过统计更精细的时间段内请求数来避免突刺问题。
可以使用环形缓冲区或队列记录每个请求的时间戳，判断最近窗口内的请求数是否超限。
实现思路：
- 维护一个有序队列，保存请求到达时间
- 每次请求时，移除早于当前窗口的记录
- 若队列长度大于阈值，则拒绝请求
type SlidingWindowLimiter struct { window time.Duration maxRequests int requests []time.Time mu sync.Mutex } func (s *SlidingWindowLimiter) Allow() bool { s.mu.Lock() defer s.mu.Unlock() now := time.Now() // 移除过期请求 for len(s.requests) > 0 && now.Sub(s.requests[0]) >= s.window { s.requests = s.requests[1:] } if len(s.requests) < s.maxRequests { s.requests = append(s.requests, now) return true } return false }3. 令牌桶限流
令牌桶允许一定程度的突发流量。系统以恒定速率生成令牌，每个请求需要获取一个令牌才能执行。
Golang 标准库中的 golang.org/x/time/rate 就基于令牌桶实现。
使用示例：
import "golang.org/x/time/rate" limiter := rate.NewLimiter(rate.Limit(100), 200) // 每秒100个令牌，初始容量200 func handler(w http.ResponseWriter, r *http.Request) { if !limiter.Allow() { http.Error(w, "Too Many Requests", http.StatusTooManyRequests) return } // 处理请求 }适用于需要平滑控制且容忍短时突发的场景。
4. 漏桶限流
漏桶以固定速率处理请求，超出桶容量的请求被丢弃或排队。
与令牌桶不同，漏桶强调请求的“平滑输出”，适合防止下游服务被突发压垮。
简易实现：
type LeakyBucket struct { capacity int // 桶容量 water int // 当前水量 rate int // 漏水速率（单位/秒） lastLeak time.Time // 上次漏水时间 mu sync.Mutex } func (b *LeakyBucket) Allow() bool { b.mu.Lock() defer b.mu.Unlock() now := time.Now() // 计算应漏掉的水量 elapsed := now.Sub(b.lastLeak).Seconds() leak := int(elapsed) * b.rate if leak > 0 { b.water = max(0, b.water-leak) b.lastLeak = now } if b.water < b.capacity { b.water++ return true } return false }5. 分布式限流（Redis + Lua）
在微服务集群中，单机限流不够，需借助中心化存储如 Redis 实现分布式限流。
推荐使用 Redis 的 Lua 脚本保证原子性，实现类似令牌桶或滑动窗口的逻辑。
示例 Lua 脚本（滑动窗口）：
-- KEYS[1]: key -- ARGV[1]: window size in seconds -- ARGV[2]: max requests local key = KEYS[1] local window = tonumber(ARGV[1]) local max = tonumber(ARGV[2]) local now = redis.call('TIME')[1] -- 移除过期请求 redis.call('ZREMRANGEBYSCORE', key, 0, now - window) -- 统计当前请求数 local current = redis.call('ZCARD', key) if current < max then redis.call('ZADD', key, now, now .. '-' .. math.random()) redis.call('EXPIRE', key, window) return 1 else return 0 endGo 调用：
script := redis.NewScript(luaScript) result, err := script.Run(ctx, client, []string{"limit:user:123"}, window, max).Int() return result == 1基本上就这些。根据业务场景选择合适的限流策略：单机可用 rate.Limiter，需要突发容忍选令牌桶，要求平滑输出用漏桶，集群环境结合 Redis 实现分布式限流。关键是理解每种算法的适用边界，避免误用导致限流失效或过度拦截。