Redis事务与管道
Redis事务
可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会序列化，按顺序地串行执行而不会被其他命令插入，不许加塞。
一个队列中，一次性、顺序性、排他性的执行一系列命令。
Redis事务VS数据库事务
常用命令
情况1：正常执行
MULTI 与 EXEC
multi执行后开启事务，把后续的每条执行命令放在队列QUEUE中，当输入exec执行命令后，队列中的相关指令才开始执行。
情况2：放弃事务
MULTI与DISCARD
情况3：全体连坐
在往队列中添加命令时，某个命令是错误的命令，语法编译错误，那么执行exec的操作会报出异常，无法继续完成队列中的命令。
情况4：冤头债主
这种是命令执行异常，不是命令编译异常
Redis不能提供事务的回滚功能，开发者必须在事务执行出错以后，自行恢复数据库的状态。
特别注意与传统数据库事务的区别，不一定要么一起成功，要么一起失败。
情况5： watch监控
Redis使用Watch来提供乐观锁定，类似于CAS（Check-and-Set)
悲观锁：顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。
乐观锁：顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此次期间别人有没有去更新这个数据。
乐观锁的策略：提交的版本必须大于记录当前版本才能执行更新。
CAS
watch操作
监控并顺利的执行
监控
在 set balance 200的时候，另外一个事务执行了set balance 300
由于balance的值被另外一个事务修改了，再次执行事务的提交exec操作，执行失败。
unwatch 可以放弃对于key的监控操作
redis事务小结
- 一旦执行了exec之前加的监控锁都会被取消掉了。
- 当客户端连接丢失的时候（如退出连接），所有的东西都会被取消监视。
Redis管道
如何优化频繁的命令往返造成的性能瓶颈？
解决思路—管道
Pipeline是为了解决RTT往返时，仅仅是将命令打包成一次性发送，对整个redis的执行不造成其他任何影响。批处理命令的变种优化方式，类似redis的原生批命令（mget与mset）
redis的管道执行，将命令打包到一个txt文件中，cat读取结果集，同时执行后续的redis-cli的命令，批量执行txt文件中的命令。类似于SQL脚本的感觉
结果查询
管道与原生批量命令的对比
- 原生批量命令是原子性的（mget mset)，pipeline是非原子性的
- 原生批量命令一次只能执行一种命令，pipeline支持批量执行不同命令
- 原生批量命令是服务端实现，pipeline需要服务端与客户端共同完成。
Pipeline与事务的对比
- 事务具有原子性，管道不具有原子性
- 管道一次性将多条命令发送到服务器，事务是一条一条的发，事务只有在接收到exec命令后才会执行，管道不会
- 执行事务时阻塞其他命令的执行，而执行管道中的命令时不会
使用pipeline的注意点
官网地址
Redis 事务
Redis 管道