Gin框架防刷限流中间件基于令牌桶算法的实现-Golang-PHP中文网

因为单机内存令牌桶无法共享状态，多实例部署下各节点独立计数导致限流失效；redis限流必须用lua脚本原子执行读、判、扣、设过期全流程，避免incr+expire竞态引发超发或key永久残留。

gin框架防刷限流中间件基于令牌桶算法的实现

为什么不用内存版令牌桶做生产限流

因为单机内存计数器在多实例部署下完全失效。你本地测试 TokenBucketLimiter 能跑通，上线后流量打到不同机器，每个实例各自维护一套桶，等于没限。真实场景中，哪怕只是两台负载均衡后的 Gin 服务，限流阈值就会翻倍——用户刷个接口，轻松绕过限制。

常见错误现象：429 Too Many Requests 偶发不触发、压测时限流形同虚设、日志里看到同一 IP 在不同节点反复通过。

只适合开发联调或单实例离线工具类服务
无法共享状态，不满足分布式一致性要求
重启即清空，不具备持久化兜底能力

Redis 实现令牌桶必须用 EVAL 原子脚本

直接用 INCR + EXPIRE 组合有竞态：两次 Redis 请求之间可能被其他客户端插入，导致超发令牌。gin-vue-admin 的 SetLimitWithTime 就踩了这个坑——它用 TxPipeline 包装，但 pipeline 不保证原子性，只是批量发送。

正确做法是把“读当前令牌数、判断是否够用、扣减/填充、设置过期”全部塞进 Lua 脚本，由 Redis 单线程执行：

local key = KEYS[1]
local limit = tonumber(ARGV[1])
local capacity = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local rate = tonumber(ARGV[4])

local tokens = redis.call("GET", key)
if not tokens then
  redis.call("SET", key, capacity, "EX", 60)
  return 1
end

tokens = tonumber(tokens)
if tokens > 0 then
  redis.call("DECR", key)
  return 1
else
  return 0
end