Redis基本的事务操作multi开启-exec执行-discard取消，和Redis的乐观锁

Redis事务本质:一组命令的集合!一个事务中的所有命令都会被序列化，在事务执行过程的中，会按照顺序执行!
一次性、顺序性、排他性!执行一系列的命令!

---------------队列  set  set  set 队列-----------------

Redis事务没有隔离级别的概念
所有的命令在事务中，并没有直接被执行！只有发起执行命令的时候才会执行! exec
Redis单条命令式保存原子性的，但是事务不保证原子性!
Redis的事务：
1、开启事务（multi）
2、命令入队（…）
3、执行事务（exec）

正常执行事务：multi->命令->exec

每次事务执行之后，就结束了，再要用的时候要再multi开启事务

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

放弃事务：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 k4 v4
QUEUED
127.0.0.1:6379(TX)> discard   # 放弃事务
OK
127.0.0.1:6379> get k4   # 由于上面放弃了，没有执行事务，所有没有k4，事务队列中的命令都不会被执行
(nil)

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

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)> set k5 v5
QUEUED
127.0.0.1:6379(TX)> exec  # 由于有错误的命令，所以执行报错
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get k5   # 所有的命令都不会被执行
(nil)

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

127.0.0.1:6379> set k1 "v1"
OK
127.0.0.1:6379> multi   # 开启事务
OK
127.0.0.1:6379(TX)> incr 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)> get k3   # 进入队列
QUEUED
127.0.0.1:6379(TX)> 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

悲观锁：很悲观，认为什么时候都会出问题，无论做什么都会加锁!

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

• 获取version
• 更新的时候比较version

Redis监视测试

watch监视，事务执行完之后，会取消监视

正常执行成功：

127.0.0.1:6379> set money 100   # 设置钱包里有100块
OK
127.0.0.1:6379> set out 0   # 花了0元
OK
127.0.0.1:6379> watch money   # 使用watch监视钱包
OK
127.0.0.1:6379> multi   # 开启事务
OK
127.0.0.1:6379(TX)> decrby money 20   # 钱包减少20块
QUEUED
127.0.0.1:6379(TX)> incrby out 20   # 花费了20块
QUEUED
127.0.0.1:6379(TX)> exec   #事务正常结束，数据期间没有发生变动，这个时候就正常执行成功!
1) (integer) 80
2) (integer) 20

测试多线程修改值，使用watch可以当做redis的乐观锁操作!

127.0.0.1:6379> watch money   # 监视money
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> decrby money 20
QUEUED
127.0.0.1:6379(TX)> incrby out 20  # 命令入队
QUEUED
127.0.0.1:6379(TX)>      # 但是此时我不执行exec

换一个连接（双击标题），去修改money

127.0.0.1:6379> set money 1000   # 打开新的一个连接，连接上redis，把这个money值修改
OK

另一边修改money之后，这边的事务就会执行失败了，因为money被监视过程中，被其他线程修改了

127.0.0.1:6379> watch money
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> decrby money 20
QUEUED
127.0.0.1:6379(TX)> incrby out 20
QUEUED
127.0.0.1:6379(TX)> exec    # 被修改为1000之后，再进行执行事务
(nil)   # 返回空nil说明失败

解决办法：解锁加锁再来一次

127.0.0.1:6379> unwatch   # 1、如果发现事务执行失败，就先解锁，停止监视
OK
127.0.0.1:6379> watch money  # 2、获取最新的值，再次监视
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> decrby money 1
QUEUED
127.0.0.1:6379(TX)> exec  # 对比监视的值是否发生变化，如果没有变化则可以执行成功，如果有变化则又执行失败
1) (integer) 999