怎么理解 Redis 事务

背景

在面试中经常会被问到，redis支持事务吗？事务是怎么实现的？事务会回滚吗？又是一键三连，我下面分析下，看看能不能吊打面试官

什么是Redis事务

1. 事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。 事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
2. 事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

总结说：redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。

Redis 中的事务如何工作

Redis 事务允许在一个步骤中执行一组命令，它们以 MULTI、EXEC、DISCARD 和 WATCH 命令为中心，事务中的所有命令都被序列化并按顺序执行。另一个客户端发送的请求永远不会在 Redis 事务执行过程中得到服务。这保证了命令作为单个独立操作执行。

一个事务从开始到执行会经历以下三个阶段：

• 开启事务。
• 命令入队。
• 执行事务或者放弃事务。

其中，开启事务使用 multi 命令，事务执行使用 exec 命令，放弃事务使用 discard 命令。

事务执行流程图，可以直观的看下：

Redis事务相关命令和使用

• MULTI ：开启事务，redis会将后续的命令逐个放入队列中，然后使用EXEC命令来原子化执行这个命令系列。
• EXEC：执行事务中的所有操作命令。
• DISCARD：取消事务，放弃执行事务块中的所有命令。
• WATCH：监视一个或多个key,如果事务在执行前，这个key(或多个key)被其他命令修改，则事务被中断，不会执行事务中的任何命令。
• UNWATCH：取消WATCH对所有key的监视。

MULTI 开启事务

multi 命令用于开启事务，实现代码如下：

# multi 命令可以让客户端从非事务模式状态，变为事务模式状态
127.0.0.1:6371> MULTI
OK

注意啊：multi 命令不能嵌套使用，如果已经开启了事务的情况下，再执行 multi 命令，会提示如下错误：

127.0.0.1:6371> MULTI
OK
127.0.0.1:6371(TX)> MULTI
(error) ERR MULTI calls can not be nested

命令入列

客户端进入事务状态之后，执行的所有常规 Redis 操作命令（非触发事务执行或放弃和导致入列异常的命令）会依次入列，命令入列成功后会返回 QUEUED，如下代码所示

127.0.0.1:6371> MULTI
OK
127.0.0.1:6371(TX)> set k 1
QUEUED
127.0.0.1:6371(TX)> set b 1
QUEUED

用户可以发出多个命令，命令会按照先进先出（FIFO）的顺序出入列，Redis 不会执行这些命令，而是将它们排队。需要调用 EXEC执行事务 ，所有命令才会执行。

执行事务/放弃事务

执行事务的命令是 exec，放弃事务的命令是 discard。

执行事务:

127.0.0.1:6371> MULTI
OK
127.0.0.1:6371(TX)> set k 1
QUEUED
127.0.0.1:6371(TX)> set b 1
QUEUED
127.0.0.1:6371(TX)> EXEC
1) OK
2) OK

EXEC 返回一个回复数组，其中每个元素都是事务中单个命令的回复，与发出命令的顺序相同。

放弃事务：

127.0.0.1:6371> MULTI
OK
127.0.0.1:6371(TX)> set k 2
QUEUED
127.0.0.1:6371(TX)> set b 2
QUEUED
127.0.0.1:6371(TX)> DISCARD
OK
127.0.0.1:6371> get k
"1"
127.0.0.1:6371> get b
"1"

MULTI开启事务后，命令入队，取消事务，队列里面的命令是不会执行的。 设置 k、b两个key的值为2，取消事务后，值还是保留以前是 1，说明取消事务后，队列里面的命令没有执行

事务出现错误的处理

事务执行中的错误分为以下两类：

• 入列的命令语法错误，终止事务
• 入列命令运行时错误，不会终止事务

入列的命令语法错误，终止事务

分别设置 k1、k2的值为1，然后开启事务，设置值k1、k2的值为2，其中 设置k2的时候 命令出错 sets，执行事务，入列的命令未执行，终止了事务

