【redis】-- redis的事务

迈不过友情╰ 2023-07-06 14:31 97阅读 0赞

### 文章目录 ###

*   *  1.redis事务的执行流程
     *  2.事务开始
     *  3.命令入队
     *   *  事务队列
     *  4.命令的执行
     *  5.watch命令
     *  6.放弃事务（\[DISCARD\](http://redis.cn/commands/discard.html)）
     *  7.事务的ACID属性
     *   *  1.原子性
         *  redis不支持回滚
         *  redis不支持事务回滚的原因：
         *  2.一致性
         *  3.隔离性
         *  4.持久性

Redis通过MULTI、EXEC、WATCH等命令来实现事务( transaction)功能。事务提供了一种将多个命令请求打包，然后- -次性、按顺序地执行多个命令的机制，并且在事务执行期间，服务器不会中断事务而改去执行其他客户端的命令请求，它会将事务中的所有命令都执行完毕，然后才去处理其他客户端的命令请求。

## 1.redis事务的执行流程 ##

在讲解事务前先简单介绍一下，有关事务的两个命令

*  multi：标记一个事务块的开始。 随后的指令将在执行EXEC时作为一个原子执行。

MULTI

*  exec：执行事务中所有在排队等待的指令并将链接状态恢复到正常 当使用WATCH 时，只有当被监视的键没有被修改，且允许检查设定机制时，EXEC会被执行

EXEC

故redis事务的执行流程是：先使用multi命令开启事务模式，然后输入要执行的代码。输入结束后，输入exec命令，执行刚才输入的命令：

127.0.0.1:6379> multi
    OK
    127.0.0.1:6379> set a 1
    QUEUED
    127.0.0.1:6379> set b 2
    QUEUED
    127.0.0.1:6379> get a
    QUEUED
    127.0.0.1:6379> exec
    1) OK
    2) OK
    3) "1"
    127.0.0.1:6379>

在执行exec指令后，redis会把每一天输入指令的执行结果输出到屏幕上。  
**一个事务从开始到结束通常会经历以下三个阶段:**

**1)事务开始。**

**2)命令人队。**

**3)事务执行。**

## 2.事务开始 ##

执行multi命令表示事务开始；

MULTI命令可以将执行该命令的客户端从非事务状态切换至事务状态，这- -切换是通

过在客户端状态的flags属性中打开REDIS\_ MULTI标识来完成的。

## 3.命令入队 ##

在非事务的情况下，向redis客户端输入的命令，会被立即执行，而在事务的情况下，指令的执行会有所不同：

*  如果客户端发送的命令为EXEC、DISCARD、WATCH、MULTI四个命令的其中一个，那么服务器立即执行这个命令。
 *  与此相反，如果客户端发送的命令是EXEC、DISCARD、WATCH、MULTI四个命令以外的其他命令，那么服务器并不立即执行这个命令，而是将这个命令放入一个事务队列里面，然后向客户端返回QUEUED回复。

![图片][format_png]

### 事务队列 ###

因为输入进redis客户端的命令不会立即执行，所以当我们输入命令后，redis会把我们输入的命令都放入一个数组队列中（即以队列的形式来安排数据的添加和删除，以数组来存储数据）。如执行以下命令：

127.0.0.1:6379> MULTI
    OK
    127.0.0.1:6379> SET "name" "Practical Common Li sp"
    QUEUED
    127.0.0.1:6379>  GET "name" 
    QUEUED
    127.0.0.1:6379>  SET "author" "Peter Seibel "
    QUEUED
    127.0.0.1:6379> GET "author"
    QUEUED

那么在redis中这些命令会被存入一个数组队列：  
![图片][format_png 1]

## 4.命令的执行 ##

当执行EXEC命令后，redis会遍历命令入队过程中的数组，按照先后顺序依次执行命令，并把命令执行的结果，返回显示在屏幕上：

127.0.0.1:6379> exec
    1) OK
    2) Practical Common Li sp3)
    3） OK
    4) "Peter Seibel "

## 5.watch命令 ##

