关于“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的响应速度。
