双活redis下lua脚本无法保证跨机房一致性，仅保障单实例内原子性；需放弃强一致幻想，改用带时间戳/lww/g-counter等可合并crdt逻辑，并由上层负责最终合并。
双活机房下 Redis 无法靠单实例原子性兜底，Lua 脚本本身不解决跨机房冲突——它只保证「单个 Redis 实例内」的原子执行。想用 Lua 实现类 CRDT（Conflict-Free Replicated Data Type）语义，必须放弃「强一致脚本」幻想，转为设计可合并、带版本/时间戳、无依赖顺序的更新逻辑。
为什么 EVAL 在双活 Redis 下天然失效
双活架构中，两个机房的 Redis 实例各自独立接受写入，数据通过异步复制同步。此时：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- EVAL 脚本在 A 机房执行成功，B 机房可能还没收到该脚本的任何命令，更别说执行；
- 即使两边都执行了同一段 Lua 脚本，只要输入参数（如
ARGV）或初始状态（如GET结果）不同，输出必然不同，且无法自动协调； - Redis 不提供跨实例的脚本哈希同步机制，
EVALSHA在 B 机房大概率报(error) NOSCRIPT No matching script； - CRDT 的核心是“最后写入胜出”（LWW）、“向量时钟”或“增量合并”，而 Lua 脚本里无法访问对端实例的状态或时钟。
能用 Lua 模拟的轻量级 CRDT 原子操作
若双活层已由中间件（如 Redis Proxy 或自研同步网关）保障最终一致性，可在单实例内用 Lua 封装「幂等 + 可合并」的更新，例如 LWW-Register 或 G-Counter 的本地代理：
- 用
HSET存储带时间戳的值：HSET user:123 lww_val "hello" lww_ts "1748453572000"，Lua 中用redis.call("HGET", KEYS[1], "lww_ts")比较并覆盖； - 实现本地 G-Counter：每个机房独占一个计数器字段（如
cnt_a/cnt_b），Lua 脚本只增自己字段，合并逻辑交由读取方或同步层做MAX(cnt_a, cnt_b)； - 禁止在脚本里调用
GET后再SET全局值——这仍是“读-改-写”，不是 CRDT；必须把「当前值」作为输入（ARGV）传入，脚本只做纯函数式转换； - 所有 key 必须显式声明在
KEYS数组，否则集群模式路由失败；双活场景下建议 key 命名带机房标识，如stock:sh:123、stock:bj:123，避免键冲突。
真正落地时最容易被忽略的三点
双活 + Lua 的组合陷阱不在语法，而在系统边界认知错位：
-
redis.call()返回的是本实例当前状态，不是双活视图——你写的“判断库存是否充足”脚本，在 A 机房返回 true，B 机房同一秒也可能返回 true，超卖照旧； - 别把
SCRIPT LOAD当同步手段：它不会推送到对端机房，重启后脚本丢失是常态，应将脚本内容与版本号一起写入配置中心，启动时主动EVAL加载； - CRDT 的“无冲突”指合并结果确定、无需人工干预，不是“不发生并发写入”。Lua 脚本只能帮你把本地写入变成确定性操作，但合并动作必须发生在应用层、Proxy 层或专用同步服务中，Redis 本身不参与。
