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脚本的感觉
在这里插入图片描述