Redis 事务迷思：为何 MULTI/EXEC 并非你想象中的“事务”？-优快云博客

看似简单的 MULTI/EXEC，背后隐藏着单线程模型的智慧与妥协。但请注意，它可能是你武器库中“性价比”最低的那一件。

在日常开发中，“事务”这个词我们耳熟能详，它通常代表着 ACID，代表着要么全做，要么全不做的原子性。当我们从关系型数据库转到 Redis 时，会很自然地寻找类似的功能。Redis 确实提供了事务，但它是一颗特性独特的“原子弹”，理解其原理和局限性至关重要，否则极易在项目中埋下隐患。

一、Redis 事务是什么？一道命令的“打包流水线”

想象一个场景：你需要先设置一个用户的名字，再增加他的积分，最后记录一条日志。这三个操作必须作为一个整体，不能只执行了一部分。

Redis 事务的核心思想就是：将多个命令打包成一个队列，然后一次性、按顺序地执行，并且在此期间，不会被其他客户端的命令请求所打断。

它通过三个核心命令实现：

MULTI：标志着事务的开始。自此之后，Redis 会将客户端发来的命令一个个放入一个队列中，而不是立即执行。
命令入队：在 MULTI 后，输入 SET, GET, INCR 等命令，返回的都是 QUEUED，表示命令已排队。
EXEC：标志着事务的执行。Redis 会依次执行队列中的所有命令，并将所有结果一次性返回。
DISCARD：用于取消事务，清空队列中的所有命令。

一个简单的事务流程：

127.0.0.1:6379> MULTI      # 开启事务
OK
127.0.0.1:6379> SET user:1:name "码哥"
QUEUED
127.0.0.1:6379> INCR user:1:points
QUEUED
127.0.0.1:6379> EXEC       # 执行事务
1) OK                      # 第一个命令的结果
2) (integer) 1             # 第二个命令的结果

二、原子性？不可打断？深挖单线程执行模型

这是最核心的问题，也是很多人的误解区。

结论先行：在 EXEC 执行阶段，事务包是原子的且不可打断的。这由 Redis 的单线程模型保证。

Redis 是单线程的！

Redis 处理命令的核心网络和读写事件是在一个单线程中完成的。这意味着，在任何给定时刻，Redis 最多只执行一个命令。所有命令都要在这个线程中排队等候，绝无并发执行的可能。

事务执行的三个阶段：

让我们把事务过程拆解，并用两个客户端（Client-A 和 Client-B）的对话来演示：

时间线	Client-A (事务客户端)	Client-B (其他客户端)	Redis 服务器状态	解释
t1	MULTI		执行 MULTI	将 Client-A 置为事务状态。
t2	SET keyA valA		返回 QUEUED	不执行，只是将命令加入 Client-A 专属的事务队列。
t3		INCR keyB	执行 INCR keyB	关键点！此时服务器是“空闲”的（只是在缓存命令），所以会立即处理 Client-B 的请求。
t4	SET keyC valC		返回 QUEUED	继续将命令加入队列。
t5	EXEC		开始执行事务	原子性开始！ Redis 依次执行队列里的 SET keyA valA -> SET keyC valC。在此期间，整个服务器被独占，Client-B 发来的任何新命令都必须阻塞等待！
t6		GET keyA	等待中...	Client-B 的命令在 t5 阶段发出，但必须等 Client-A 的事务全部执行完。
t7			返回结果给 A	事务执行完毕，返回 [OK, OK] 给 Client-A。
t8			执行 GET keyA	现在才轮到处理 Client-B 在 t6 时刻发出的命令。

所以，答案是：在 EXEC 执行期间，绝对不可能插入执行任何其他非事务命令。事务的“不可打断”指的是这个执行阶段。

三、为何说它不像MySQL事务？—— 没有回滚（Rollback）

这是 Redis 事务最著名的特性，或者说“缺陷”。Redis 事务不支持回滚。

语法错误（入队错误）：如果在 MULTI 期间命令语法错误（如 SET key），在 EXEC 时整个事务会被拒绝，所有命令都不执行。

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET key1 value1
QUEUED
127.0.0.1:6379> SET key2 # 错误的语法
(error) ERR wrong number of arguments for 'set' command
127.0.0.1:6379> EXEC
(error) EXECABORT Transaction discarded because of previous errors. # 整个事务失败

运行时错误（执行错误）：如果在 EXEC 期间某条命令出错（如对字符串执行 INCR），只有那条失败的命令不会被执行，队列中的其他命令会照常执行！

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET key1 "hello"
QUEUED
127.0.0.1:6379> INCR key1 # 这个会在执行时失败
QUEUED
127.0.0.1:6379> SET key2 "world"
QUEUED
127.0.0.1:6379> EXEC
1) OK # SET key1 "hello" 成功
2) (error) ERR value is not an integer or out of range # INCR key1 失败
3) OK # SET key2 "world" 成功！它被执行了

Redis 团队的设计哲学是： 命令失败通常是编程错误（比如用了错误的类型），应该在开发阶段就被发现和修复，而不是在生产环境通过回滚来挽救。保持简单高效的内核比支持复杂的回滚机制更重要。

四、事务的致命伤：为何在开发中“鸡肋”？

你可能会想，既然能打包执行，总有用武之地吧？但事实上，Redis 事务在实际生产中使用场景非常有限，甚至被认为是“鸡肋”，主要原因如下：

