怎么理解 Redis 事务

news2024/11/18 23:44:39

背景

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

什么是Redis事务

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

总结说：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");
        //监控key
        jedis.watch("k");
        //开启事务
        Transaction tx =jedis.multi();
        // 命令入队
        tx.set("k","2");
        tx.set("k1","3");
        //执行事务
        tx.exec();
        //取消监控
        jedis.unwatch();


    }