Redis 7 第五讲 事务、管道、发布订阅 过渡篇

 事务

理论

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

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

Redis事务 VS 关系型数据库事务 

单独的隔离操作	Redis的事务仅仅是保证事务里的操作会被连续独占的执行，redis命令执行是单线程架构，在执行完事务内所有指令前是不可能再去同时执行其他客户端的请求的
没有隔离级别的概念	事务提交前任何指令不会被执行，因此不存在脏读、幻读等
不保证原子性	Redis的事务不保证原子性，也就是不保证所有指令同时成功或同时失败，只有决定是否开始执行全部指令的能力，没有执行到一半进行回滚的能力
排它性	Redis会保证一个事务内的命令依次执行，而不会被其它命令插入

命令

DISCARD

取消事务，放弃执行事务块内的所有命令。

DISCARD

取消事务，放弃执行事务块内的所有命令。

EXEC	标记一个事务块的开始。

UNWATCH

取消 WATCH 命令对所有 key 的监视。

WATCH

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

案例

 正常放行

         （MULTI->指令集->EXEC）

 放弃事务

        （MULTI->指令集->DISCARD） 

全部连坐

        一个队列中，命令在写入队列时出现错误，将直接影响队列整体的提交。

冤头债主

        一个队列中，命令在写入队列时未出现错误，但在执行时出错。只影响错误指令的执行结果，其他正常执行的指令结果没影响。

WATCH监控 

        Redis 使用watch提供乐观锁锁定，类似CAS(CHECK-AND-SET)

悲观锁(Pessimistic Lock)	每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，想拿这个数据就会block直到它拿到锁。
乐观锁(Optimistic Lock)	每次去拿数据的时候都认为别人不会修改，所以不会上锁，在更新 的时候会判断一下在此期间别人有没有去更新这个数据。 乐观锁策略:提交版本必须 大于 记录当前版本才能执行更新
CAS	利用WATCH去监控key,EXEC时去验证是否被操作

        初始化acount和balance两个key,先监控再开启multi保证两key变动在同一个事务内

未加塞 

加塞 

如果监控的balance事务开启后，被其他客户端修改后，当前客户端的事务失败。

 UNWATCH

管道 

 面试题

        如何优化频繁命令往来造成的性能瓶颈?

        管道(pipeline)可以一次性发送多条命令给服务端，服务端依次处理完完毕，通过一次性将响应结果返回，减少客户端与redis的通信次数来实现降低往返延时时间。

        pipeline实现的原理是队列，先进先出特性就保证数据的顺序性。 

作用

         Pipeline是为了解决RTT往返回时，仅仅是将命令打包一次性发送，对整个Redis的执行不造成其它任何影响。简言之，批处理命令变种优化，类似Redis的原生批处理命令（mget/mset）

 案例 

         利用Linux的CAT命令特性，返回结果集作为pipe的参数

 总结

管道与原生批量命令对比	原生批量命令是服务端实现的，管道需要服务的与客户端共同完成
	原生批量命令一次只能执行一种命令，管道支持批量执行不同命令
	原生命令是原子性（如mset\mget）,管道是非原子性的
管道与事务对比	事务具有原子性，管道不具有原子性
	事务逐条发送到队列，接收到exec命令后才执行；管道一次性将多条命令发送到服务器
	执行事务时会阻塞其他命令执行；管道中的命令不会阻塞
使用管道注意事项	管道缓冲的指令只会依次执行，不保证原子性，执行过程中发生异常，会继续执行后续指令
	使用管道组装的命令个数不能太多，数据量过大客户端阻塞的时间可能过久，服务端也被迫回复一个队列答复，占用很多内存

发布订阅 （了解）

理论

        一种消息通信模式:发送者(PUBLISH)发送消息，订阅者(SUBSCRIBE)接收消息，可以实现进程间的消息传递 。

        Redis可以实现消息中间件MQ的功能，通过发布订阅实现消息的引导和分流。

        代表我个人，不推荐使用该功能，专业的事情交给专业的中间件处理，redis就做好分布式缓存功能

案例 

        先订阅再发布 

SUBSCRIBE pattern [pattern ...]订阅一个或多个符答给定模式的频道。

PUBSUB subcommand [argument [argument ...]查看订阅与发布系统状态。 

PUBLISH channel message将信息发送到指定的频道。 

PUNSUBSCRIBE[pattern[pattern ..]退订所有给定模式的频道。 

SUBSCRIBE channel [channel ...]订阅给定的一个或多个频道的信息。 

UNSUBSCRIBE [channel [channel ...]指退订给定的频道。 

 缺点

         发布的消息在Redis系统中不能持久化，因此，必须先执行订阅，再等待消息发布

        消息只管发送对于发布者而言消息是即发即失的，不管接收，也没有ACK机制，无法保证消息的消费成功 

        Redis5.0版本新增了Stream数据结构，不但肢持多播，还支持数据持久化，相比Pub/Sub更加的强大 

🌹 以上分享 Redis 事务、管道、发布订阅，如有问题请指教写。

🌹🌹 如你对技术也感兴趣，欢迎交流。

🌹🌹🌹  如有需要，请👍点赞💖收藏🐱‍🏍分享