Redis限流应优先用Lua脚本而非事务：事务无法实现“读-判-写”原子性，WATCH导致高并发重试、QPS虚高；Lua单线程执行，支持条件判断、一次完成全部逻辑，且集群兼容性更好。
Redis事务在限流场景下无法保证“读-判-写”原子性
限流的核心逻辑是：读当前计数 → 判断是否超限 → 更新计数。Redis事务（MULTI/EXEC）本身不支持条件跳转，也无法在执行过程中根据中间结果决定后续行为。比如你用GET读到值为99，接着INCR，但这两个命令在事务里只是排队执行，中间没有判断分支——它不会自动拒绝第101次请求。
更关键的是，事务依赖WATCH实现乐观锁，而高并发下多个客户端同时WATCH同一个key，只要有一个抢先EXEC成功，其余全部失败重试。这导致大量无效重试请求打到Redis，QPS虚高、延迟飙升，实际吞吐反而下降。线上压测时常见现象是：目标限流1000 QPS，Redis监控看到3000+ EXEC调用，其中2000+因WATCH失败被丢弃。
Lua脚本天然满足限流的原子性与条件判断需求
Redis单线程执行Lua脚本，整个EVAL过程不可中断。脚本内可以自由使用if、math.max、tonumber等逻辑，把“读令牌数→算新增量→截断上限→判断是否放行→更新状态→返回结果”全部封装在一个调用中。
- 避免竞态：两个请求不会同时读到相同旧值再各自+1
- 减少RTT：一次网络请求完成全部操作，比事务+重试节省至少2–3倍往返
- 可控性更强：可精确返回剩余令牌数、是否放行、预估下次可用时间等信息
示例片段（固定窗口）：
local count = redis.call("INCR", KEYS[1])<br>if count == 1 then redis.call("EXPIRE", KEYS[1], ARGV[1]) end<br>return count <= tonumber(ARGV[2]) —— 这段代码在Redis端完成“首次访问设过期时间+判断是否超限”，客户端拿到true/false即可直接决策，无歧义。
事务和Lua在集群模式下的兼容性差异明显
Redis Cluster要求所有key落在同一slot，事务中涉及多个key时必须用{xxx}哈希标签对齐，否则报错CROSSSLOT Keys in request don't hash to the same slot。而Lua脚本若只操作单个key（如限流桶名），完全不受影响；即使需多key，也能通过KEYS[1]统一前缀规避跨slot问题。
更重要的是，WATCH在Cluster中行为不稳定：某些客户端SDK对MOVED/ASK重定向处理不当，导致WATCH失效却不报错，最终变成“伪原子”。Lua则无此顾虑——只要脚本发给正确的节点，执行就是确定性的。
容易被忽略的性能陷阱：事务重试成本远高于Lua阻塞
很多人担心Lua脚本执行太久会阻塞Redis主线程，于是倾向用事务“分步扛压”。但现实是：一个简单限流脚本执行通常
真正该警惕的是Lua里的耗时操作：for循环上万次、调用redis.call("KEYS")、或在脚本里做复杂浮点运算。这些确实会卡住Redis，但限流脚本本身逻辑极简，几乎不存在这种风险——反而是事务方案更容易因重试逻辑写错，把简单问题搞复杂。
