Redis事务讲解

分手后的思念是犯贱 2022-01-23 02:41 155阅读 0赞

## 一、引言 ##

为了确保连续多个操作的原子性，一个成熟的数据库通常都会有事务支持，Redis 也不例外。Redis 的事务使用非常简单，不同于关系数据库，我们无须理解那么多复杂的事务模型，就可以直接使用。不过也正是因为这种简单性，它的事务模型很不严格，这要求我们不能像使用关系数据库的事务一样来使用 Redis。

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

1.  开始事务。
2.  命令入队。
3.  执行事务。

在MySQL中我们使用START TRANSACTION 或 BEGIN开启一个事务，使用COMMIT提交一个事务；而在Redis中我们使用**MULTI** 开始一个事务，由 **EXEC** 命令触发事务， 一并执行事务中的所有命令。

需要注意的是:

*  Redis的事务没有关系数据库事务提供的回滚（rollback），所以开发者必须在事务执行失败后进行后续的处理；
 *  如果在一个事务中的出现**命令错误**，那么**所有的命令都不会执行**；
 *  如果在一个事务中出现**运行错误**，那么**正确的命令会被执行**。

## 二、相关命令 ##

### 1. MULTI ###

用于标记事务块的开始。Redis会将后续的命令逐个放入服务器队列中，然后才能使用EXEC命令原子化地执行这个命令序列。

这个命令的运行格式如下所示：

MULTI

这个命令的返回值是一个简单的字符串，总是OK。

### 2. EXEC ###

在一个事务中执行所有先前放入队列的命令，然后恢复正常的连接状态。

当使用WATCH命令时，只有当受监控的键没有被修改时，EXEC命令才会执行事务中的命令，这种方式利用了检查再设置（CAS）的机制。

这个命令的运行格式如下所示：

EXEC

这个命令的返回值是一个数组，其中的每个元素分别是原子化事务中的每个命令的返回值。 当使用WATCH命令时，如果事务执行中止，那么EXEC命令就会返回一个Null值。

### 3. DISCARD ###

清除所有先前在一个事务中放入队列的命令，然后恢复正常的连接状态。

如果使用了WATCH命令，那么DISCARD命令就会将当前连接监控的所有键取消监控。

这个命令的运行格式如下所示：

DISCARD

这个命令的返回值是一个简单的字符串，总是OK。

### 4. WATCH ###

当某个事务需要按条件执行时，就要使用这个命令将给定的键设置为受监控的。

这个命令的运行格式如下所示：

WATCH key [key ...]

这个命令的返回值是一个简单的字符串，总是OK。

对于每个键来说，时间复杂度总是O(1)。

### 5. UNWATCH ###

清除所有先前为一个事务监控的键。

如果你调用了EXEC或DISCARD命令，那么就不需要手动调用UNWATCH命令。

这个命令的运行格式如下所示：

UNWATCH

这个命令的返回值是一个简单的字符串，总是OK。

时间复杂度总是O(1)。

## 三、执行事务 ##

以下是一个事务的例子， 它先以 **MULTI** 开始一个事务， 然后将多个命令入队到事务中， 最后由 **EXEC** 命令触发事务， 一并执行事务中的所有命令：

redis 127.0.0.1:6379> MULTI
    OK
    
    redis 127.0.0.1:6379> SET book-name "Mastering C++ in 21 days"
    QUEUED
    
    redis 127.0.0.1:6379> GET book-name
    QUEUED
    
    redis 127.0.0.1:6379> SADD tag "C++" "Programming" "Mastering Series"
    QUEUED
    
    redis 127.0.0.1:6379> SMEMBERS tag
    QUEUED
    
    redis 127.0.0.1:6379> EXEC
    1) OK
    2) "Mastering C++ in 21 days"
    3) (integer) 3
    4) 1) "Mastering Series"
       2) "C++"
       3) "Programming"

单个 Redis 命令的执行是原子性的，但 Redis 没有在事务上增加任何维持原子性的机制，所以 Redis 事务的执行并不是原子性的。

