为什么生产环境Redis限流推荐使用Lua脚本而非事务？-Redis-PHP中文网

Redis限流应优先用Lua脚本而非事务：事务无法实现“读-判-写”原子性，WATCH导致高并发重试、QPS虚高；Lua单线程执行，支持条件判断、一次完成全部逻辑，且集群兼容性更好。

为什么生产环境redis限流推荐使用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 <p> —— 这段代码在Redis端完成“首次访问设过期时间+判断是否超限”，客户端拿到<code>true</code>/<code>false</code>即可直接决策，无歧义。</p><div class="aritcle_card flexRow artxards">
											<div class="artcardd flexRow">
												<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill11046" title="Sentinal Redis"><img
														src="https://img.php.cn/upload/skill/001/246/273/6adaf20dbae7c507.jpg" alt="Sentinal Redis" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
												<div class="aritcle_card_info flexColumn">
													<a rel="nofollow" href="/xiazai/skill11046" title="Sentinal Redis" class="overflowclass">Sentinal Redis</a>
													<p class="overflowclass">监控Redis服务器健康状况、内存、性能及BullMQ队列。检查队列深度、失败任务，分析慢查询并诊断问题。</p>
												</div>
												<a rel="nofollow" href="/xiazai/skill11046" title="Sentinal Redis" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
												</a>
											</div>
										</div><h3>事务和Lua在集群模式下的兼容性差异明显</h3><p>Redis Cluster要求所有key落在同一slot，事务中涉及多个key时必须用<code>{xxx}</code>哈希标签对齐，否则报错<code>CROSSSLOT Keys in request don't hash to the same slot</code>。而Lua脚本若只操作单个key（如限流桶名），完全不受影响；即使需多key，也能通过<code>KEYS[1]</code>统一前缀规避跨slot问题。</p><p>更重要的是，<code>WATCH</code>在Cluster中行为不稳定：某些客户端SDK对<code>MOVED</code>/<code>ASK</code>重定向处理不当，导致WATCH失效却不报错，最终变成“伪原子”。Lua则无此顾虑——只要脚本发给正确的节点，执行就是确定性的。</p><h3>容易被忽略的性能陷阱：事务重试成本远高于Lua阻塞</h3><p>很多人担心Lua脚本执行太久会阻塞Redis主线程，于是倾向用事务“分步扛压”。但现实是：一个简单限流脚本执行通常
</p><p>真正该警惕的是Lua里的耗时操作：<code>for</code>循环上万次、调用<code>redis.call("KEYS")</code>、或在脚本里做复杂浮点运算。这些确实会卡住Redis，但限流脚本本身逻辑极简，几乎不存在这种风险——反而是事务方案更容易因重试逻辑写错，把简单问题搞复杂。</p>