单靠 Redis 命令无法保证双写缓存原子性，因 SET 和 DEL 是两个独立命令，中间可能被其他客户端插入操作，导致缓存与 DB 不一致；Lua 脚本在服务端单线程原子执行，可规避竞态。
为什么单靠 Redis 命令无法保证双写缓存原子性
因为 SET 和 DEL（或 EXPIRE）是两个独立命令，中间可能被其他客户端插入操作，导致缓存与 DB 状态不一致。网络分区、客户端崩溃、主从复制延迟都会放大这个问题——你发了 SET，但没来得及发 DEL，缓存就脏了。
Lua 脚本在 Redis 服务端原子执行，整个脚本要么全成功，要么全失败（运行时错误除外），天然规避了客户端侧的竞态。注意：不是“事务”，是“单线程串行执行”，所以不用 WATCH 或 MULTI/EXEC。
用 EVAL 执行双写 Lua 脚本的实操要点
典型场景：DB 更新后，同步更新缓存（比如先 SET 新值，再 DEL 旧 key 的关联缓存）。脚本必须把所有依赖 key 显式传入 KEYS，所有参数走 ARGV，否则集群模式下会报 CROSSSLOT Keys in request don't hash to the same slot。
-
EVAL "if redis.call('exists', KEYS[1]) == 1 then redis.call('set', KEYS[2], ARGV[1]); redis.call('del', KEYS[3]); end" 3 cache:old user:1001 cache:new—— 注意KEYS数量要和实际传入一致 - 避免在 Lua 中做耗时操作（如循环大量 key、调用
redis.call('keys', '*')），会阻塞整个 Redis 实例 - 脚本里不要用
return返回大对象，Redis 对 Lua 返回值大小有限制（默认 16MB），超限直接报错ERR Error running script (call to f_...): @user_script: N: user_script: N: too much data returned
缓存失效策略选 DEL 还是 UNLINK？
DEL 是同步删除，时间复杂度取决于 key 类型（O(N) for hash/list/set），大 key 会导致 Redis 卡顿；UNLINK 是异步删除，立即返回，后台线程清理内存，更安全。
但在 Lua 脚本里不能直接用 UNLINK——Redis 6.0+ 才支持，且部分老版本集群代理（如 Twemproxy）会拦截该命令。检查你的环境：redis-cli --version 和 redis-cli info | grep redis_version。
- 生产环境建议统一用
DEL，除非确认所有节点 ≥ 6.0 且无中间件拦截 - 如果用了
UNLINK，脚本中需加版本判断逻辑（不推荐，增加复杂度） - 别在 Lua 里反复
DEL不存在的 key，虽不报错但浪费 CPU
本地调试 Lua 脚本的常见翻车点
直接在 redis-cli 里粘贴脚本容易因换行、引号、空格出错。最稳的方式是用 redis-cli --eval 加载外部文件，并用 --raw 查看原始返回。
- 脚本文件末尾别留空行，
--eval会把最后一行当ARGV解析，导致ERR Error compiling script (new line in a string) - 字符串参数含空格要用单引号包裹：
redis-cli --eval sync.lua cache:user:1001 , 'hello world'，否则空格被截断 - 调试时加
redis.log(redis.LOG_WARNING, 'key='..KEYS[1])，日志会输出到 Redisredis-server控制台（仅开发环境，别上生产）
真正难的不是写对脚本，而是厘清哪些操作必须进 Lua、哪些可以放客户端——比如生成唯一 ID、校验权限、调用外部 API，这些永远不该塞进 Lua。边界划错了，问题会从缓存蔓延到整个服务稳定性。