🛑 不满足原子性和持久性：如上所述，它无法提供类似关系型数据库的事务安全保证。对于要求“要么全做，要么全不做”的核心业务（如转账），Redis 事务根本无法胜任。
🚫 巨大的网络开销：这是最容易被忽略但性能影响极大的一点。 事务模式：MULTI + N条命令 + EXEC 需要 N+2 次网络往返（RTT）。每条命令在入队时都要发送一次，并等待 QUEUED 响应，这会产生巨大的网络延迟。 明明可以批量：这种操作非常低效，明明一次批量发送所有命令就可以了。

正是因为这些致命伤，在大多数需要批量执行命令的场景下，我们都有更好、更高效的替代方案。

五、进阶技能：用 WATCH 实现乐观锁

单纯打包命令不够，我们常需要确保事务中的键在打包后、执行前没有被别人改动。这就是 CAS（Compare-And-Set） 操作，Redis 用 WATCH 命令来实现。

场景：秒杀扣库存 多个客户端同时尝试减少库存 stock:001，必须保证库存不为负。

没有 WATCH 的问题：

# Client-A 和 Client-B 都读取到库存为 10
# Client-A 开始了事务
MULTI
DECR stock:001 # 此时库存还是10，命令入队
# 在 EXEC 前，Client-B 已经执行了 `DECR stock:001`，库存变成了9
EXEC # Client-A 的事务依然会执行 DECR，库存变成了8，但本应只减一次！

使用 WATCH 的解决方案： WATCH 命令可以监视一个或多个 key。如果在 EXEC 命令执行前，这些被监视的 key 被其他客户端修改了，那么整个事务将被取消（EXEC 返回 nil）。

# Client-A 执行流程（实现乐观锁）
127.0.0.1:6379> WATCH stock:001          # 客户端A开始监视库存键
OK
127.0.0.1:6379> GET stock:001            # 获取当前库存值
"10"
# ... (此时客户端A基于业务逻辑判断 stock > 0，决定发起扣减)

127.0.0.1:6379> MULTI                    # 开启事务
OK
127.0.0.1:6379> DECR stock:001           # 将“减少库存”命令放入队列
QUEUED
127.0.0.1:6379> EXEC                     # 执行事务
# 此时有两种可能的结果：
# 1. 如果在 WATCH 之后、EXEC 之前，stock:001 未被其他客户端修改
#    → 事务成功执行，返回所有命令的结果队列，例如：(integer) 9
#
# 2. 如果在 WATCH 之后、EXEC 之前，stock:001 被其他客户端（如Client-B）修改
#    → 事务被取消，EXEC 返回 (nil)

WATCH 是实现 Redis “CAS”操作的唯一手段，这也是 Redis 事务最有价值、不可替代的应用场景。

六、最佳实践与决策：抛弃事务，拥抱 Pipeline 和 Lua

了解了事务的弊端后，我们的选择应该非常清晰。下面是一个全面的方案对比和选型指南：

特性	事务 (MULTI/EXEC)	Pipeline	Lua 脚本
原子性	是 (EXEC阶段)	否	是 (原子且阻塞，类似一个大命令)
网络开销	高 (N+2次RTT)	极低 (1次RTT)	极低 (1次RTT)
隔离性	强 (串行执行)	无 (命令可能交错)	强 (串行执行)
灵活性	中	低	极高 (可编写复杂逻辑)
错误处理	无回滚	命令独立成功/失败	出错可自定义回滚逻辑(需自己实现)

决策指南：

只需要批量执行，无需原子性，且执行顺序无依赖关系？
✅ 坚决使用 Pipeline。它将多个命令打包在一次请求中发送，极大减少网络往返次数，是提升性能的首选方案。这是替代事务最常见、最有效的方案。
需要原子性，且逻辑复杂？
✅ 首选 Lua 脚本。它是现代 Redis 实现复杂原子操作的标准答案。脚本在服务器端原子执行，既无网络开销，灵活性又远超事务。例如，可以在脚本内实现 if...else、for 循环甚至复杂的计算和回滚逻辑。
需要原子性，且逻辑简单（只是检查-设置）？
⭕ 考虑使用 WATCH + 事务。这是事务唯一的“王牌”应用场景，用于实现乐观锁。但请注意，在竞争激烈时，事务可能会多次执行失败，需要重试逻辑。

结论： 在日常开发中，应避免将 Redis 事务作为普通的批量命令工具。 它的设计并非为了满足严格的 ACID，其性能开销也使其性价比极低。理解其 WATCH 机制在乐观锁上的独特价值，并熟练掌握 Pipeline 和 Lua 脚本这两种更优秀的批量与原子操作方案，才是高效使用 Redis 的正确姿势。

结语：理解取舍，方得始终

Redis 事务是一个特定设计哲学下的产物，它是性能、简单性与功能之间的一次典型权衡。它放弃了回滚和强一致性这些重型数据库的特性，换来了核心命令执行的高性能和内部实现的极度简洁。因此，评判它“鸡肋”与否，关键在于是否把它用对了地方。将它误用作通用批量工具，它无疑是低效且脆弱的；但将其视为实现分布式乐观锁的专用原语，它又是不可替代的。

作为开发者，我们的价值不在于记住所有 API，而在于深刻理解每个工具背后的设计意图与适用边界。对于 Redis 事务，我们的策略应是：珍视其 WATCH 能力，但忘掉其批量操作的属性，用 Pipeline 和 Lua 脚本去填补后者的空白。唯有如此，才能在架构与编码中做出最明智的选择。