在高并发Web服务中，限流是防止系统被突发流量击穿的基础能力。无论是秒杀场景下的下单接口，还是对外开放的API网关，都需要在入口处控制请求速率。Go语言标准库没有内置限流器，但官方扩展包golang.org/x/time/rate实现了稳定的令牌桶算法，同时配合Redis可以构建分布式限流。本文将围绕算法选型、单机实现、分布式扩展和中间件集成四个层面展开，并提供可直接运行的代码示例。
一、限流算法的核心差异与选型
令牌桶算法是实际工程中使用最广泛的限流方案。它的核心是维护一个固定容量的令牌桶，系统以固定速率向桶中补充令牌，每个请求到达时需要消耗一个令牌，如果桶为空则拒绝请求或等待。桶容量决定了一次能够承受的最大突发流量，例如每秒补充5个令牌、桶容量为10，意味着正常情况下平均每秒处理5个请求，但短时间内最多可以连续处理10个请求，之后必须等待令牌补充。这种特性非常适合对突发流量有一定容忍度的Web接口。
漏桶算法则强调输出速率的绝对平滑。请求先进入一个队列，系统以固定速率从队列中取出请求并处理，即使上游瞬时压入大量请求，下游处理速率依然恒定。漏桶适合需要保护下游慢速系统的场景，但由于它无法利用空闲时段的处理能力，在流量波动较大的业务中会造成不必要的延迟。固定窗口计数实现简单，但存在临界突变问题：当大量请求集中在前一个窗口的最后100毫秒和后一个窗口的前100毫秒，两个窗口内的计数都没有超过阈值，但实际在200毫秒内放行了双倍流量。滑动窗口通过保留每个请求的时间戳并按当前时间动态计算窗口内的数量，可以避免这种临界问题，但实现成本更高。
在Go Web服务中，如果只需要保护单个实例不被突发流量打垮，令牌桶是最省心且高效的选择。golang.org/x/time/rate包内部使用基于时间的惰性计算，每次判断只做少量算术运算，并发安全，可以在全局共享一个Limiter实例。如果服务部署在多个实例且限流维度是全局唯一的，则需要将计数下沉到Redis等集中式存储。
二、用x/time/rate包实现单机令牌桶限流
golang.org/x/time/rate提供了Limiter类型用于管理令牌。创建时通过rate.NewLimiter(r, b)指定每秒生成的令牌数r和桶容量b。最常用的方法是Allow，它非阻塞地判断当前是否有可用令牌，如果可用则消耗一个令牌并返回true，否则返回false。下面是一个HTTP服务的完整示例。
package main
import (
"fmt"
"net/http"
"golang.org/x/time/rate"
)
var limiter = rate.NewLimiter(5, 10)
func handler(w http.ResponseWriter, r *http.Request) {
if !limiter.Allow() {
http.Error(w, "too many requests", http.StatusTooManyRequests)
return
}
fmt.Fprintln(w, "request allowed")
}
func main() {
http.HandleFunc("/api", handler)
http.ListenAndServe(":8080", nil)
}
这段代码创建了一个每秒产生5个令牌、桶容量为10的限流器。当请求到达/api接口时，先调用Allow判断是否放行。如果令牌不足，直接返回HTTP 429状态码。这里没有使用复杂的锁或定时器，Limiter内部通过原子操作和基于时间的计算保证并发安全，多个goroutine同时调用Allow也不会出现计数错误。
如果业务可以接受请求延迟而不希望直接拒绝，可以使用Wait方法。它接受一个context.Context参数，在令牌不足时会阻塞等待，直到有令牌可用或context被取消。例如ctx, cancel := context.WithTimeout(r.Context(), time.Second)后再调用limiter.Wait(ctx)，可以避免瞬时流量导致请求失败，同时保证等待时间上限。另一个方法是Reserve，它返回一个预留结果，调用方可以通过Delay方法获知需要等待多久才能拿到令牌，从而自行决定是等待、降级还是直接返回错误。对于大部分HTTP接口，推荐先用Allow做快速失败，外部由负载均衡或网关做重试，这样能更快释放资源。
设置桶容量时需要结合业务峰值来调整。桶容量太小会导致正常的流量波动也被拒绝，太大会让限流形同虚设。建议在压测时观察接口的请求分布，将burst设置为平均每秒请求数的2到3倍，rate设置为下游能稳定承载的每秒请求数。全局共享一个Limiter实例时，也可以按路径或用户维度拆分多个Limiter，避免某个高频接口占满所有令牌。
三、基于Redis的分布式限流
当服务有多个实例且前面没有统一网关时，每个实例各自维护一份本地令牌桶会导致整体限流失效。假设3个实例各自限流每秒100次，整个集群实际可能放行每秒300次请求。此时需要一个集中式的计数器，Redis天然适合承担这个角色。最直观的方案是固定窗口计数：以接口名加时间窗口作为key，每次请求时执行INCR，如果值超过阈值则拒绝，同时给key设置过期时间。这种方案实现简单，但同样存在窗口临界问题，流量在窗口切换瞬间可能翻倍。
滑动窗口方案通过Redis的有序集合（ZSet）记录每个请求的时间戳。每次请求到达时，先移除当前窗口之前的所有时间戳，再添加当前请求的时间戳，然后统计集合大小。以下示例使用go-redis的管道命令完成这一过程，减少网络往返。
package main
import (
"context"
"strconv"
"time"
"github.com/redis/go-redis/v9"
)
func allowRequest(ctx context.Context, rdb *redis.Client, key string, limit int64, window time.Duration) (bool, error) {
now := time.Now().UnixNano()
min := now - window.Nanoseconds()
pipe := rdb.TxPipeline()
pipe.ZRemRangeByScore(ctx, key, "0", strconv.FormatInt(min, 10))
pipe.ZAdd(ctx, key, redis.Z{Score: float64(now), Member: now})
pipe.ZCard(ctx, key)
pipe.Expire(ctx, key, window)
cmds, err := pipe.Exec(ctx)
if err != nil {
return false, err
}
count := cmds[2].(*redis.IntCmd).Val()
return count <= limit, nil
}
这个函数先计算窗口起点时间，然后在事务管道中依次执行移除过期时间戳、添加当前时间戳、统计集合大小和设置过期时间四条命令。最后的比较语句在Go代码中就是count <= limit。由于管道命令不是完全原子，在极高并发下可能出现计数不精确的情况。如果对精度要求很高，可以将这段逻辑改写成Lua脚本，通过EVAL一次执行，Redis会保证脚本内部命令的原子性。Lua脚本中同样执行ZRemRangeByScore、ZAdd、ZCard和Expire，最后返回计数与阈值比较的结果。
需要特别注意的是Redis分布式限流会增加一次网络调用，接口延迟会比本地限流高。在流量很大的系统中，Redis本身可能成为瓶颈。可以结合本地限流作为第一道防线，例如每个实例本地限流到集群总限流的50%，再用Redis做精确控制，这样既能降低Redis压力，又能把整体流量限制在目标范围内。另一个常见做法是引入网关层限流，由Kong、APISIX等组件在请求进入服务前完成限流，业务代码只处理已经通过限流的请求。
四、将限流逻辑封装为HTTP中间件
把限流判断写进每个handler会导致大量重复代码，更合理的做法是封装成HTTP中间件。中间件可以在请求进入业务逻辑之前统一执行限流决策，并根据不同维度（如用户ID、IP地址或接口路径）选择不同的限流器。下面是一个基于x/time/rate的动态限流中间件实现。
package main
import (
"net/http"
"sync"
"golang.org/x/time/rate"
)
type rateLimiterMiddleware struct {
mu sync.RWMutex
limiters map[string]*rate.Limiter
rate rate.Limit
burst int
}
func (m *rateLimiterMiddleware) getLimiter(key string) *rate.Limiter {
m.mu.RLock()
limiter, ok := m.limiters[key]
m.mu.RUnlock()
if ok {
return limiter
}
m.mu.Lock()
defer m.mu.Unlock()
if limiter, ok := m.limiters[key]; ok {
return limiter
}
limiter = rate.NewLimiter(m.rate, m.burst)
m.limiters[key] = limiter
return limiter
}
func (m *rateLimiterMiddleware) Handle(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
key := r.Header.Get("X-User-Id")
if key == "" {
key = r.RemoteAddr
}
if !m.getLimiter(key).Allow() {
http.Error(w, "rate limit exceeded", http.StatusTooManyRequests)
return
}
next.ServeHTTP(w, r)
})
}
中间件内部使用map存储每个限流键对应的Limiter实例，并用读写锁保证并发安全。获取限流器时采用双重检查模式，避免每次请求都加写锁。选择用户ID作为默认限流维度，如果请求头中没有用户ID则退化为按客户端IP限流。对于登录用户，也可以从JWT中解析用户身份后作为key，这样不同用户之间的流量互不影响。
在生产环境中，还需要考虑两点：一是map中限流器的数量会随着用户或IP数量增长，长期运行可能导致内存膨胀，可以定期清理长时间未使用的条目；二是限流参数可能需要动态调整，不要重新部署服务。可以将rate和burst放入atomic.Value或通过配置中心订阅，当配置变化时重新构建新的限流器。返回429响应时，最好设置Retry-After头，告诉客户端大约多久之后可以重试。同时记录限流命中日志，便于监控和告警。
限流本身不是目的，只是保障系统稳定的一种手段。实际使用时需要和超时控制、熔断降级、重试策略配合。比如限流器返回拒绝时，可以让客户端走缓存数据或返回兜底结果，而不是直接显示错误页面。对于内部服务之间的调用，限流阈值应该参照下游服务的容量来设置，并预留一定缓冲，避免级联故障。