如何用Golang实现请求限流_Golang Web请求限流技巧

固定窗口计数限流存在临界突刺问题,适合低精度场景;令牌桶算法通过golang.org/x/time/rate实现平滑限流,支持突发流量;分布式环境下需结合Redis的INCR与EXPIRE命令或Lua脚本实现全局限流,确保多实例间请求控制一致。

在高并发场景下,控制请求频率是保护后端服务稳定的重要手段。Golang 因其高效的并发模型,非常适合实现请求限流。常见的限流策略有固定窗口、滑动窗口、漏桶和令牌桶算法。下面介绍几种实用的 Golang 请求限流技巧,帮助你在 Web 服务中有效控制流量。

使用标准库实现简单的计数器限流

最基础的限流方式是固定时间窗口计数。比如限制每秒最多 100 个请求,可以维护一个每秒重置的计数器。

虽然简单,但存在“临界突刺”问题——大量请求可能集中在窗口切换时通过。适合对精度要求不高的场景。

示例代码:

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。合理限流,既能防刷又能保障核心服务稳定。