[redis学习笔记]五、Redis事务的使用

Redis的事务

概述

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

简单地说，就是将一系列的命令按顺序地加入到一个队列中，一次性地、顺序地、排他地执行这些命令。

常用命令

使用

步骤大致为：multi(开启事务)–>一系列的命令–>exec/discard(执行事务或放弃执行事务)

正常执行

## 开启事务
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> get k1
QUEUED
## 执行事务
127.0.0.1:6379> EXEC
1) OK
2) OK
3) "v1"

可以发现，一系列的命令只是入队QUEUED,而并没有立即执行，而是等待EXEC时才执行

取消事务

## 开启事务
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k3 v3
QUEUED
127.0.0.1:6379> set k4 v4
QUEUED
127.0.0.1:6379> get k4
QUEUED
## 取消事务
127.0.0.1:6379> DISCARD
OK
## 由于事务被取消，命令未被执行 所以k4没有值
127.0.0.1:6379> get k4
(nil)

注意：redis统一事务中执行若干命令，并不能保证原子性

1. 类比Java异常，如果是检查异常，在编码中未抛出时，系统会报错。同理，在redis事务中，某个命令由于redis语法错误执行失败，那么该事务下的所有命令均执行失败。

   127.0.0.1:6379> FLUSHDB
   OK
   127.0.0.1:6379> MULTI
   OK
   127.0.0.1:6379> set k1 v1
   QUEUED
   127.0.0.1:6379> set k2 v2
   QUEUED
   ## 语法错误 抛出异常信息
   127.0.0.1:6379> set k3
   (error) ERR wrong number of arguments for 'set' command
   ## 执行事务时发现有错，事务被取消
   127.0.0.1:6379> EXEC
   (error) EXECABORT Transaction discarded because of previous errors.
   ## 其他正常命令的执行也被取消
   127.0.0.1:6379> get k2
   (nil)
   127.0.0.1:6379> get k1
   (nil)
   

2. 类比Java编译时异常，在redis事务中，某个命令因为参数不合法等问题导致了错误，那么该事务下只会影响当前命令的执行结果，不会影响其他命令的正常执行。

   127.0.0.1:6379> FLUSHDB
   OK
   127.0.0.1:6379> MULTI
   OK
   127.0.0.1:6379> set k1 abcd
   QUEUED
   ## 参数不合法  字符串不能执行+1操作 但是这属于编译异常 这里系统未检出错误 直接入队
   127.0.0.1:6379> INCR k1
   QUEUED
   127.0.0.1:6379> set k2 v2
   QUEUED
   127.0.0.1:6379> get k1
   QUEUED
   127.0.0.1:6379> EXEC
   1) OK
   ## 执行时报错参数问题，但是没有影响其他命令的正常执行
   2) (error) ERR value is not an integer or out of range
   3) OK
   4) "abcd"
   127.0.0.1:6379> get k1
   "abcd"
   127.0.0.1:6379> get k2
   "v2"
   

watch监控

watch监控类似于乐观锁的机制，监控了某key，在事务中真正执行时发现该key可能被其他客户端修改了，那么当前事务执行失败。需要重新监控该key，直至监控时候key的数据跟执行事务时key的数据均一致方可

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

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

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

正常使用

127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
## 同时监控两个key
127.0.0.1:6379> WATCH k1 k2
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 v11
QUEUED
127.0.0.1:6379> set k2 v22
QUEUED
127.0.0.1:6379> get k1
QUEUED
127.0.0.1:6379> get k2
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) OK
3) "v11"
4) "v22"

异常情况

模拟监控key后，key被其他客户端修改。

说明:监控了两个key，分别是k1,k2。但是在事务执行时，k1的值被其他客户端修改过，k1的值相当于watch时被修改过。因此事务执行失败。响应结果nil。

这种情况，只能重新watch，力求key是最新的数据。比如下面这次 就执行成功了

127.0.0.1:6379> WATCH k1 k2
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 v11
QUEUED
127.0.0.1:6379> set k2 v22
QUEUED
127.0.0.1:6379> get k1
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) OK
3) "v11"

unwatch

取消监控，同样地，一旦事务执行完成，之前加到事务上某key的监控锁也会被取消掉。

说明：监控了k1,后来又取消对k1的监控了。在事务执行前，对k1的值进行修改，对事务的正常执行没有影响，k1的值变为v11。因为redis是单线程的，这里推断k1值的变化是：v1->v01->v11

watch总结

watch指令类似于乐观锁，事务提交时，如果key的值已被别的客户端改变，比如某key被别的客户端修改过，那么整个事务队列都不会被执行。

通过WATCH命令在事务执行之前监控了多个Keys(如上面的例子)，倘若在WATCH之后有任何Key的值发生了变化，EXEC命令执行的事务都将被放弃，同时返回nil应答以通知调用者事务执行失败。

总结

事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

事务队列中的命令没有提交之前都不会实际的被执行，所以也就不会有隔离级别的问题。

不保证严格上的原子性操作。