17370845950

最常用轻量HTTP限流方式是golang.org/x/time/rate.Limiter，基于令牌桶算法、线程安全；需服务启动时复用实例，按IP/用户/路径等粒度限流，配合sync.Map实现per-IP限流并注意过期清理，返回429时应设Retry-After等标准响应头，高并发下需关注Reserve()带来的GC和锁竞争问题。

用 golang.org/x/time/rate 实现 HTTP 请求限流

限流最常用、最轻量的方式就是用官方维护的 rate.Limiter。它基于令牌桶算法，线程安全，适合在 HTTP handler 中直接使用。

关键点是：不要为每个请求新建 rate.Limiter，而应在服务启动时初始化并复用；限流粒度按 IP、用户 ID 或路由路径决定，不能只靠全局单例。

• rate.NewLimiter(rate.Limit(10), 5) 表示最大每秒 10 个请求，初始桶容量为 5（允许短时突发）
• 调用 limiter.Allow() 判断是否放行，返回 true 表示通过；更推荐用 limiter.Wait(ctx)，它会自动阻塞或超时，避免忙等
• 若需按 IP 限流，从 r.RemoteAddr 提取客户端真实 IP（注意 X-Forwarded-For 可伪造，生产环境应结合可信代理列表校验）

func rateLimitedHandler(limiter *rate.Limiter) http.HandlerFunc {
	return func(w http.ResponseWriter, r *http.Request) {
		if !limiter.Allow() {
			http.Error(w, "Too Many Requests", http.StatusTooManyRequests)
			return
		}
		w.WriteHeader(http.StatusOK)
		w.Write([]byte("OK"))
	}
}

基于中间件实现 per-IP 限流

单纯用一个全局限流器无法区分不同用户，容易误伤。常见做法是用 sync.Map 按 IP 维护独立的 *rate.Limiter，但要注意内存泄漏和过期清理。

问题在于：长期存活的 rate.Limiter 实例不会自动销毁，若不做淘汰，map 会无限增长。不建议用 time.Now().Sub() 手动遍历清理——性能差且易出错。

• 用 sync.Map 存储 map[string]*rate.Limiter，key 是清洗后的 IP 字符串
• 每次请求先 LoadOrStore 获取对应限流器，避免重复创建
• 配合后台 goroutine 定期扫描过期项（例如 30 分钟无访问的 IP），但更稳妥的做法是改用带 TTL 的库如 github.com/patrickmn/go-cache
• 注意 IPv6 地址字符串长度远大于 IPv4，做 key 时建议统一规范化（如去掉前导 0、转小写）

HTTP 429 响应头与重试提示

返回 429 Too Many Requests 时，光给状态码不够。客户端需要知道“什么时候能再试”，否则可能盲目重试加剧压力。

标准做法是设置 Retry-After 响应头，值可以是秒数或 HTTP-date。但 rate.Limiter 本身不暴露下次可用时间，得自己算。

• 调用 limiter.Reserve() 得到 *rate.Reservation，再用 reservation.Delay() 获取等待时长
• 若 Delay() 返回 0，说明可立即执行，仍建议设 Retry-After: 0 保持语义清晰
• 避免返回绝对时间（如 time.Now().Add(delay).Format(time.RFC1123)），因客户端时钟可能不准；优先用秒数
• 同时设置 X-RateLimit-Limit、X-RateLimit-Remaining 等 header，方便前端调试

func withRateLimitHeader(limiter *rate.Limiter) http.HandlerFunc {
	return func(w http.ResponseWriter, r *http.Request) {
		res := limiter.Reserve()
		if !res.OK() {
			http.Error(w, "Too Many Requests", http.StatusTooManyRequests)
			return
		}
		if delay := res.Delay(); delay > 0 {
			w.Header().Set("Retry-After", strconv.FormatInt(int64(delay.Seconds()), 10))
		}
		w.WriteHeader(http.StatusOK)
		w.Write([]byte("OK"))
	}
}

高并发下 rate.Limiter 的性能隐患

rate.Limiter 单实例在万级 QPS 下基本无压力，但一旦引入 per-IP map + Reserve() 调用链，CPU 和 GC 压力会上升明显——尤其是频繁调用 Reserve() 创建临时对象。

真正卡点往往不在算法本身，而在锁竞争和内存分配。比如用 sync.RWMutex 包裹 map 访问，在热点 IP 频繁请求时会成为瓶颈。

• 避免在 handler 中做字符串拼接、正则匹配、JSON 解析等耗时操作后再限流；应尽早拦截
• 对静态资源（/static/、/healthz）或已认证的内部服务调用，建议跳过限流逻辑
• 压测时观察 runtime.ReadMemStats 中的 PauseTotalNs 和 NumGC，若 GC 频繁，很可能是 Reserve() 或日志打印导致的短期对象暴增
• 极端场景可考虑用原子计数器 + 时间窗口（如每秒重置）替代令牌桶，牺牲精度换性能，但要注意时钟跳跃导致的窗口错位

实际部署时，最容易被忽略的是限流策略和业务 SLA 的对齐。比如登录接口被限流，用户反复刷新反而触发更多失败请求；又比如限流未区分 GET/POST，导致健康检查探针也被拦住。这些都得结合具体路由、方法、来源做细粒度控制，而不是套一个通用中间件就完事。