redis从节点不执行事务语义，仅逐条执行主节点发送的原始命令；它无事务状态、不识别multi/exec边界、不校验watch或回滚，导致主从数据可能不一致。
从节点只执行命令，不执行事务语义
Redis 从节点在复制过程中，收到的是主节点发来的原始命令（如 SET、INCR、EXEC），而不是“事务块”这个逻辑单元。它不会识别 MULTI 和 EXEC 的边界，也不会维护事务队列或回滚机制——它只是按顺序逐条执行每条命令。
这意味着：即使主节点上一个事务中某条命令因条件失败（比如 WATCH 失效导致 EXEC 返回 nil），该事务最终没生效；但从节点仍会照常执行 EXEC 前面所有已入队的命令（因为这些命令早已被主节点写入 AOF / 复制流），造成主从数据不一致。
主节点事务失败 ≠ 从节点跳过命令
这是最容易误解的一点：事务失败是主节点运行时的逻辑判断结果，而复制层只管“发什么”，不管“是否成功”。常见场景包括：
-
WATCH监控的 key 在MULTI到EXEC之间被其他客户端修改，主节点EXEC返回nil，但之前SET、INCR等命令早已进入复制缓冲区并下发到从节点 - 事务中某条命令语法错误（如
HSET key缺少 field/value），主节点在EXEC时直接报错，但合法命令仍会被执行并复制 - 主节点内存不足或 OOM kill 导致事务中途崩溃，部分命令已落盘或已发往从节点
从节点没有事务上下文和状态机
Redis 单线程模型决定了事务只是客户端请求的“打包协议”，服务端并不为每个客户端维护事务状态。从节点更进一步：它不解析客户端连接、不处理 MULTI 协议帧、不校验命令序列合法性。它只做一件事：repl_baklog 里有什么，就执行什么。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
所以以下行为在从节点上都不存在：
- 事务队列（无
multi标记状态） - WATCH 键监控（无键版本号比对逻辑）
- EXEC 原子性判定（不返回
nil或数组，只执行单条命令） - DISCARD 清空队列（从节点压根没建过队列）
真正影响一致性的是复制粒度，不是事务包装
Redis 主从复制的原子单位是「单条写命令」，不是「一个 EXEC 块」。哪怕你在主节点用 MULTI 包了 10 条命令，只要其中任意一条进了 repl_baklog，它就会被同步过去并执行。这也是为什么官方文档反复强调：Redis 事务不保证跨命令的原子性，也不保证主从间事务级一致性。
如果你依赖多命令强一致（比如扣库存+写日志必须同时成功），不要靠 MULTI/EXEC，而应改用 Lua 脚本——因为脚本在主节点是原子执行的，整个脚本体作为一条命令被复制，从节点也只会执行一次脚本，不会拆解。