事务可以理解为一个打包的批量执行脚本，但批量指令并非原子化的操作，中间某条指令的失败不会导致前面已做指令的回滚，也不会造成后续的指令不做。

![20190601233553879.png][]

## 四、取消事务 ##

此外我们可以使用DISCARD取消事务。

redis 127.0.0.1:6379> MULTI
    OK
    
    redis 127.0.0.1:6379> SADD tag "Java" "Python"
    QUEUED
    
    redis 127.0.0.1:6379> DISCARD
    OK
    
    redis 127.0.0.1:6379> SMEMBERS tag
    1) "Mastering Series"
    2) "C++"
    3) "Programming"

## 五、WATCH命令 ##

Redis使用WATCH命令实现事务的“检查再设置”（CAS）行为。

作为WATCH命令的参数的键会受到Redis的监控，Redis能够检测到它们的变化。在执行EXEC命令之前，如果Redis检测到至少有一个键被修改了，那么整个事务便会中止运行，然后EXEC命令会返回一个Null值，提醒用户事务运行失败。

例如，设想我们需要将某个键的值自动递增1（假设Redis没有INCR命令）。

首次尝试的伪码可能如下所示：

val = GET mykey
    val = val + 1
    SET mykey $val

如果我们只有一个Redis客户端在一段指定的时间之内执行上述伪码的操作，那么这段伪码将能够可靠的工作。如果有多个客户端大约在同一时间尝试递增这个键的值，那么将会产生竞争状态。例如，客户端-A和客户端-B都会读取这个键的旧值（例如：10）。这两个客户端都会将这个键的值递增至11，最后使用SET命令将这个键的新值设置为11。因此，这个键的最终值是11，而不是12。

现在，我们可以使用WATCH命令完美地解决上述的问题，伪码如下所示：

WATCH mykey
    val = GET mykey
    val = val + 1
    MULTI
    SET mykey $val
    EXEC

由上述伪码可知，如果存在竞争状态，并且有另一个客户端在我们调用WATCH命令和EXEC命令之间的时间内修改了val变量的结果，那么事务将会运行失败。

我们只需要重复执行上述伪码的操作，希望此次运行不会再出现竞争状态。这种形式的锁就被称为**乐观锁**，它是一种非常强大的锁。在许多用例中，多个客户端可能会访问不同的键，因此不太可能发生冲突 —— 也就是说，通常没有必要重复执行上述伪码的操作。

**那么WATCH命令实际做了些什么呢？**这个命令会使得EXEC命令在满足某些条件时才会运行事务：我们要求Redis只有在所有受监控的键都没有被修改时，才会执行事务。（但是，相同的客户端可能会在事务内部修改这些键，此时这个事务不会中止运行。）否则，Redis根本就不会进入事务。（注意，如果你使用WATCH命令监控一个易失性的键，然后在你监控这个键之后，Redis再使这个键过期，那么EXEC命令仍然可以正常工作。）

WATCH命令可以被调用多次。简单说来，所有的WATCH命令都会在被调用之时立刻对相应的键进行监控，直到EXEC命令被调用之时为止。你可以在单条的WATCH命令之中，使用任意数量的键作为命令参数。

当调用EXEC命令时，所有的键都会变为未受监控的状态，Redis不会管事务是否被中止。当一个客户端连接被关闭时，所有的键也都会变为未受监控的状态。

你还可以使用UNWATCH命令（不需要任何参数），这样便能清除所有的受监控键。当我们对某些键施加乐观锁之后，这个命令有时会非常有用。因为，我们可能需要运行一个用来修改这些键的事务，但是在读取这些键的当前内容之后，我们可能不打算继续进行操作，此时便可以使用UNWATCH命令，清除所有受监控的键。在运行UNWATCH命令之后，Redis连接便可以再次自由地用于运行新事务。

## 六、事务对异常的处理机制 ##

Redis执行命令的错误主要分为两种：

1.  **命令错误**：执行命令语法错误，比如说将 set 命令写成 sett
2.  **运行时错误**：命令语法正确，但是执行错误，比如说对 List 集合执行 sadd 命令

