redis事务

Redis的事务

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

作用：在一个队列中，一次性、顺序性、排他性的执行一系列命令。

multi：标记一个事务块的开始，即开启事务；

exec：执行所有事务块内的命令，截图：


；

discard：取消事务，放弃执行事务块内的所有命令，截图：


；

事务内如果有一条命令出错（加入队列的时候就报错），则事务内的所有命令都会执行失败，截图：


；

事务内将命令加入队列的时候没有报错，而是执行事务的时候报错，则正确的命令会被提交，如下图：2到5执行成功，1执行出错，因为k1的值不是数值型的（注意和上图中的区别），由此可见，redis对事务的支持是部分支持。截图：


；

悲观锁/乐观锁/CAS：

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

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

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

watch key [key…]:监视一个或多个key，如果在事务执行之前这些key被其他命令所改动，那么事务将被打断。

实例：信用卡金额：

初始化信用卡可用余额和欠额，balance表示余额，debt表示欠额，初始化时balance=100，debt=0，无加塞篡改，先监控，再开启multi，保证两笔金额变动在同一个事务内，截图：


；

有加塞（即中途有人把值篡改了）篡改的情况：当执行完watch的时候，刚好有人在另一个客户端将balance的值从80改为了800，如图：

，

然后在接着执行multi，然后同样balance-20，debt+20，结果事务失败，成功的时候会返回改变之后具体的值，如图：

（图中红色圈起来的部分应该在watch
balance，不过在修改值之前效果相同）；

unwatch：取消watch命令对所有key的监视。当执行完watch的时候，balance的值刚好被改了，如图：


，

然后执行unwatch，再执行multi及后边的操作，结果事务成功，如图：


；

一旦执行了exec，则之前加的监控锁都会被取消。