【Redis】事务浅析

落日映苍穹つ 2023-01-19 04:39 105阅读 0赞

我们知道 Redis 的单个命令是原子性的（比如 get set mget mset），如果涉及到多个命令的时候，需要把多个命令作为一个不可分割的处理序列，就需要用到事务。

例如用 setnx 实现分布式锁，我们先 set，然后设置对 key 设置 expire， 防止 del 发生异常的时候锁不会被释放，业务处理完了以后再 del，这三个动作我们就希望它们作为一组命令执行。

### 1.事务的用法 ###

<table> 
 <thead> 
  <tr> 
   <th>命令</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>MULTI</td> 
   <td>标记一个事务块的开始</td> 
  </tr> 
  <tr> 
   <td>EXEC</td> 
   <td>执行所有事务块内的命令</td> 
  </tr> 
  <tr> 
   <td>DISCARD</td> 
   <td>取消事务，放弃执行事务块内的所有命令</td> 
  </tr> 
  <tr> 
   <td>WATCH</td> 
   <td>监视一个（或多个）key，如果在事务执行之前这个（或多个）key被其他命令所改动，那么事务将被打断</td> 
  </tr> 
  <tr> 
   <td>UNWATCH</td> 
   <td>取消 WATCH 命令对所有 keys 的监视</td> 
  </tr> 
 </tbody> 
</table>

**multi、exec 命令**

案例场景：tom 和 mic 各有 1000 元，tom 需要向 mic 转账 100 元。 tom 的账户余额减少 100 元，mic 的账户余额增加 100 元。

127.0.0.1:6379> set tom 1000
    OK
    127.0.0.1:6379> set mic 1000
    OK
    127.0.0.1:6379> multi
    OK
    127.0.0.1:6379> decrby tom 100
    QUEUED
    127.0.0.1:6379> incrby mic 100
    QUEUED
    127.0.0.1:6379> exec
    1) (integer) 900
    2) (integer) 1100
    127.0.0.1:6379> get tom
    "900" 
    127.0.0.1:6379> get mic
    "1100"

通过 multi 的命令开启事务。事务不能嵌套，多个 multi 命令效果一样。 multi 执行后，客户端可以继续向服务器发送任意多条命令， 这些命令不会立即被执行， 而是被放到一个队列中， 当 exec 命令被调用时， 所有队列中的命令才会被执行。

通过 exec 的命令执行事务。如果没有执行 exec，所有的命令都不会被执行。

**discard 命令**

如果中途不想执行事务了，怎么办？ 可以调用 discard 可以清空事务队列，放弃执行

multi
    set k1 1
    set k2 2
    set k3 3
    discard

**watch 命令**

在 Redis 中还提供了一个 watch 命令。 它可以为 Redis 事务提供 CAS 乐观锁行为（Check and Set / Compare and Swap），也就是多个线程更新变量的时候，会跟原值做比较，只有它没有被其他线程修改的情况下，才更新成新的值。

我们可以用 watch 监视一个或者多个 key，如果开启事务之后，至少有一个被监视 key 键在 exec 执行之前被修改了， 那么整个事务都会被取消（key 提前过期除外）。可以用 unwatch 取消

<table> 
 <thead> 
  <tr> 
   <th align="left">client 1</th> 
   <th align="left">client 2</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">127.0.0.1:6379&gt; set balance 1000<br>OK<br>127.0.0.1:6379&gt; watch balance<br>OK<br>127.0.0.1:6379&gt; multi<br>OK<br>127.0.0.1:6379&gt; incrby balance 100<br>QUEUED</td> 
   <td align="left"></td> 
  </tr> 
  <tr> 
   <td align="left"></td> 
   <td align="left">127.0.0.1:6379&gt; decrby balance 100<br>(integer) 900</td> 
  </tr> 
  <tr> 
   <td align="left">127.0.0.1:6379&gt; exec<br>(nil)<br>127.0.0.1:6379&gt; get balance<br>"900"</td> 
   <td align="left"></td> 
  </tr> 
 </tbody> 
</table>

### 2.事务可能遇到的问题 ###

我们把事务执行遇到的问题分成两种，一种是在执行 exec 之前发生错误，一种是在执行 exec 之后发生错误

**在执行 exec 之前发生错误**

比如：入队的命令存在语法错误，包括参数数量，参数名等等，属于编译错误

127.0.0.1:6379> multi
    OK
    127.0.0.1:6379> set k1 666
    QUEUED
    127.0.0.1:6379> hset k2 2673
    (error) ERR wrong number of arguments for 'hset' command
    127.0.0.1:6379> exec
    (error) EXECABORT Transaction discarded because of previous errors

在这种情况下事务会被拒绝执行，也就是队列中所有的命令都不会得到执行

**在执行 exec 之后发生错误**

比如，类型错误，比如对 String 使用了 Hash 的命令，这是一种运行时错误

127.0.0.1:6379> flushall
    OK
    127.0.0.1:6379> multi
    OK
    127.0.0.1:6379> set k1 1
    QUEUED
    127.0.0.1:6379> hset k1 a b
    QUEUED
    127.0.0.1:6379> exec
    1) OK
    2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
    127.0.0.1:6379> get k1
    "1"

最后我们发现 set k1 1 的命令是成功的，也就是在这种发生了运行时异常的情况下， 只有错误的命令没有被执行，但是其他命令没有受到影响。

这个显然不符合我们对原子性的定义，也就是我们没办法用 Redis 的这种事务机制来实现原子性，保证数据的一致。

### 3.为什么 Redis 事务不支持回滚 ###

对于我们平常使用惯了 Mysql 等关系型数据库，那么对于 Redis 的事务失败时不回滚，而是继续执行余下的命令”这种做法可能会觉得有点奇怪。

以下是官方的说法：

*  Redis 命令只会因为错误的语法而失败（并且这些问题不能在入队时发现），或是命令用在了错误类型的键上面：这也就是说，从实用性的角度来说，失败的命令是由编程错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中。
 *  因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速。

有种观点认为 Redis 处理事务的做法会产生 bug ， 然而需要注意的是， 在通常情况下， 回滚并不能解决编程错误带来的问题。 举个例子， 如果你本来想通过 INCR 命令将键的值加上 1 ， 却不小心加上了 2 ， 又或者对错误类型的键执行了 INCR ， 回滚是没有办法处理这些情况的。

鉴于没有任何机制能避免程序员自己造成的错误， 并且这类错误通常不会在生产环境中出现， 所以 Redis 选择了更简单、更快速的无回滚方式来处理事务。

### 4.总结 ###

Redis 的事务有如下几个特点：

*  按进入队列的顺序执行：事务中的所有命令都会序列化、按顺序地执行。
 *  不受其他客户端请求影响：事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
 *  没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行（也就不存在”事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题）
 *  不保证原子性：Redis 同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚

在传统的关系式数据库中，常常用 ACID 性质来检验事务功能的安全性。Redis 事务保证了其中的一致性（C）和隔离性（I），但并不保证原子性（A）和持久性（D）。