redis中的事务操作

事务

把一组数据库命令放在一起执行，保证操作原子性，要么同时成功，要么同时失败
允许把一组redis命令放在一起，把命令序列化，然后一起执行，保证部分原子性

multi:用来标记一个事务的开始
例如

multi
set k1 v1 
set k2 v2

这样子就会把命令放到队列中等待执行

exec:用来执行事务队列中的命令

exec //相当于mysql中的提交

redis事务只能保证部分原子性

如果一组命令中，有在压入事务队列过程中发生错误的命令，则在本事务中所有的命令都不执行，能够保证事务的原子性

保持全部原子性

multi
set k3 v3
setaa k4 v4
set k5 v5
exec

因为在setaa是命令错了，在压入队列的时候就报错了，所以这样子是可以保持数据原子性的

保持部分原子性

如果一组命令中，在压入队列过程中正常，但在执行事务队列命令发生了错误，则只会影响发生错误的命令，不会影响其他命令
的执行，不能保证事务的全部原子性

multi
set kk3 vv3
incr kk2 //这里会报错，因为不是数值类型
set kk4 vv4
exec

discard:清除所有已经压入队列中的命令，并且结束整个事务

multi
set kk5 vv5
set kk6 vv6 
sidcard

redis中的乐观锁
watch:监控某一个键，当事务在执行过程中，此键的值如果发生变化，则本事务放弃执行

就是说，如果在某次修改过程中，该键的值发生变化，就会执行失败，这个键变化，就代表在此过程中，别的用户已经修改过了，或者说，改操作如果继续修改下去，数据就会变得不一致了

//客户一执行
set balance 50 //客户的值
set balance1 5000 //服务商的值
set version //被监控的值，该值起到区分是否修改过(本来事务中)
watch version //开启监听
multi //开启事务
desrby balance 20 //客户的值执行减操作
incrby balance1 20 /服务商的值进行加操作

但是在此过程中，该客户在另外一个终端也进行了操作

客户二的操作

set version 2

所以，在该次操作中，就已经是被改过了，由于客户一的执行并没有结束，所以继续执行就会发生失败了
客户一的操作

顺序:客户一在监听version键后，事务还没有执行结束，客户二在客户一监听version键后，去改变了version的值，然后客户一再去操作

放弃监控所有键

unwatch:放弃监控所有键

单独的隔离操作：

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

不保证事务的原子性：

redis同一个事务如果一条命令执行失败，其后的命令依然会被执行，redis的事务没有回滚。redis已经在系统内部进行功能简化，因为可以保证更快的运行速度，所有redis是不需要回滚事务的