Redis用Lua实现缓存双写原子性

Redis双写缓存场景下，仅靠独立的SET和DEL命令无法保证原子性，易因并发插入、网络异常或客户端崩溃导致缓存与数据库不一致；而Lua脚本凭借Redis服务端单线程串行执行的特性，能将多步操作封装为不可分割的整体，从根本上规避竞态条件——但需严格遵循KEYS/ARGV传参规范、规避大key阻塞、慎选DEL/UNLINK、规范调试流程，并清醒划清Lua边界（如绝不嵌入IO或业务逻辑），方能在高性能与强一致性之间取得关键平衡。

为什么单靠 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])，日志会输出到 Redis redis-server 控制台（仅开发环境，别上生产）

真正难的不是写对脚本，而是厘清哪些操作必须进 Lua、哪些可以放客户端——比如生成唯一 ID、校验权限、调用外部 API，这些永远不该塞进 Lua。边界划错了，问题会从缓存蔓延到整个服务稳定性。

到这里，我们也就讲完了《Redis用Lua实现缓存双写原子性》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！