Redis事务中如果发生上面两种错误，处理机制也是不同的。

### 命令错误处理机制 ###

开启事务之后，往事务中添加的命令如果有命令错误（语法错误），那么整个事务中的命令都不会执行。

redis 127.0.0.1:6379>multi
    "OK"
    
    redis 127.0.0.1:6379>set a1 a
    "QUEUED"
    
    redis 127.0.0.1:6379>sett a2 b
    "ERR unknown command 'sett'"
    
    redis 127.0.0.1:6379>exec
    "EXECABORT Transaction discarded because of previous errors."
    
    redis 127.0.0.1:6379>get a1
    null

上面案例中，开启事务后第一条命令添加返回QUEUED，第二条命令语法错误，最后提交事务。

可以看到，事务提交后 get a1 返回值是null，所以第二条命令的语法错误导致整个事务中的命令都不会执行。

### 运行时错误处理机制 ###

如果语法没有错误，而执行过程中发生了运行时错误，Redis不仅不会回滚事务，还会跳过这个运行时错误，继续向下执行命令

redis 127.0.0.1:6379>lpush l1 a
    "1"
    
    redis 127.0.0.1:6379>lpush l2 b
    "1"
    
    redis 127.0.0.1:6379>lpush l3 c
    "1"
    
    redis 127.0.0.1:6379>multi
    "OK"
    
    redis 127.0.0.1:6379>lpush l1 aa
    "QUEUED"
    
    redis 127.0.0.1:6379>sadd l2 bb
    "QUEUED"
    
    redis 127.0.0.1:6379>lpush l3 cc
    "QUEUED"
    
    redis 127.0.0.1:6379>exec
     1)  "2"
     2)  "WRONGTYPE Operation against a key holding the wrong kind of value"
     3)  "2"

上面这个案例中，先创建了三个List类型 l1、l2、l3，然后开启事务，第一条命令往l1中插入元素，第二条命令使用 sadd 命令往List类型的l2中添加元素，第三天命令往l2中插入元素，最后提交事务。

可以看到最后事务的执行结果是第一条和第三条命令执行成功，第二条命令执行失败，所以第二条命令的执行失败不仅没有回滚事务而且还不会影响后续第三条命令的执行。

## 七、ACID分析 ##

针对Redis的事务实现，对于ACID，个人认为，对于Atomicity和Durability以及Consistency，Redis是不满足的。为什么会对ACID进行分析呢，一部分原因是为了作对比学习，另一部分是因为《Redis设计与实现》19章事务ACID性质里面提到了一些观点，个人不太认同，所以进行了一些对比。

1.  Atomicity  
    原子性，指的是要么不执行，要么全部执行。当其中一部分执行了，但是另外一部分没有执行，那么作为整个事务，是全部要回滚都不执行的，而Redis在执行过程中，如果出现操作和类型不一致，则会导致一部分执行，而一部分错误的情况，即不满足原子性。当然，除去部分失误外，还是能够保证原子性的，但是这并不是严格的原子性要求。
2.  Durability  
    持久性，事务提交后，无论出现任何情况，包括系统断电之类的，重启后都是可以恢复的。对于Redis来说，即使开启了AOF以及设置为always，也存在命令执行一部分后，系统宕机而导致数据不一致的情况，不能恢复。一般都是通过write-ahead-logging来实现的，即事先写日志，而Redis是边执行边写日志。
3.  Consistency  
    一致性，指从一个有效的状态转到另一个有效的状态，不满足上述的两个条件，也无法保存一致性，即会出现中间状态。比如从一个人的账户转到另外一个人上面，执行了转出，但是没有执行转入的时候宕机了，就会导致数据的不一致。
4.  Isolation  
    隔离性，在多个事务并发的情况下，事务之间不会被影响。对于Redis来说，事务的执行是串行的，中途不会插入其它命令的执行，所以是满足隔离性的。

[20190601233553879.png]: /images/20220123/747982fc911b43f2ae8963dde1728a49.png