Redis限流关键在维度设计、窗口对齐、原子性保障三点；必须用Lua脚本将计数、判断、过期设置原子化执行，否则INCR+EXPIRE分步操作会因竞态导致超限或误拒。
直接说结论：Redis限流不是“加个RedisRateLimiter就完事”，关键在维度设计、窗口对齐、原子性保障这三点。配错参数或忽略时钟漂移，限流可能形同虚设，甚至误杀正常流量。
Redis限流必须用Lua脚本保证原子性
INCR + EXPIRE 分两步走，在高并发下必然出问题：两个请求同时读到计数为9，各自+1后都写入10，结果本该拒绝的第11次请求被放行。这是经典竞态条件。
必须用 Lua 脚本把计数、判断、设置过期时间打包成一个原子操作。Spring Cloud Gateway 的 RedisRateLimiter 内部就是靠 Lua 实现的；自己手写 AOP 限流时，也得封装类似逻辑：
local key = KEYS[1]
local count = tonumber(ARGV[1])
local expire = tonumber(ARGV[2])
local current = redis.call('incr', key)
if current == 1 then
redis.call('expire', key, expire)
end
if current > count then
return 0
end
return 1
注意：KEYS[1] 必须是带业务维度的完整 key（如 rate:ip:192.168.1.100），不能只传 rate: 这种前缀。
固定窗口 vs 滑动窗口：别被“高级”二字忽悠
固定窗口（INCR + EXPIRE）实现最简单，但存在临界突刺问题——比如窗口是 60 秒，第 59 秒来了 100 个请求，第 60 秒又来了 100 个，实际峰值是 200 QPS，远超你配置的 100。
滑动窗口能解决这个问题，但 Redis 原生不支持，得用 ZSET 存时间戳 + 请求 ID，每次请求要 ZREMRANGEBYSCORE + ZCARD + ZADD，耗时比固定窗口高 3–5 倍。真实压测中，单节点 QPS 超过 5000 后，滑动窗口的 Redis CPU 就开始明显上升。
建议按场景选：
- 网关层限流（如 Spring Cloud Gateway）：优先用
RedisRateLimiter默认的令牌桶，它内部已做滑动平滑处理，且支持replenishRate和burstCapacity两个参数灵活控突发 - 代码层注解限流（如
@RateLimit）：如果业务能容忍短时突刺（比如后台管理接口），直接用固定窗口更稳；若必须精确控每秒（如支付回调验签），再上滑动窗口
Key 设计决定限流是否真正生效
限流效果好不好，一半看算法，一半看 key 怎么拼。常见错误有：
- 只按
ip限，但用户走代理或 NAT，多个真实用户共享一个 IP，导致大面积误拒 - 只按
uri限，没区分参数，/order/{id}全部算同一个 key，根本起不到保护单个订单详情的作用 - 拼 key 时用了未校验的参数，比如
userId是前端传的，没做合法性检查，攻击者可伪造任意userId绕过限制
推荐组合策略：
- 高危接口（如登录、下单）：用
ip:userId:uri三元组，既防刷又保体验 - 开放 API：强制要求
app_id+access_token校验后再生成 key，避免 token 泄露后被滥用 - 微信回调类接口：key 中必须包含
appid和event_type，因为微信不同事件频控阈值完全不同
burstCapacity 和 replenishRate 参数怎么调才不翻车
这两个参数只在令牌桶算法里出现，但很多人配完就忘——replenishRate 是每秒补多少令牌，burstCapacity 是桶最大容量。它们共同决定“允许多大程度的突发”。
典型翻车现场：
-
replenishRate=10，burstCapacity=10：相当于每秒最多放行 10 个请求，完全没突发余量，和固定窗口无异 -
replenishRate=10，burstCapacity=100：桶初始满，瞬间能扛 100 个请求，但之后每秒只能补 10 个。如果下游服务实际吞吐只有 30 QPS，这 100 个请求打过去照样雪崩
调参口诀：
- 先看下游服务真实稳定吞吐（比如压测得出商品服务单实例 40 QPS 是极限），设
replenishRate为这个值的 80%（即 32） - 再看业务是否允许短时冲击：秒杀类可设
burstCapacity = replenishRate × 3；普通查询类建议 ≤replenishRate × 1.5 - 上线后紧盯 Redis 的
latency和网关429错误率，如果 429 突增但下游没压力，说明burstCapacity太小；如果下游 CPU 打满但 429 很少，说明replenishRate太大
最易被忽略的一点：Redis 集群环境下，Lua 脚本里的 key 必须落在同一个 slot，否则会报 CROSSSLOT Keys in request don't hash to the same slot。所以 key 命名时务必用 {rate:ip:192.168.1.100} 这种带大括号的方式，让 Redis 只按花括号内内容哈希。