WATCH命令是一个 乐观锁( optimistic locking),它可以在EXEC命令执行之前，监视任意数量的数据库键，并在EXEC命令执行时，检查被监视的键是否至少有-一个已经被修改过了，如果是的话，服务器将拒绝执行事务，并向客户端返回代表事务执行失败的空回复。

> 使用 check-and-set 操作实现乐观锁  
> WATCH 命令可以为 Redis 事务提供 check-and-set （CAS）行为。  
> 被 WATCH 的键会被监视，并会发觉这些键是否被改动过了。 如果有至少一个被监视的键在 EXEC 执行之前被修改了， 那么整个事务都会被取消， EXEC 返回nil-reply来表示事务已经失败。  
> 举个例子， 假设我们需要原子性地为某个值进行增 1 操作（假设 INCR 不存在）。  
> 首先我们可能会这样做：  
> val = GET mykey  
> val = val + 1  
> SET mykey $val  
> 上面的这个实现在只有一个客户端的时候可以执行得很好。 但是， 当多个客户端同时对同一个键进行这样的操作时， 就会产生竞争条件。举个例子， 如果客户端 A 和 B 都读取了键原来的值， 比如 10 ， 那么两个客户端都会将键的值设为 11 ， 但正确的结果应该是 12 才对。  
> 有了 WATCH ， 我们就可以轻松地解决这类问题了：  
> WATCH mykey  
> val = GET mykey  
> val = val + 1  
> MULTI  
> SET mykey $val  
> EXEC  
> 使用上面的代码， 如果在 WATCH 执行之后， EXEC 执行之前， 有其他客户端修改了 mykey 的值， 那么当前客户端的事务就会失败。 程序需要做的， 就是不断重试这个操作， 直到没有发生碰撞为止。  
> 这种形式的锁被称作乐观锁， 它是一种非常强大的锁机制。 并且因为大多数情况下， 不同的客户端会访问不同的键， 碰撞的情况一般都很少， 所以通常并不需要进行重试。

## 6.放弃事务（[DISCARD][]） ##

*  discard：刷新一个事务中所有在排队等待的指令，并且将连接状态恢复到正常。如果已使用WATCH，DISCARD将释放所有被WATCH的key。

## 7.事务的ACID属性 ##

在Redis中，事务总是具有原子性(Atomicity)、一致性(Consistency)和隔离性( Isolation),并且当Redis运行在某种特定的持久化模式下时，事务也具有耐久性( Durability )。

### 1.原子性 ###

事务具有原子性指的是，数据库将事务中的多个操作当作-一个整体来执行,服务器要么就执行事务中的所有操作，要么就一个操作也不执行。

对于Redis的事务功能来说，事务队列中的命令要么就全部都执行，要么就-一个都不执行，因此，Redis 的事务是具有原子性的。

### redis不支持回滚 ###

redis与传统关系型最大的区别是，redis不支持事务回滚，即如果在exec执行命令的过程中，某条指令出现错误，redis会继续执行后面的语句，而不会回滚到事务开启前的状态。即执行过程中的错误不影响，事务的执行：

127.0.0.1:6379> multi
    OK
    127.0.0.1:6379> set w a a
    QUEUED
    127.0.0.1:6379> set hh 12
    QUEUED
    127.0.0.1:6379> get hh
    QUEUED
    127.0.0.1:6379> exec
    1) (error) ERR syntax error
    2) OK
    3) "12"

例子中第一条指令在执行时发生错误，但依旧可以执行后面的语句。

### redis不支持事务回滚的原因： ###

Redis的作者在事务功能的文档中解释说，**不支持事务回滚是因为这种复杂的功能和Redis追求简单高效的设计主旨不相符**，并且他认为，**Redis事务的执行时错误通常都是编程错误产生的，这种错误通常只会出现在开发环境中，而很少会在实际的生产环境中出现，所以他认为没有必要为Redis开发事务回滚功能。**

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

### 2.一致性 ###

事务具有一致性指的是，如果数据库在执行事务之前是一致的，那么在事务执行之后,无论事务是否执行成功，数据库也应该仍然是一致的。

