Gin限流必须用Redis而非本地内存，因多实例部署下本地计数器各自独立，4个实例各限100 QPS会导致实际400 QPS击穿后端；Redis凭借单线程原子性与共享存储保障分布式限流生效。
为什么Gin限流必须用Redis而不是本地内存
因为微服务必然多实例部署，本地内存计数器各自为政。比如你启了4个Gin服务实例，每个都按“每分钟100次”限流，实际总流量可能飙到400次——这已经击穿后端了。Redis在这里不是“可选优化”，而是分布式限流的底线要求。它的单线程原子性（INCR、EXPIRE组合或Lua脚本）和共享存储能力，直接决定了限流是否真正生效。
固定窗口 vs 滑动窗口：选错会放大临界问题
固定窗口（如用INCR + EXPIRE）实现简单，但存在“窗口切换瞬间请求洪峰”风险：前一秒末尾+后一秒开头各来100次，实际2秒内200次，却没被拦住。生产环境强烈建议滑动窗口，哪怕多写几行Lua脚本。Gin中间件里调用Redis时，别直接拼key，要按时间粒度动态生成，例如：
KEYS[1] = "limit:ip:" .. ARGV[1] .. ":" .. math.floor(tonumber(ARGV[2]) / 60) * 60
常见坑：
- 没校验
ARGV[2]（当前时间戳）是否合法，导致key计算错乱 - 用
SETNX代替INCR，漏掉并发请求的累加语义 - ttl设成固定值（如60秒），但窗口是滑动的，必须随时间戳动态计算过期时间
Gin中间件里调Redis的三个硬性约束
限流中间件不是“加个Redis client就行”，它必须满足三件事才能上线：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
context.Context透传超时控制：Redis命令必须带ctx, timeout，避免一个卡死的Redis拖垮整个HTTP连接 - 失败降级开关：当Redis不可用时，不能直接panic或500，应走预设的宽松策略（如允许10倍阈值）或跳过限流，否则雪崩从网关开始
- Key命名必须含维度标识：比如
"limit:phone:" .. phone、"limit:route:" .. c.FullPath()，否则不同限流规则互相覆盖
别在中间件里做redis.NewClient()，复用全局client实例；也别把time.Now()塞进Lua脚本——Redis服务器时间和应用服务器时间可能漂移，一律传入毫秒级时间戳由Lua处理。
令牌桶算法在Gin中用Redis实现的取舍点
Spring Cloud Gateway默认用令牌桶，但Gin生态里多数人直接上固定窗口，因为简单。真要用令牌桶，注意两点：
- 不要自己手写“取令牌→sleep→放回”的逻辑，那不是原子操作；必须用Lua脚本一次性完成“读剩余令牌→判断→decr→返回结果”
- 令牌生成速率（rate）和桶容量（burst）得存两份：一份在Redis key value里（当前令牌数），一份在配置中心或内存常量里（避免每次读配置）
性能敏感场景下，令牌桶比滑动窗口更耗Redis QPS——每次请求都要一次EVAL，而滑动窗口可用INCR + EXPIRE组合应付大部分情况。除非你明确需要应对突发流量（比如秒杀），否则别为“听起来高级”而选令牌桶。
Redis连接池大小、超时时间、重试次数这些参数，在Gin服务启动时就该固化，别让它们变成线上故障的变量。限流本身是保护手段，但如果它因Redis抖动而集体失效或误判，反而成了最危险的单点。
