Redis（2）——事务机制

Redis的事务机制

• Redis的事务本质：一组命令的集合
• 一个事务中的所有命令都会都被序列化，在事务执行的过程中，会按照顺序执行！
• 一次性、顺序性、排他性——执行一系列的命令
• Redis没有事务隔离级别的概念
• 所有命令在事务中，并没有直接被执行！只有发起执行命令（Exec）才会执行！
• Redis的单挑命令保存原子性，但是事务不保证原子性。

Redis的事务使用过程

1. 开启事务——multi
2. 命令入队—— ...
3. 执行事务——exec

正常执行事务

127.0.0.1:6379> multi         #命开启事务
OK
127.0.0.1:6379> set key1 v1   #命令入队
QUEUED
127.0.0.1:6379> set key2 v2   #命令入队
QUEUED
127.0.0.1:6379> get key2      #命令入队
QUEUED
127.0.0.1:6379> set key3 v3   #命令入队
QUEUED
127.0.0.1:6379> exec		#执行事务
1) OK
2) OK
3) "v2"
4) OK

事务执行结束，队列就消失了，再去get会返回nil

放弃事务

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 k4 v4
QUEUED
127.0.0.1:6379> discard   # 放弃事务
OK
127.0.0.1:6379> get k3    # 事务队列中的命令都不会执行
(nil)

编译型异常（命令有错）

事务中所有的命令都不会被执行

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 v3
QUEUED
127.0.0.1:6379> getset k3  #错误命令
(error) ERR wrong number of arguments for 'getset' command
127.0.0.1:6379> set k4 v4
QUEUED
127.0.0.1:6379> set k5 v5
QUEUED
127.0.0.1:6379> exec   #执行事务报错
(error) EXECABORT Transaction discarded because of previous errors.   
127.0.0.1:6379> get k5   #所有命令都不会被执行
(nil)

我们在使用getset命令时少写了一个参数，这是命令错误，所以在执行事务是会报错，最终所有的命令都不会被执行。

执行时异常

如果事务队列中存在语法性错误，执行命令的时候，其他命令可以正常执行，错误命令抛出异常

127.0.0.1:6379> set k1 "v1"  #字符串无法+1
OK
127.0.0.1:6379> multi
OK  
127.0.0.1:6379> incr k1   #执行至此会失败
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> set k3 v3
QUEUED
127.0.0.1:6379> get k3
QUEUED
127.0.0.1:6379> exec    #执行事务是，第一个命令执行出错，其他命令依旧会执行
1) (error) ERR value is not an integer or out of range
2) OK
3) OK
4) "v3"
127.0.0.1:6379> get k2
"v2"
127.0.0.1:6379> get k3
"v3"

Redis的乐观锁 Watch

悲观锁：

• 很悲观，认为什么时候都会出问题，无论做什么都会加锁！但是影响效率！

乐观锁：

• 很乐观，认为什么时候都不会出问题，所以不会加锁！
• 更新数据时去判断一下，在此期间是否有人修改过这个数据！
• MySQL的version的使用：先获取version，更新数据时比较version，看version 是否被修改

Redis的监视测试

正常执行成功

127.0.0.1:6379> set money 100 
OK
127.0.0.1:6379> set out 0 
OK
127.0.0.1:6379> watch money   #监视money对象 
OK
127.0.0.1:6379> multi   #事务正常结束，数据期间没有发生变动，这个时候就正常执行成功 
OK
127.0.0.1:6379> decrby money 20 
QUEUED 
127.0.0.1:6379> incrby out 20 
QUEUED 
127.0.0.1:6379> exec 
1) (integer) 80 
2) (integer) 20 

多线程修改

线程1：

127.0.0.1:6379> get money
"80"
127.0.0.1:6379> set money 1000
OK

线程2：

127.0.0.1:6379> watch money
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decrby money 10
QUEUED
127.0.0.1:6379> incrby out 10
QUEUED
127.0.0.1:6379> exec
(nil)

在线程2的exec命令执行之前，A客户端执行了set命令修改了money的值，就会导致事务执行失败。

watch监视后的事务执行失败后，可以使用unwatch解锁后重新开始监视：

127.0.0.1:6379> unwatch
OK
127.0.0.1:6379> watch money       #获取最新的值，再次监视
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decrby money 10
QUEUED
127.0.0.1:6379> incrby out 10
QUEUED
127.0.0.1:6379> exec
1) (integer) 990
2) (integer) 10

此时exec时，比对监视的值是否发生变化，如果没有变化，可以执行成功，如果变量被修改 了，执行失败