关于Redis静态窗口限流中直接使用事务化INCR+EXPIRE组合命令的疑问

嘿，这个问题问得太接地气了——我刚用Redis做限流的时候也纠结过一模一样的问题，甚至还在测试环境踩过坑，来给你唠明白这里面的门道。

首先得肯定你的思路：你想的MULTI INCR limit:key1:min12 EXPIRE limit:key1:min12 60 NX EXEC这个事务写法，核心是想把自增计数和设置过期时间做成原子操作，避免出现“键被创建了但没设过期，导致永久留在Redis里”的坑，这个方向完全是对的。

那为啥网上很多例子都是先GET再INCR呢？大多是因为那些教程面向的是入门学习者，先把限流的逻辑脉络讲清楚——“先看当前计数有没有超过阈值，再决定要不要增加”，但这种写法在高并发场景下有致命的竞态问题：比如两个请求同时GET到计数是99，都判断没到100的阈值，然后各自执行INCR，最后计数变成100，直接突破了限流限制，这在生产环境里绝对是不能忍的。

再回到你的问题：直接用事务化的INCR+EXPIRE NX有啥风险？得拆分来看：

• 兼容性风险：EXPIRE命令的NX参数是Redis 7.0版本才新增的，它的作用是“只有当键没有设置过期时间时，才执行过期设置”。如果你的生产环境Redis版本低于7.0，这个语法直接报错，根本跑不起来。这也是为啥很多老项目不会这么写的原因之一。
• 事务本身的局限性：Redis的事务是“批量入队、一次性执行”，但它不支持条件分支判断。比如你没法在事务里做“如果自增后的值是1，就设置过期时间”这种逻辑——虽然NX参数能帮你一部分，但如果你的键命名不是严格按时间窗口（比如不用min12这种后缀，而是靠过期时间划分窗口），那这个写法就会出问题。

那有没有更通用、更靠谱的方案？当然有，用Lua脚本来实现原子操作，这也是生产环境里最常用的方式，不管Redis版本高低都能跑：

local current_count = redis.call("INCR", KEYS[1])
if current_count == 1 then
    -- 第一次创建这个键，设置过期时间
    redis.call("EXPIRE", KEYS[1], ARGV[1])
end
return current_count

这个脚本的逻辑很简单：自增计数，如果是第一次创建（返回1），就给键设置过期时间，整个过程是原子的，完全不会有竞态或者漏设过期的问题。

最后再补一句：不管你用事务还是Lua脚本，静态窗口限流本身有个固有问题——在窗口的边界时刻（比如第59秒到第60秒），可能会出现“前一个窗口最后一秒进来大量请求，后一个窗口刚开又进来大量请求”，导致实际请求量远超阈值。如果你的业务对这个场景敏感，可能得考虑滑动窗口、令牌桶这些更复杂的限流算法，但这就是另一个话题了。

内容来源于stack exchange