很多人在第一次接触 Redis 事务时，都会有一个疑问：MySQL 的事务可以通过 ROLLBACK 回滚，为什么 Redis 的事务不支持回滚？这难道不是一个明显的功能缺陷吗？其实，Redis 不支持回滚并不是设计上的疏忽，而是一个经过深思熟虑的架构决策。要理解这个决策，我们需要先搞清楚 Redis 事务到底是怎么工作的。
Redis 事务的基本用法
Redis 事务通过 MULTI、EXEC、DISCARD 和 WATCH 这几个命令来实现。一个典型的事务流程如下：
MULTI
SET user:1:name "Alice"
INCR user:1:age
LPUSH user:1:tasks "task1"
EXEC
在执行 MULTI 之后，后续的命令并不会立即执行，而是被放入一个队列中。当 EXEC 被调用时，队列中的所有命令会按顺序一次性执行完毕。DISCARD 用于放弃事务，清空命令队列。WATCH 则用于实现乐观锁，在 EXEC 执行前监视某些键是否被其他客户端修改。
从表面上看，这确实像是一个事务机制。但关键在于：如果队列中某条命令执行失败，Redis 不会回滚已经执行的命令，而是继续执行剩余的指令。
两种不同类型的错误
要理解为什么不回滚，首先要区分 Redis 事务中可能出现的两种错误。
入队错误
这类错误发生在命令被放入队列的阶段。比如，你写了一个根本不存在的命令，或者命令的参数个数不对：
MULTI
SET key
INCR
EXEC
SET key 缺少参数，在入队时就会被检测出来。在这种情况下，Redis 会返回错误，并且整个事务都会被放弃，EXEC 执行时不会执行任何命令。这其实是一种“全有或全无”的行为，但它是通过拒绝执行整个事务来实现的，而不是通过回滚。
执行错误
这类错误发生在 EXEC 执行阶段。命令本身语法正确，入队也成功了，但在实际执行时出错。最典型的例子是对一个字符串类型的键执行 LPUSH 或 INCR 操作：
MULTI
SET user:1:name "Alice"
INCR user:1:name
EXEC
INCR 命令入队时没有问题，但执行时会因为 user:1:name 的值不是数字而报错。在这种情况下，SET 命令已经执行成功了，INCR 报错，但 Redis 不会回滚 SET 操作，事务中的其他命令也会继续执行。
这就是很多人感到困惑的地方：为什么出错了还不回滚？
为什么 Redis 选择不支持回滚
设计哲学：简单和快速
Redis 的核心设计哲学是简单和快速。它的作者 antirez 在设计事务时，明确表示不支持回滚是经过权衡的决定。支持回滚意味着 Redis 需要维护额外的撤销日志（undo log），记录每个命令执行前的状态，以便在出错时恢复。这不仅会增加内存开销，还会拖慢执行速度。
Redis 的定位是一个高性能的内存数据库，它不希望为了一个在大多数场景下并不必要的能力而牺牲性能。antirez 在文档中写道：“如果你有命令执行失败，那说明你的代码有问题，应该在开发阶段就发现并修复，而不是在生产环境中依赖回滚。”
执行错误本质上是编程错误
Redis 认为，事务中的执行错误（比如对字符串执行 INCR）本质上属于编程错误，而不是运行时才可能出现的意外情况。类型不匹配、命令用错，这些问题在开发和测试阶段就应该被发现。既然不是运行时不可预知的异常，就没有必要让数据库层来兜底。
这和 MySQL 的场景不同。在 MySQL 中，事务回滚通常用于处理并发冲突、约束违反、业务逻辑中的异常分支等运行时才确定的情况。而 Redis 的事务模型更简单，它假设你发送的命令在语义上都是正确的。
Redis 事务的本质是命令批处理
严格来说，Redis 的事务更像是一种命令批处理机制，而不是传统关系型数据库意义上的事务。它保证的是：
- 原子性（Atomicity）：队列中的所有命令要么全部被执行，要么全部不执行（仅针对入队错误的情况）。
- 隔离性（Isolation）：事务执行过程中不会被其他客户端的命令打断。
但它不保证一致性（Consistency） 在传统 ACID 意义上的那种一致性，也不提供回滚能力。Redis 官方文档也明确说明，Redis 事务不支持回滚。
性能考量
如果 Redis 要实现回滚，每个命令执行前都需要保存旧值，这会带来显著的内存和 CPU 开销。对于一个追求极致性能的内存数据库来说，这是不可接受的。而且，大多数使用 Redis 事务的场景，并不需要回滚——它们更多是为了保证一组命令的原子性和隔离性，而不是为了处理执行失败后的恢复。
WATCH 机制：乐观锁的替代方案
虽然 Redis 事务不支持回滚，但它提供了 WATCH 命令来实现乐观锁，这在一定程度上弥补了回滚缺失带来的问题。
WATCH balance
MULTI
DECRBY balance 100
INCRBY debt 100
EXEC
如果在 WATCH 之后、EXEC 之前，balance 被其他客户端修改了，那么 EXEC 会返回 nil，整个事务不会执行。这实际上提供了一种“条件执行”的能力：只有在数据未被修改的情况下才执行事务。
通过 WATCH，你可以在应用层实现类似“检查再执行”的逻辑，避免并发冲突导致的数据不一致。这比回滚更轻量，也更符合 Redis 的设计理念。
实际开发中的建议
既然 Redis 事务不支持回滚，在实际开发中应该注意以下几点：
- 在开发阶段充分测试：确保事务中的命令类型和参数都正确，避免执行错误。
- 使用 WATCH 处理并发：在需要条件执行的场景下，用
WATCH配合重试机制来保证数据一致性。 - 不要依赖事务回滚：如果业务逻辑需要严格的事务回滚，考虑使用关系型数据库，或者用 Lua 脚本在 Redis 中实现更复杂的原子操作。
- Lua 脚本是更好的选择：Redis 的 Lua 脚本在执行时是原子性的，而且可以在脚本中进行条件判断和错误处理，比
MULTI/EXEC更灵活。
总结
Redis 事务不支持回滚，不是因为它“做不到”，而是因为它“选择不做”。这一决策背后是 Redis 对简单性、高性能和实用主义的坚持。Redis 事务的本质是命令批处理，它保证原子性和隔离性，但不提供回滚能力。执行错误在 Redis 看来是编程错误，应该在开发阶段解决，而不是依赖数据库回滚。
理解这一点，不仅能帮助你在面试中给出准确的回答，更能让你在实际开发中正确使用 Redis 事务，避免踩坑。如果你需要更强大的事务能力，Lua 脚本或关系型数据库可能是更合适的选择。
未经允许不得转载：任鹏个人博客 » Redis 事务为什么不支持回滚