“一致”指的是数据符合数据库本身的定义和要求，没有包含非法或者无效的错误数据。Redis通过谨慎的错误检测和简单的设计来保证事务的一致性，以下三个小节将分别介绍三个Redis事务可能出错的地方，并说明Redis是如何妥善地处理这些错误，从而确保事务的一致性的。

**1.入队错误**

如果redis在开启事务后的输入指令时，输入的某一指令出现格式错误，或指令不存在，那么redis会拒绝执行事务。此时没有数据的输入所以数据库中的数据是一致的。

> Redis 2.6.5以前的入队错误处理  
> 根据文档记录，在Redis 2.6.5以前的版本，即使有命令在入队过程中发生了错误，事务一样可以执行，不过被执行的命令只包括那些正确入队的命令。以下这段代码是在Redis 2.6.4版本上测试的，可以看到，事务可以正常执行，但只有成功入队的SET命令和GET命令被执行了，而错误的YAH0000则被忽略了:  
> redis> MULTI  
> OK  
> redis> SET msg “he11o”  
> QUEUED  
> redis> YAH000O  
> (error) ERR unknown command ’ YAHO000’  
> redis> GET msg  
> QUEUED  
> redis> EXEC
> 
> 1.  0K
> 2.  “hello”

**2.执行错误**

在讨论redis不支持事务回滚时，就讨论过该问题，因为错误的指令不会存入数据库，而正确的指令都存入了数据库，所以执行错误也不会影响redis的一致性。

**3.服务器停机**

服务器出现停机，那么如果没有开启rdb或aof那么数据库所有数据都会消失，不影响一致性，而有rdb或aof时会根据这两个把数据再次装入数据库，所以这种情况下redis的数据也是一致的。

### 3.隔离性 ###

redis是单线程的，无论并发量多大，进入redis后，都是串行执行，所以并发情况和串行情况下在开启事务后，也是一样。

因为Redis使用单线程的方式来执行事务(以及事务队列中的命令),并且服务器保证,在执行事务期间不会对事务进行中断，因此，Redis的事务总是以串行的方式运行的，并且事务也总是具有隔离性的。

### 4.持久性 ###

事务的耐久性指的是，当一个事务执行完毕时，执行这个事务所得的结果已经被保存到永久性存储介质(比如硬盘)里面了，即使服务器在事务执行完毕之后停机，执行事务所得的结果也不会丢失。

> 因为Redis的事务不过是简单地用队列包裹起了–组Redis命令，Redis并没有为事务提供任何额外的持久化功能，所以Redis事务的耐久性由Redis所使用的持久化模式决定:  
> 当服务器在无持久化的内存模式下运作时，事务不具有耐久性:一旦服务器停机，包括事务数据在内的所有服务器数据都将丢失。  
> 当服务器在RDB持久化模式下运作时，服务器只会在特定的保存条件被满足时，才会执行BGSAVE命令，对数据库进行保存操作，并且异步执行的BGSAVE不能保证事务数据被第一时间保存到硬盘里面，因此RDB持久化模式下的事务也不具有耐久性。  
> 当服务器运行在AOF持久化模式下，并且appendfsync选项的值为always时,程序总会在执行命令之后调用同步(sync) 函数，将命令数据真正地保存到硬盘里面，因此这种配置下的事务是具有耐久性的。  
> 当服务器运行在AOF持久化模式下，并且appendfsync选项的值为everysec时，程序会每秒同步–次命令数据到硬盘。因为停机可能会恰好发生在等待同步的那一秒钟之内，这可能会造成事务数据丢失，所以这种配置下的事务不具有耐久性。

文章部分参考：

《redis设计与实现(第二版)》

redis中文官网：[http://redis.cn/topics/transactions.html][http_redis.cn_topics_transactions.html]

[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWRlci5zaGltby5pbS9mL1N2RnhkdGsxVHJJdEx3azcucG5nIXRodW1ibmFpbA?x-oss-process=image/format,png
[format_png 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWRlci5zaGltby5pbS9mLzJ1d3JWYUFLd3ZzaE1Fa1oucG5nIXRodW1ibmFpbA?x-oss-process=image/format,png
[DISCARD]: http://redis.cn/commands/discard.html
[http_redis.cn_topics_transactions.html]: http://redis.cn/topics/transactions.html