正确做法是仅在incr返回1时执行expire设60秒ttl，避免重复刷新导致永不过期；因set的nx无法同时自增，而incr ex仅对新key生效，故incr+expire组合最可靠。
用 INCR + EXPIRE 实现每分钟限流
redis 的 INCR 和 EXPIRE 组合是 IP 限流最轻量、最常用的方式，核心逻辑是：对每个 IP 做计数器，首次访问时设 TTL（比如 60 秒），后续请求只 INCR，不重复设过期时间。
常见错误是每次请求都执行 EXPIRE，导致 TTL 不断刷新，实际变成“只要持续请求就永不过期”。正确做法是只在 INCR 返回 1（即 key 刚创建）时设 TTL。
- 用
INCR ip:192.168.1.100增加计数，返回值即当前请求数 - 若返回 1，立刻执行
EXPIRE ip:192.168.1.100 60 - 检查返回值是否 > 限流阈值（如 100），超过则拒绝请求
- 注意：
INCR对不存在的 key 会自动初始化为 0 再 +1，所以返回 1 表示“这是该 IP 本周期第一条请求”
为什么不用 SET 的 XX/NX 参数？
SET key value EX 60 NX 看似能原子化创建带过期的 key，但它无法同时完成“创建 + 自增”，而限流必须支持多次递增。单独用 NX 只能设初值，后续 INCR 又得再处理 TTL，反而破坏原子性。
更关键的是：Redis 6.2+ 虽支持 INCR 的 EX 选项（如 INCR key EX 60），但该功能仅在 key 不存在时生效；一旦 key 存在，INCR 就忽略 TTL 参数——这意味着你无法靠一条命令保证“存在即续期、不存在即新建并设 TTL”。
- 老版本（INCR EX，必须拆成两步
- 新版本用
INCR key EX 60时，若 key 已存在，TTL 不变，可能让上一周期残留的 key 持续生效 - 真正可靠的原子写法仍是
INCR后判断返回值，再条件执行EXPIRE
并发场景下 INCR 和 EXPIRE 不是原子操作，怎么防竞态？
两个请求几乎同时到达，都看到 key 不存在、都 INCR 得到 1、都执行 EXPIRE——这没问题，重复 EXPIRE 不影响结果。真正要防的是：第一个请求 INCR 后还没来得及 EXPIRE，第二个请求又 INCR 了，此时 key 无 TTL，会永久残留。
解决方案是改用 Lua 脚本把判断、自增、设 TTL 锁死在服务端一次执行：
local current = redis.call("INCR", KEYS[1]) if current == 1 then redis.call("EXPIRE", KEYS[1], ARGV[1]) end return current调用时传入 key（如 ip:192.168.1.100）和 TTL（如 60）。这样无论多少并发，每个 IP 的首次请求一定绑上 TTL，后续只是安全自增。
- Lua 脚本在 Redis 中是原子执行的，无需担心中间状态被其他请求读取
- 别用
EVALSHA缓存脚本哈希却忘了传参顺序，参数错位会导致 TTL 设成 0 或 key 名混乱 - 如果业务已用 pipeline 批量发命令，注意 Lua 脚本不能和其他命令混在同一个 pipeline 里原子执行
限流后怎么快速清理无效 key？
IP 限流 key 生命周期短，但突发流量可能产生大量 key（比如 10 万 IP 各触发一次），而 Redis 的惰性删除 + 定期抽样删除机制，在高负载下可能让过期 key 残留较久，占用内存。
不要主动扫 KEYS ip:* ——这个命令会阻塞主线程，线上禁用。也不建议用 SCAN 配合 TTL 逐个删，效率低且可能漏删。
- 真正有效的做法是：依赖 Redis 自身的过期淘汰策略，确保
maxmemory-policy配置为allkeys-lru或volatile-lru（推荐后者，只针对带过期的 key） - 如果观察到
expired_keys监控指标持续升高，说明过期 key 删除不及时，可临时调大hz参数（如从默认 10 改为 100），加快 Redis 主动清理频率 - 更彻底的预防是：在应用层控制 key 命名粒度，比如按“IP+接口路径”分 key（
ip:192.168.1.100:/login），避免一个 IP 刷多个接口时互相干扰，也减少单 key 过热
限流逻辑越靠近接入层（Nginx/OpenResty/网关）越好，别全压给 Redis；而 Redis 里那几行 Lua，关键不在多 fancy，而在每一步的条件分支是否覆盖了 key 存在性、返回值边界、TTL 生效时机这些细节。