当前位置：首页 > 问答 > 正文

Redis到底能不能实现事务，实际用起来怎么样，有啥限制和注意点？

凤伟才
问答
2026-01-10 15:37:29
3

关于Redis到底能不能实现事务，答案是：能，但和传统关系型数据库（比如MySQL）里理解的事务完全不是一回事，你不能用MySQL那套ACID标准来生搬硬套Redis，否则会很困惑，下面就来详细说说它实际用起来怎么样,以及有哪些限制和注意点。

Redis事务是如何工作的？

Redis的事务核心是通过三个命令实现的：MULTI, EXEC, DISCARD，它的工作模式更像一个“打包批处理”或者“命令队列”的机制。

开启事务（MULTI）：当你输入MULTI命令后，Redis就进入了“事务模式”，但这并不意味着它像MySQL那样立刻创建了一个数据快照，它只是表示，接下来你发的所有命令，Redis不会立即执行,而是按照顺序一个一个地排队放进一个队列里。
命令入队：在MULTI之后，你输入的所有常规命令（比如SET, GET, SADD, HSET等）都会收到一个QUEUED的回复，这表示命令已经成功进入了事务队列,在等待执行。
执行事务（EXEC）：当你输入EXEC命令时，Redis才会真正开始干活，它会按照命令入队的顺序，一次性、连续地执行队列中的所有命令。
丢弃事务（DISCARD）：如果你在输入EXEC之前改变了主意，可以用DISCARD命令来清空事务队列,并退出事务状态。

实际用起来的感觉和好处

保证隔离性：这是Redis事务最大的亮点，当某个客户端在执行MULTI...EXEC事务块时，其他客户端发来的命令是无法插入执行的，Redis会确保事务队列中的所有命令作为一个独立的、连续的操作序列来执行，在执行过程中，不会被其他命令打断，这满足了事务ACID特性中的“I”（Isolation，隔离性）,你不会看到事务执行到一半时的中间状态。
一次性执行：所有命令在EXEC时一次性执行，减少了客户端与服务器之间的网络往返时间（RTT），在某些需要连续执行多个命令的场景下,比一条一条地发送命令效率更高。

核心限制和需要注意的点（这里很重要）

没有原子性回滚（最关键的差异）：这是Redis事务和传统数据库事务最本质的区别，在MySQL里，如果事务中有一条SQL语句失败了（比如违反了唯一约束），整个事务会回滚，所有修改都会撤销。但Redis不是这样的！
- Redis事务中，命令的错误分两种：
  - 入队时错误：在输入MULTI后，如果你输入了一个语法错误的命令（比如命令名拼错SETT，或者参数个数不对），Redis会直接报错，并且这个命令不会被放入队列。如果你还坚持执行EXEC，整个事务都不会被执行，因为队列中包含了错误命令,这还算比较符合预期。
  - 执行时错误：如果命令语法正确，但执行时出错（你对一个字符串类型的键执行列表操作LPOP mykey，或者HSET一个不存在的键但类型是集合），只有那条出错的命令会执行失败，而事务队列中其他正确的命令会照常执行！Redis不会自动回滚之前已经执行成功的命令。
- 为什么这么设计？ Redis作者认为，这种命令执行错误通常是编程错误，应该在开发测试阶段就被发现和修复，而不是等到生产环境，为了保持Redis的简单性和高性能,它不支持回滚这种复杂功能。
不满足原子性的例子：
- 假设事务里有三条命令：1. SET key1 "A" 2. LPOP key2（但key2不是列表类型，会执行失败） 3. SET key3 "C"。
- 执行EXEC后，结果会是：key1被成功设置为"A"，key2的LPOP操作失败，key3被成功设置为"C",事务并没有因为第二条命令失败而全部撤销。
不保证强一致性：虽然事务执行期间是隔离的，但因为Redis的持久化机制（RDB快照和AOF日志）是异步的，所以在极端情况下（如服务器崩溃），有可能出现事务已经执行成功，但数据还没来得及持久化到磁盘的情况，从持久化的角度看，它不满足ACID中的“D”（Durability，持久性）。
WATCH命令——乐观锁：为了解决类似“丢失更新”的问题（比如两个人同时想修改同一个库存），Redis提供了一个WATCH机制。
- 用法：在MULTI之前，先用WATCH命令监视一个或多个键，然后执行你的业务逻辑，最后MULTI...EXEC。
- 原理：如果在WATCH之后、EXEC之前，有其他客户端修改了你监视的键的值，那么当你执行EXEC时，整个事务会被取消，返回nil，你的程序需要检测到这个失败，然后重试整个逻辑（重新WATCH，重新计算，重新MULTI...EXEC）。
- 注意点：WATCH相当于一个乐观锁，它认为冲突不经常发生，只在最后提交时检查，如果冲突频繁，重试次数会很多,性能会下降。