7 Redis的事务

7.1 是什么

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

7.2 能干嘛

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

7.3 怎么玩

7.3.1 常用命令

       ①　DISCARD:取消事物，放弃执行事务块内的所有命令
       ②　EXEC:执行事务块内所有命令
       ③　MULTI:标记一个事务块的开始
       ④　UNWATCH:取消WATCH命令对所有key的监视
       ⑤　WATCH KEY[KEY ….]:如果在事务执行之前这个或者这些key被其他命令所改动，那么事务将被打断。

7.3.2 case1：正常执行

7.3.3 Case2：放弃事务

7.3.4 Case3：全体连坐

       错一个，全部都无法执行。

7.3.5 Case4：冤头债主

       一个错了，但是其他正常执行。

       这种方式和“全体连坐”方式区别：“全体连坐”方式是“set k3”语句上就错了，肯定会直接报错的，但是“冤头债主”模式的“incr k1”在语句上来说是正确的，只是执行后是错误的，就像java代码中，有些代码一写出来就报错了，但是有些代码写出来不报错，运行后才报错一个道理。
       由此看出redis对事物的支持是部分支持。

7.3.6 Case5：watch监控

7.3.6.1 悲观锁/乐观锁/CAS(Check And Set)

       ①　悲观锁
       悲观锁就是认为一定会出事，每次取拿数据的时候都认为别人要修改数据，所以每次都在拿数据的时候会上锁，这样别人想拿这个数据就会block直到它拿到锁，传统的关系型数据库里面就用到了很多这种锁机制，比如行锁，表锁，读锁，写锁等，都是在操作之前上锁。
       ②　乐观锁
       乐观锁不锁整张表，乐观锁既保证高并发也保证不锁整张表，就在每条记录的后面加上一个versio(版本号)。
比如有一条数据，初始时这条数据的version为1，张三要改这条数据的手机号，李四要修改这条数据的微信号，当两人都把这条数据查出来的时候，两人查到的version都为1，当李四先修改好提交后，数据库中的版本号为2了，然后张三也修改好要提交到数据库了，此时会报错，因为张三手里的版本号为1，更新后放到数据库应该为2，但是此时冲突了，那就应该把此时数据库中新的版本的数据查出来修改后再提交。乐观锁策略：提交版本必须大于记录当前版本才能执行更新。
在工作中主要用乐观锁。
       ③　CAS

7.3.6.2 采用信用卡模型来举例

       ①　初始化信用卡可用余额和欠额

       ②　无加塞篡改，先监控再开启multi，保证两笔金额变动在同一个事务内

       ③　有加塞篡改，监控了key，如果key被修改了，后面一个事务的执行失效

7.3.6.3 unwatch

       执行unwanted就是为了预防信用卡例子中有加塞篡改的情况出现。

7.3.6.4 监控锁的取消

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

7.3.6.5 小结

       ①　Watch指令，类似乐观锁，事务提交时，如果Key的值已被别的客户端改变，比如某个list已被别的客户端push/pop过了，整个事务队列都不会被执行
       ②　通过WATCH命令在事务执行之前监控了多个Keys，倘若在WATCH之后有任何Key的值发生了变化，EXEC命令执行的事务都将被放弃，同时返回Nullmulti-bulk应答以通知调用者事务执行失败

7.4 3个阶段

       ①　开启：以MULTI开始一个事务
       ②　入队：将多个命令入队到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务队列里面
       ③　执行：由EXEC命令触发事务

7.5 3个特性

       ①　单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
       ②　没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，也就不存在”事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题。
       ③　不保证原子性：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚，只是部分支持事务。