Redis Lua脚本的“原子性”指单线程内完整连续执行、不可中断，而非ACID事务的全成功或全失败；出错时立即终止，不回滚已执行命令，需手动校验、捕获或补偿。
Redis Lua脚本执行失败不会自动回滚，这不是bug，是设计使然——它压根没打算提供数据库级别的ACID原子性。
Redis Lua的“原子性”到底指什么
这个“原子性”只有一层含义：脚本在单线程中被完整、连续地执行，期间不会有其他客户端命令插入。它保证的是EVAL调用的执行过程不可中断，不是“全成功或全失败”的事务语义。
换句话说，只要Redis开始跑你的Lua脚本，就一定会把它从头到尾跑完（或卡在某处报错停住），但已执行的redis.call("SET", "a", "1")不会因为后面redis.call("INCR", "b")报(error) ERR value is not an integer而撤销。
- 这是由Redis单线程模型 + Lua嵌入式执行机制决定的，没有事务日志、没有undo log
- 和关系型数据库的
BEGIN/COMMIT/ROLLBACK完全不是一回事 - 官方文档明确说：“Lua scripts are executed atomically, but there is no rollback.”
Lua脚本出错时，后续命令是否还执行
不执行。这和Redis原生事务MULTI/EXEC行为相反。
MULTI事务里某条命令失败（比如对string执行LPUSH），错误会被记录，但EXEC仍会继续执行队列里剩下的命令；而Lua脚本一旦在某行抛出未捕获异常（如redis.call返回错误、或nil参与运算），整个脚本立即终止，后面的redis.call根本不会触发。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 错误示例：
local a = redis.call("GET", "missing"); return a + 1→a是nil，加法报错，脚本退出，后续操作不执行 - 想让错误不中断执行？得用
pcall手动包裹可能失败的操作 - 注意：
pcall捕获的是Lua运行时错误，不是Redis命令返回的error_reply，后者需显式检查
如何在Lua里做“类回滚”或补偿逻辑
没有自动回滚，就得自己写防御和兜底。常见手段有三类：
- 前置校验：在真正修改数据前，先用
redis.call("EXISTS")、redis.call("TYPE")确认key存在且类型正确 - 错误捕获：对关键步骤用
pcall(redis.call, "INCR", "counter")，根据返回值决定是否跳过后续逻辑或清理中间状态 - 手动补偿：比如先
SET temp:lock 1 EX 10加锁，再操作主数据；若中途失败，可在脚本末尾DEL temp:lock释放，或靠过期自动清理
特别注意：不要在Lua里依赖redis.error_reply()来“假装回滚”，它只是向客户端返回错误，已发生的写操作照旧生效。
集群环境下Lua脚本的隐性风险
在Redis Cluster中，Lua脚本的“原子性”会进一步打折——它甚至不能跨slot安全执行。
- 如果脚本里同时操作
user:1001和order:2002，而它们哈希后落在不同节点，Redis直接报CROSSSLOT Keys in request don't hash to the same slot - 解决办法只有加哈希标签，比如改成
{user}:1001和{user}:2002，强制路由到同一slot - 更隐蔽的问题是：脚本在主节点执行成功，但复制到从节点时因超时或网络中断失败，导致主从数据短暂不一致
- 所有这些，都不会触发任何回滚，也不会报错给客户端——你得靠监控
info replication里的lag和repl_backlog_active去发现
真正容易被忽略的，是脚本执行时间本身：超过lua-time-limit（默认5秒）会被强制中断，此时已执行的部分无法撤回，中断点也不可控——它可能卡在redis.call半途中，也可能卡在纯Lua循环里。
