Redis 事务深度总结与技术选型指南

Redis 事务（由 MULTI、EXEC、WATCH、DISCARD 构成）的设计哲学与传统关系型数据库（如 MySQL）截然不同。它放弃了复杂的强一致性和回滚机制，转而追求极致的单线程执行效率和基于乐观锁的并发控制。

要想真正掌握 Redis 事务，必须剥离 MySQL 的固有思维，从 Redis 自身的“命令队列”与“单线程模型”出发。以下是针对其 ACI（原子性、一致性、隔离性）特性在不同故障阶段的详细剖析，以及与 Lua 脚本的工程化选型对比。

一、 Redis 事务的 ACID 特性深度拆解

在传统数据库中，ACID 是一个整体的强契约；但在 Redis 中，ACID 的实现是“分化”且“有条件”的。持久性（Durability）完全取决于 Redis 的持久化策略（AOF/RDB），与事务本身机制无关，因此主要聚焦于 ACI。

阶段 1：命令入队时报错（语法错误 / 命令不存在）

场景描述： 客户端在发送 MULTI 后，输入了拼写错误的命令（如 SETT a 1）或参数数量不对的命令。
处理机制： Redis 在将命令放入内存队列时，会进行前置的语法校验。一旦发现错误，会向客户端返回 EXECABORT，并将该事务标记为失败。当客户端最终调用 EXEC 时，Redis 会拒绝执行队列中的所有命令，直接清空队列。

• 原子性 (Atomicity)：完美保证。 事务被整体放弃，没有产生任何“部分执行”的中间状态。
• 一致性 (Consistency)：完美保证。 数据库的状态保持在 MULTI 之前的原貌，没有任何脏数据写入。
• 隔离性 (Isolation)：天然满足。 由于命令未实质执行，不涉及对共享数据的并发争抢。

阶段 2：实际执行时报错（运行时错误）

场景描述： 语法完全正确，命令成功入队（返回 QUEUED）。但在 EXEC 触发后，Redis 实际执行命令时发生了类型不匹配（例如对一个 String 类型的 Key 执了 HSET 操作）。
处理机制： 这是 Redis 事务最具争议的设计——不支持回滚（No Rollback）。Redis 会在日志中记录错误，并继续执行队列中剩余的合法命令。

• 原子性 (Atomicity)：不满足。 事务出现了“部分成功、部分失败”的断裂状态，打破了传统意义上“要么全做、要么全不做”的原子性底线。
• 一致性 (Consistency)：物理一致，逻辑不一致。
  • 物理层面： 数据库引擎没有崩溃，底层数据结构依然合法，Redis 认为自己是一致的。
  • 业务逻辑层面： 数据可能停留在半成品的错误状态（如扣了库存但没生成订单），业务一致性被打破。修复这种不一致需要开发者在应用层进行补偿。
• 隔离性 (Isolation)：完全保证。 Redis 处理 EXEC 时是单线程排他执行的，在这批命令执行完毕前，其他任何客户端的请求都必须在外部排队，不会产生并发干扰。

阶段 3：EXEC 命令执行时实例故障（宕机 / 断电）

场景描述： 事务包含 10 条命令，Redis 刚执行完前 5 条，服务器突然断电或进程崩溃。
处理机制： 这种灾难恢复场景的 ACI 完全依赖于底层的持久化配置。

• 如果使用 RDB： 事务执行中途不会触发快照，重启后数据恢复到上一个快照点，本次事务的所有修改全部丢失。

• 如果使用 AOF： AOF 日志可能只记录了事务的前 5 条命令。重启时，Redis 会检测到 AOF 文件末尾的事务不完整，从而拒绝启动。

• 原子性 (A) 与 一致性 ©：依靠工具修复保证。 开发者必须使用 redis-check-aof 工具截断 AOF 文件中不完整的事务日志。修复后重启，系统相当于回退到了该事务执行前的状态，从而侧面保证了原子性和一致性。

---

二、 Redis 事务 (WATCH 机制) vs Lua 脚本

在工程实践中，为了弥补 Redis 事务逻辑处理能力的缺失，引入了 Lua 脚本。两者代表了完全不同的并发控制哲学。

1. 核心机制对比

维度	Redis 事务 (WATCH + MULTI/EXEC)	Lua 脚本 (EVAL)
执行位置	逻辑判断在客户端，执行在服务端。	逻辑判断与执行全部在服务端封闭完成。
并发控制机制	乐观锁 (OCC)：执行前校验 Key 是否被改动。	隐式排他锁：脚本执行期间，整个 Redis 拒绝其他请求。
网络开销 (RTT)	高：需要多次往返发送 WATCH、MULTI、具体命令及 EXEC。	低：一次网络传输将整个脚本发送并获取结果。
原子性保障	弱（运行时报错不回滚，冲突则直接失效取消）。	强：脚本本身作为一个原子指令流执行。
对中间态的依赖	强：需要先将数据 GET 到客户端内存中进行判断。	弱：直接在内存中计算，无需将中间结果传回客户端。

2. 深层差异：乐观锁的“重试风暴”

WATCH 机制的核心是 CLIENT_DIRTY_CAS 标记。它允许多个客户端同时读取数据，只在最后 EXEC 瞬间进行冲突校验。

• 优点： 在低并发、冲突极少的场景下，由于没有真实的锁等待，吞吐量极高。
• 致命缺陷： 在高并发写冲突（如秒杀同一件商品）时，大量客户端会因为 WATCH 失败而收到 nil。如果应用层采取 while(true) 轮询重试，会导致严重的 CPU 空转和网络拥堵（活锁）。

Lua 脚本则通过“单线程排他性”从根本上消除了并发冲突的可能，但也因此要求脚本绝对精简，避免死循环拖垮整个集群。

---

三、 适用场景与技术选型考量

基于严谨的工程思维，这两种技术方案的选型有着清晰的边界：

优先选择 Redis 事务 (WATCH + MULTI/EXEC) 的场景：

1. 低竞争并发环境： 极少出现多个线程同时修改同一个 Key 的情况，偶尔的冲突可以通过简单的应用层报错或单次重试解决。
2. 多 Key 批量操作且无复杂逻辑关联： 只是单纯地希望将一堆命令打包，确保它们在执行时不被其他客户端的指令打断（利用隔离性）。
3. 规避 Lua 集群限制： 在 Redis Cluster 集群模式下，如果需要操作的多个 Key 分布在不同的哈希槽（Hash Slot），Lua 脚本会直接报错被拒。而原生事务可以通过客户端路由策略进行一定程度的变通（尽管也不推荐跨槽事务）。

必须选择 Lua 脚本的场景：

1. 高并发原子判断与更新（如秒杀扣减、分布式锁）： 需要将 GET、条件判断（if count > 0）和 SET 绝对绑定在一起，绝不能容忍因高并发导致的大量事务 Discard。
2. 网络 I/O 敏感型操作： 逻辑流包含多个步骤且彼此依赖，使用 Lua 可将 5 次以上的 RTT 降为 1 次，大幅降低网络延迟引起的系统响应毛刺。
3. 定制化限流器： 如滑动窗口限流、令牌桶算法，需要精准的时序控制和计算，原生指令无法拼凑出这种逻辑闭环。

总结结论： Redis 事务是一套以性能为优先、将逻辑正确性责任上交给开发者的轻量级批处理机制；而 Lua 脚本则是 Redis 提供的一种“存储过程”，用于在单线程模型下实现强原子性的复杂逻辑。优秀的架构设计不在于强行要求 Redis 提供类似 MySQL 的回滚能力，而在于利用其极速的内存操作特性，在应用侧做好状态机的流转与补偿。