1、事务

1、概念

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

事务运行步骤

开启事务 multi
命令入队（…）
执行事务 exec

2、命令

1）开启事务 `multi`

2）执行事务 `exec`

# 开启事务
127.0.0.1:6379> multi
OK

# 命令入队
127.0.0.1:6379(TX)> set k1 v1
QUEUED
127.0.0.1:6379(TX)> set k2 v2
QUEUED
127.0.0.1:6379(TX)> get k2
QUEUED
127.0.0.1:6379(TX)> set k3 v3
QUEUED

# 执行事务
127.0.0.1:6379(TX)> exec
1) OK
2) OK
3) "v2"
4) OK

127.0.0.1:6379> keys *
1) "k2"
2) "k3"
3) "k1"

3）放弃事务 `discard`

# 开启事务
127.0.0.1:6379> multi
OK

# 命令入队
127.0.0.1:6379(TX)> set k1 v1
QUEUED
127.0.0.1:6379(TX)> set k2 v2
QUEUED
127.0.0.1:6379(TX)> set k3 v3
QUEUED

# 放弃事务
127.0.0.1:6379(TX)> discard
OK

# 事务取消；set k3 v3并未执行，所以结果为nil
127.0.0.1:6379> get k3
(nil)

3、异常

1）编译型异常

编译型异常（代码有问题！命令有错！），事务中所有的命令都不会被执行！

# 开启事务
127.0.0.1:6379> multi
OK

# 命令入列
127.0.0.1:6379(TX)> set k1 v1
QUEUED
127.0.0.1:6379(TX)> set k2 v2
QUEUED
127.0.0.1:6379(TX)> set k3 v3
QUEUED

# 错误命令：参数不全，编译时出错
127.0.0.1:6379(TX)> getset k3
(error) ERR wrong number of arguments for 'getset' command

127.0.0.1:6379(TX)> set k4 v4
QUEUED

# 执行事务：未通过编译，出错；所有事务操作不执行
127.0.0.1:6379(TX)> exec
(error) EXECABORT Transaction discarded because of previous errors.

# 因为所有事务命令不执行，所以查询结果为nil
127.0.0.1:6379> get k4
(nil)

2）运行型异常

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

# 设置k1的值为字符串v1
127.0.0.1:6379> set k1 v1
OK

# 开启事务
127.0.0.1:6379> multi
OK

# 命令入列
# k1的值自增1，由于k1的值是字符串，不能自增，运行时将出错，但可以通过编译
127.0.0.1:6379(TX)> incr k1 
QUEUED

127.0.0.1:6379(TX)> set k2 v2
QUEUED
127.0.0.1:6379(TX)> set k3 v3
QUEUED
127.0.0.1:6379(TX)> get k3
QUEUED

# 执行事务
127.0.0.1:6379(TX)> exec
1) (error) ERR value is not an integer or out of range # 任务1出错
2) OK # 正常执行
3) OK # 正常执行
4) "v3" # 正常执行

# 查询正常
127.0.0.1:6379> get k2
"v2"
127.0.0.1:6379> get k3
"v3"

2、乐观锁

悲观锁：

很悲观，认为什么时候都会出问题，无论做什么都会加锁！效率低

乐观锁：

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

监控！ Watch

在 Redis 中使用 watch 命令可以决定事务是执行还是回滚。一般而言，可以在 multi 命令之前使用 watch 命令监控某些键值对，然后使用 multi 命令开启事务，执行各类对数据结构进行操作的命令，这个时候这些命令就会进入队列。

当 Redis 使用 exec 命令执行事务的时候，它首先会去比对被 watch 命令所监控的键值对，如果没有发生变化，那么它会执行事务队列中的命令，提交事务；如果发生变化，那么它不会执行任何事务中的命令，而去事务回滚。无论事务是否回滚，Redis 都会去取消执行事务前的 watch 命令，这个过程如图 1 所示。

Redis 监控测试

正常执行成功

# 设置总金额账户为 100
127.0.0.1:6379> set money 100
OK
# 设置支出账户为 0
127.0.0.1:6379> set out 0
OK
# 监视总金额账户 money
127.0.0.1:6379> watch money
OK

# 开启事务
127.0.0.1:6379> multi # 事务正常结束，执行期间没有发生变动，这个时候就正常执行成功！
OK
# 命令入列
# 消费：总金额账户减20
127.0.0.1:6379(TX)> decrby money 20
QUEUED
# 支出账户增20
127.0.0.1:6379(TX)> incrby out 20
QUEUED
# 执行事务
# 事务正常结束，执行期间没有发生变动
127.0.0.1:6379(TX)> exec
1) (integer) 80 # 总金额账户变为80
2) (integer) 20 # 支出账户变为20

模拟多线程

开启两个窗口：一个窗口正常执行事务，在执行过程中，另一个窗口修改监视的对象

# 窗口一：正常执行事务

# 监视money
127.0.0.1:6379> watch money
OK

# 开启事务
127.0.0.1:6379> multi
OK
# 命令入列
127.0.0.1:6379(TX)> decrby money 10
QUEUED
127.0.0.1:6379(TX)> incrby out 10
QUEUED

# ------------------------
# 此时执行窗口二：修改money
# ------------------------

# 执行事务：失败
127.0.0.1:6379(TX)> exec
(nil)

127.0.0.1:6379> get money
"180"

# 窗口二：修改money；在窗口一中监视money之后执行

[root@bogon bin]# redis-cli
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> keys *
1) "money"
2) "out"

127.0.0.1:6379> incrby money 100
(integer) 180