Redis 事务

ゝ一纸荒年。 2022-06-05 10:23 211阅读 0赞

# Redis 事务 #

> 可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会序列化，按顺序地串行化执行而不会被其他命令插入，不许加塞。

在一个队列中，一次性、顺序性、排他性的执行一系列命令。

## 常用命令 ##

DISCARD 取消事务，放弃执行事务块内的所有命令。

EXEC 执行所有事务块内的命令。

MULTI 标记一个事务块的开始。

UNWATCH 取消 WATCH 命令对所有 key 的监视。

WATCH key [key...] 监视一个或多个key，如果在事务执行之前这个（或这些） key 被其它命令所改动，那么事务将被打断。

## Redis 事务正常执行 ##

![这里写图片描述][SouthEast]

上面的演示，通过了 MULTI 开启事务，通过 EXEC 执行所有事务命令。  
更加 说明，事务是一个命令集合。

## Redis 放弃事务 ##

![这里写图片描述][SouthEast 1]

上面的命令是 通过 MULTI 开始事务，中间设置了很多个 key 值，然后通过 DISCARD 放弃事务。

## Redis 事务要么全部执行，要么全部失败 ##

![这里写图片描述][SouthEast 2]

上面通过 MULTI 开启了事务，中间输入了几个正常命令，但是包含错误命令，当提交后执行后，发现正确的命令也没有执行，说明 Redis 事务特性也是和 MySQL 特性一样，要么都成功，要么都失败。

但是这种条件是 事务中 有个命令不是 Redis 规定内的命令，而是一个错误的乱写的命令，这才会导致整个事务不会执行。

## Redis 对事务的支持，其实是部分支持 ##

![这里写图片描述][SouthEast 3]

上面的命令中，中间没有出现任何语法错误的命令，只是出现了一个 v1 不能加一的操作，和本例上面的一个例子相比，上一个出现了语法错误，这个例子没有出现语法错误，出现语法错误的整个事务都没有执行，而没有出现语法错误，只是运行后出错的是部分正确命令执行。所以 Redis 事务是部分支持。

## 总结 ##

Redis 对事务的支持是部分支持。

## watch 监控 ##

悲观锁/乐观锁/CAS (Check And Set)

### 悲观锁 ###

***悲观锁（Pessimistic Lock），顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上排他锁，这样别人想拿这个数据就会 block 直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。***

### 乐观锁 ###

***乐观锁（Optimistic Lock），顾明思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。***

乐观锁策略：提交版本必须大于记录当前版本才能执行更新。

### 演示 Redis 中 WATCH 的作用 ###

#### WATCH 逆向流，WATCH 监控的数据被修改，导致 WATCH 后的事务执行失败。 ####

![这里写图片描述][SouthEast 4]

> 上面过程是初始化演示数据。

![这里写图片描述][SouthEast 5]

> WATCH 是和 Redis 事务一起使用的命令，是为了解决并发过程中数据被篡改引发线程安全的东西。  
> 上面的过程是：用 WATCH 监控了 balance 这个 key，作用是防止在监控那一个时刻起，如果被本地连接或其它连接修改被监控数据的话，不管 WATCH 后的第一个事务是否访问被监控数据，第一个事务绝对会执行失败，并且也将自动取消 WATCH 监控的所有数据。如果你还是想要让事务里面的操作执行成功的话，你就必须要重复执行 WATCH + 事务，直到执行成功为止。

#### WATCH 正向流，WATCH 监控的数据那一刻后，被监控数据没有被改动，事务执行成功！！！ ####

![这里写图片描述][SouthEast 6]

#### 如果 WATCH 后本地连接修改了被监控数据，那么自己可以通过 UNWATCH 取消数据的监控，注意，UNWATCH 命令将会取消对所有被监控数据的监控。 ####

![这里写图片描述][SouthEast 7]

## 总结 ##

*  一旦执行 EXEC 之前加的监控锁都会被取消掉。也就是第一个 事务 执行后，之前对所有数据加的监控都会被自动取消掉。
 *  WATCH 指令，类似乐观锁，事务提交时，如果 key 的值已被别的客户端或者本地客户端改变，比如某个 list 已被别的客户端或本地客户端 push/pop 过了，第一个整个事务队列都不会被执行，并且自动取消 WATCH 对所有数据的监控。
 *  通过 WATCH 命令在事务执行之前监控了多个 keys ，倘若在 WATCH 之后有任何的值发生了变化，EXEC 命令执行的事务都将被放弃，同时返回 Nullmulti-bulk 应答以通知调用者事务执行失败，并且自动取消所有数据的 WATCH 监控。
 *  当 MULTI 开启一个事务后，后面在事务中添加的所有命令都将不会立即执行，而是放到等待执行的事务队列里面，事务的执行由 EXEC 命令触发。

> 单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。  
> 没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，也就不存在“事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头疼的问题。也不会存在事务内 数据 的幻读和不可重复读的问题。  
> 不保证原子性：Redis 同一个事务中如果有一条命令执行失败（排除语法错误命令情况，这里的执行失败是，语法正确，但是命令还是执行失败），其后的命令仍然会被执行，没有回滚。

[SouthEast]: /images/20220605/8141556bf94448018d96bd97c2687425.png
[SouthEast 1]: /images/20220605/5cecf5a689cb456f9a9a819b72bcce3d.png
[SouthEast 2]: /images/20220605/4300271716044c86a9143ae28c4ccfee.png
[SouthEast 3]: /images/20220605/ab2be147cb414a429ab04860c4779659.png
[SouthEast 4]: /images/20220605/199bd59548794eecb931eef8c8265149.png
[SouthEast 5]: /images/20220605/2b7b8d8021024bffaaf871d9800e4ead.png
[SouthEast 6]: /images/20220605/1c16880a407e497fb56c70a03d832e56.png
[SouthEast 7]: /images/20220605/5fab88bf4a2f48dbbd69812024ce4167.png