Redis Lua脚本不能实现真正的分布式事务回滚，仅能通过条件化原子写入预防性拒绝，失败后需业务层设计补偿机制。
Redis Lua脚本能保证原子性，但不能替代数据库事务
Redis 本身不支持跨 key 的分布式事务（如 MySQL 的 BEGIN/COMMIT），EVAL 执行的 Lua 脚本虽在服务端原子执行，但仅限于 Redis 内部操作——它无法自动回滚已发往下游服务（如 HTTP 调用、MQ 发送、DB 写入）的副作用。所谓“补偿机制”，本质是手动设计可逆操作 + 状态记录，Lua 脚本只负责其中最脆弱的一环：日志写入与状态标记的原子性。
常见错误现象：(error) ERR Error running script (call to f_...): @user_script:12: user_script:12: attempt to concatenate a nil value——脚本里没校验 redis.call("GET", ...) 返回值，空值参与字符串拼接；或用 redis.pcall 捕获错误后未处理返回结构，导致后续逻辑崩掉。
- 必须用
redis.call()而非redis.pcall()做关键写入（如记日志、改状态），否则失败会静默吞掉错误 - 所有外部依赖（DB、RPC、MQ）的操作必须在 Lua 外完成，且需配套幂等 ID 和最终一致性校验
- 脚本内禁止耗时操作（如循环 10000 次、调用
redis.call("KEYS", "*")），否则阻塞整个 Redis 实例
用 Lua 脚本原子写入补偿日志并预置回滚标记
核心思路：把「操作意图」和「回滚指令」一起存进一个 compensate_log:{biz_id} 结构，用 HSET 一次写入多个字段，利用 Redis Hash 的单 key 原子性避免日志残缺。字段包括：status（pending/committed/compensated）、rollback_cmd（如 DEL user:1001 或 HINCRBY balance:1001 amount -100）、created_at、expire_at（建议设为业务超时时间 + 24h，防误删）。
示例脚本（保存为 log_and_mark.lua）：
local biz_id = KEYS[1]
local status = ARGV[1] -- "pending"
local rollback_cmd = ARGV[2] -- "HINCRBY balance:1001 amount -100"
local expire_sec = tonumber(ARGV[3]) or 86400
<p>redis.call("HSET", "compensate_log:"..biz_id,
"status", status,
"rollback_cmd", rollback_cmd,
"created_at", tostring(tonumber(redis.call("TIME")[1])),
"expire_at", tostring(tonumber(redis.call("TIME")[1]) + expire_sec)
)
redis.call("EXPIRE", "compensate_log:"..biz_id, expire_sec)
return 1调用方式：redis-cli --eval log_and_mark.lua 'order:789' , 'pending' 'HINCRBY balance:1001 amount -100' 86400
-
KEYS[1]必须是业务唯一 ID（如订单号），不可用随机 UUID，否则无法关联查询 - 不要在脚本里拼接用户输入的
rollback_cmd，需由上层严格白名单校验（只允许HINCRBY/DEL/HSET等有限命令） - 避免用
redis.call("TIME")做精确时间比对，不同 Redis 节点时钟可能漂移，仅用于相对时间戳
用 Lua 实现安全的条件回滚（避免重复执行）
回滚不是无脑执行 rollback_cmd，必须先检查当前状态是否允许回滚——比如已成功提交（status == "committed"）就不该再删数据。真正的回滚脚本要三步：读状态 → 判定是否可执行 → 更新状态 + 执行指令。这三步必须在一个 EVAL 中完成，否则竞态下可能双写。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
示例脚本（safe_compensate.lua）：
local key = "compensate_log:"..KEYS[1]
local status = redis.call("HGET", key, "status")
<p>if status == "pending" then
local cmd = redis.call("HGET", key, "rollback_cmd")
if not cmd or cmd == "" then return {err="no rollback_cmd"} end</p><p>-- 执行回滚指令（仅支持简单命令，生产中建议转成预编译函数）
local cmd_parts = {}
for part in string.gmatch(cmd, "[^%s]+") do table.insert(cmd_parts, part) end
local res = redis.call(unpack(cmd_parts))</p><p>redis.call("HSET", key, "status", "compensated", "compensated_at", tostring(tonumber(redis.call("TIME")[1])))
return {ok=true, result=res}
else
return {err="invalid status: "..tostring(status)}
end调用：redis-cli --eval safe_compensate.lua 'order:789'
- 脚本里用
string.gmatch解析命令是临时方案，高并发场景应提前将合法回滚指令注册为 Redis 函数（Redis 7.0+）或由应用层解析后调用对应redis.call - 返回值必须检查
err字段，很多客户端库会把 Lua 返回的 table 当成字符串处理，导致判空失效 - 别依赖
EXPIRE自动清理日志——过期 key 仍可能被SCAN扫到，回滚后主动DEL compensate_log:{biz_id}更稳妥
补偿任务如何发现待处理日志并触发回滚
Redis 不提供“过期通知”或“变更监听”给 Lua 脚本，所以补偿调度必须由外部服务承担。典型做法是：独立进程定时（如每 30 秒）用 SCAN 扫描 compensate_log:*，查出 status == "pending" 且 created_at 超过阈值（如 5 分钟）的记录，再调用上面的 safe_compensate.lua。
关键细节：
-
SCAN不能用KEYS，大数据量下会阻塞 Redis；游标要分页处理，单次最多SCAN 1000 MATCH compensate_log:* COUNT 100 - 扫描结果需按
created_at排序（用HGET逐个取），避免新日志被老日志挤出窗口 - 补偿任务自身必须幂等：同一条日志被扫到多次，重复调用
safe_compensate.lua应返回相同结果（靠脚本内status判断实现） - 网络分区时，补偿任务可能失联，需配合 Redis 的
PUBLISH/PSUBSCRIBE或外部消息队列做最终触发保障
真正难的从来不是写几行 Lua，而是界定清楚哪部分交给 Redis 原子性兜底，哪部分必须靠外部服务重试+幂等+监控补位。日志字段设计错一位、状态机漏一个分支、扫描间隔设长一秒，都可能导致补偿延迟数小时甚至永久丢失。