127.0.0.1:6371> set k1 1
OK
127.0.0.1:6371> set k2 1
OK
127.0.0.1:6371> get k1
"1"
127.0.0.1:6371> get k2
"1"
127.0.0.1:6371> MULTI
OK
127.0.0.1:6371(TX)> set k1 2
QUEUED
127.0.0.1:6371(TX)> sets k2 2
(error) ERR unknown command 'sets', with args beginning with: 'k2' '2'
127.0.0.1:6371(TX)> EXEC
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6371> get k1
"1"
127.0.0.1:6371> get k2
"1"

入列的命令运行时错误，不会终止事务

在开启事务后，修改k1值为2，但将k2的类型作为List，进行元素操作，在运行时检测类型错误，最终导致事务提交失败，此时事务并没有回滚，而是跳过错误命令继续执行， 结果k1值改变

127.0.0.1:6371> get k1
"1"
127.0.0.1:6371> get k2
"1"
127.0.0.1:6371> MULTI
OK
127.0.0.1:6371(TX)> set k1 2
QUEUED
127.0.0.1:6371(TX)> LPOP k2
QUEUED
127.0.0.1:6371(TX)> exec
1) OK
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
127.0.0.1:6371> get k1
"2"

运行时发生错误，事务未终止，事务不会回滚呢？

为什么事务不会回滚？

Redis 官方文档的解释如下：

Redis 命令只会因为错误的语法而失败（并且这些问题不能在入队时发现），或是命令用在了错误类型的键上面：这也就是说，从实用性的角度来说，失败的命令是由编程错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中。

watch 监控

WATCH 用于为 Redis 事务提供检查和设置 (CAS) 行为。

watch 命令用于客户端并发情况下，为事务提供一个乐观锁（CAS，Check And Set），也就是可以用 watch 命令来监控一个或多个变量，如果在事务的过程中，某个监控项被修改了，那么整个事务就会终止执行,并且 EXEC 返回 Null 回复以通知事务失败

watch 基本语法如下：

watch key [key ...]

举个例子，看下修改监控的key以后，事务是否会终止

客户端1：设置k1的值为1，k2的值1，然后 watch 监控k1，开启事务，设置k1为2，k2为2，客户端2：修改k1的值为23，客户端1执行事务

客户端1执行命令如下：

127.0.0.1:6371> set k1 1
OK
127.0.0.1:6371> set k2 1
OK
127.0.0.1:6371> WATCH k1
OK
127.0.0.1:6371> MULTI
OK
127.0.0.1:6371(TX)> set k1 2
QUEUED
127.0.0.1:6371(TX)> set k2  2
QUEUED
127.0.0.1:6371(TX)> EXEC
(nil)
127.0.0.1:6371> get k1
"3"
127.0.0.1:6371> get k2
"1"

客户端2执行命令如下：

127.0.0.1:6371> set k1 3
OK

从上面的结果可以看出，监控了k1，客户端2修改了k1的值，事务是中止的

如果不再监控key，使用UNWATCH 取消监控

代码实现

使用jedis客户端实现，代码如下：

public static void main(String[] args) {Jedis jedis = new Jedis("10.1.250.157", 6379);jedis.auth("google00");jedis.set("k","1");//监控keyjedis.watch("k");//开启事务Transaction tx =jedis.multi();// 命令入队tx.set("k","2");tx.set("k1","3");//执行事务tx.exec();//取消监控jedis.unwatch();}

总结

redis是支持事务的，开启事务后，命令入队，命令的语法如果有错，执行事务会中止，如果执行命令的时候发现命令有问题，其他命令能正常执行，事务是不会回滚的，因为redis的回滚会对redis的简单性和性能造成严重影响。

特别注意： 事务中的命令要么全部被执行，要么全部都不执行 。是执行，不是成功哦，更我们平时用的关系型数据库是有差别的。