Redis Lua脚本原子性保证与单线程阻塞机制

关于“Redis执行Lua脚本能保证原子性”这一说法，其实很容易引发理解偏差。不少人直觉上认为Redis内部存在锁机制，或像关系数据库那样支持事务回滚。但实际上，两者都不是。真相非常直接，且富有Redis特色：它只是在主线程中以独占式、阻塞式的方式，将整个脚本一口气执行完毕。在此期间，其他所有客户端的请求都必须排队等待，无法中途插入。

为什么单线程执行就等于原子性

背后的逻辑其实很直观。Redis的主线程采用典型的事件循环模型，所有命令都必须排队等待调度。当一个EVAL脚本进入后：

• 脚本会完整加载进Lua解释器，其中的redis.call()调用走的是内部执行队列，无需再次解析和排队。
• 主线程在此期间绝不会分心去处理其他客户端发来的GET、INCR或SET请求。
• 这样一来，脚本内的“读取-计算-写入”三步操作对外界而言就是“不可见的”。例如，脚本刚GET到一个值，准备基于该值继续计算时，不必担心其他客户端中途修改该值——这正是原子性的核心。
• 另外有个容易被忽略的细节：即使脚本执行过程中网络断开，它也会在服务器上自行完成执行。但如果脚本执行超时（默认5秒），Redis只会发出警告，不会主动终止它，需要手动发送SCRIPT KILL命令。

KEYS 和 ARGV 的声明为什么影响集群可用性

另一个常见问题是：在Redis集群环境下，Lua脚本操作的所有key必须属于同一个slot。为什么官方文档反复强调使用KEYS[1]这样的形式？因为Redis在脚本启动前就能静态分析出脚本涉及的key，从而提前校验它们是否位于同一slot。但如果脚本中动态拼接key名，问题就会显现。

• ✅ 正确写法：redis.call("GET", KEYS[1]) —— 这样Redis可以提前校验slot，确保集群兼容。
• ❌ 错误写法：local key = "user:" .. ARGV[1]; redis.call("GET", key) —— 动态生成的key，Redis无法预知其所属slot，集群模式下会直接报错 CROSSSLOT Keys in request don't hash to the same slot。
• 牢记一点：ARGV只能用来传递纯参数，切勿用它构造key。如果脚本需要操作多个key，则必须将所有key显式列在KEYS数组里。

脚本出错时到底会不会回滚

这是另一个普遍存在的误解。Lua脚本的“原子性”仅意味着执行过程不会被其他请求打断，但它并不提供任何回滚能力。脚本内部已经成功执行的redis.call()命令，一旦写入数据就永久生效，不会有任何“撤销”操作。

• 举例：假设脚本先执行 redis.call("SET", "a", "1")，再执行 redis.call("INCR", "a")。如果第二行因类型错误失败（例如a的值不是数字），那么第一行SET命令写入的“a”=“1”会依然保留，不会自动回滚到执行前的状态。
• 若想在出错时“模拟”回滚，就需要自行编写逻辑：用 pcall() 包裹关键操作，在捕获到错误后手动调用 redis.call("DEL", ...) 来清理状态。
• 此外，你还可以主动使用 redis.error_reply() 抛出错误并中断脚本。但请注意，这只能阻止后续命令的执行，之前已成功写入的命令仍是不可逆的。

什么时候该用 Lua 脚本而不是 MULTI/EXEC

在业务场景中，判断是否必须使用Lua脚本的核心标准是：你的逻辑是否形成一个需要“读取-判断-写入”的闭环，且在这个闭环过程中，任何中间状态都不能被其他客户端看到或修改。MULTI/EXEC本质上只是将一些命令打包执行，并不能提供这种真正的原子性隔离。

• 适合Lua的场景：典型的秒杀扣库存（先查余量，再判断并减库存）、分布式限流器（计数和过期时间需要同步设置）、以及需要替代SETNX的复杂条件操作。
• 不适合Lua的场景：例如仅需按顺序向多个key写入数据，此时使用pipeline效率更高、更轻量；或者需要花大量时间遍历大规模key，这种操作会长时间阻塞整个实例，最好将遍历逻辑拆分到客户端处理。
• 重要提醒：Lua脚本运行在沙箱中，无法调用外部网络或文件系统，也不能使用os.time()等非沙箱函数，否则会报 attempt to call a nil value 错误。

最后，很多人容易忽略的关键点是：所谓的“原子性”仅仅覆盖了脚本中通过redis.call()调用的Redis命令。脚本内部自身的计算逻辑，例如字符串处理、循环等，这些操作本身并不被保护，它们同样会阻塞主线程。不过它们不会导致数据损坏，更多时候只是单纯地拖慢Redis的响应速度。