17370845950

直接用 golang.org/x/time/rate 容易限不住流量，因其默认基于请求到达时间做令牌桶判断，单实例无法感知全局流量，导致多实例下总流量超限；真正可用的限流需跨实例共享状态、支持突发控制、区分调用方或接口粒度。

为什么直接用 golang.org/x/time/rate 容易限不住流量

因为 rate.Limiter 默认基于「请求到达时间」做令牌桶判断，但微服务中常有并发请求、网络延迟、重试等场景，单实例的 Limiter 无法感知全局流量。比如两个服务实例各自限流 100 QPS，实际总入口可能突增到 200 QPS，后端仍被打垮。

真正可用的限流必须满足：可跨进程/实例共享状态、支持突发流量平滑控制、能区分调用方或接口粒度。

• 单机限流只适合压测或开发环境验证，上线前务必替换为分布式方案
• rate.Every(10 * time.Millisecond) 这种写法隐含每秒 100 次，但实际吞吐受处理耗时影响，不是硬 QPS 限制
• 别把 Allow() 放在 handler 最外层——它不阻塞，返回 false 后需主动 return，否则逻辑仍会执行

用 Redis + Lua 实现原子化分布式限流

核心是用 Redis 的 INCR + EXPIRE 组合存在竞态，必须用 Lua 脚本保证「计数+过期设置」原子性。Go 侧只需调用 Eval，无需自己加锁或重试。

典型脚本（key 是限流标识，如 "limit:api:/user/profile:192.168.1.100"）：

local current = redis.call("INCR", KEYS[1])
if current == 1 then
    redis.call("EXPIRE", KEYS[1], tonumber(ARGV[1]))
end
if current > tonumber(ARGV[2]) then
    return 0
end
return 1

• KEYS[1] 是限流 key，建议包含服务名、接口路径、客户端 IP 或用户 ID
• ARGV[1] 是窗口秒数（如 60），ARGV[2] 是该窗口内最大请求数（如 1000）
• Golang 调用时用 redisClient.Eval(ctx, script, []string{key}, windowSec, maxReq).Int()
• 注意 Redis 连接池要足够大，避免限流逻辑本身成为瓶颈

如何给不同 API 设置差异化限流规则

硬编码每个接口的 maxReq 和 windowSec 不可持续。推荐用配置中心（如 etcd 或 Consul）动态加载规则，并监听变更。

结构示例（YAML）：

rules:
- path: "/api/v1/order/create"
  method: "POST"
  limit: 50
  window: 60
  by: "client_ip"
- path: "/api/v1/user/info"
  method: "GET"
  limit: 200
  window: 60
  by: "user_id"

• 解析后构造成 map[string]*Rule，key 可为 method:path（如 "GET:/api/v1/user/info"）
• 中间件中先匹配规则，再拼出 Redis key："limit:" + rule.by + ":" + value（value 来自 r.Header.Get("X-User-ID") 或 r.RemoteAddr）
• 没匹配到规则时，走默认限流（如 1000 QPS），避免配置遗漏导致全放开

限流日志与拒绝响应怎么写才不拖慢服务

记录每次被限流的请求详情（IP、path、UA）看似合理，但高频打日志会显著增加延迟和磁盘 IO。更稳妥的做法是采样记录 + 异步上报。

• 拒绝响应统一返回 http.StatusTooManyRequests，body 精简为 JSON：{"error":"rate_limited","retry_after":60}
• 用 log.Printf 前加个概率采样：if rand.Intn(100) == 0 { log.Printf("...") }
• 关键指标（如每分钟被限次数）用 Prometheus 的 Counter 上报，不要依赖日志 grep
• 别在限流中间件里调用外部服务（如发告警），失败或超时会卡住整个请求链路

真正难的不是写限流代码，而是确定哪些接口该限、限多少、依据什么数据调整——这些得靠线上监控和业务反馈持续迭代，代码只是执行载体。