《redis in action》redis事务和管道

写点笔记

共 941字,需浏览 2分钟

 ·

2021-04-13 05:20

在之前的文章中我们大概学习了redis的安全性,主要就是持久化和夸机备份。这里我们再来学习一下redis的安全和性能问题。这块说的性能问题主要就是说客户端与服务端的通信,而不是说redis的服务器的机器的问题。
我们在之前学习了redis的事务(multi/exec),当时我们说redis事务是没有原子性的,所有的命令都是先发送到服务端,然后缓存起来,然后再执行exec的时候才进行统一执行的,如果exec之前发生了错误,那么所有提交的命令将不会被redis执行。当然如果如果命令执行了一半之后报错了,那么已经执行的命令也不会发生回滚。而且我们当时也说过redis的事务是阻塞的,直到exec执行完毕才能进行其他客户端发来的命令。那么redis事务的问题就是操作指令是一个个发到服务端,然后缓存,在客户端调用exec的时候再进行执行。那么有没有一种方式让这些命令一次性发送到服务端,然后一起执行?答案是有得。这就是传说中的管道。
管道不是redis提供的命令,redis只是提供了事务相关的命令,管道是客户端的行为。管道分为事务管道和非事务管道,事务管道就是在管道中进行multi开启事务,非事务管道仅仅是批量执行命令。因此性能就会有差别。通过实践测试,使用管道比一般传统模式效率高4-5倍,这块和网络有关系。
了解了管道和事务的联系,我们就知道我们在项目中应该尽可能使用管道,尤其是命令比较多的时候,除此之外,对于一些具有并发特征的数据应该采用事务管道,因为事务管道具有阻塞的功能,也就是串行。
在关系型数据库中事务都是采用加锁的方式进行的,redis并没有采用那种锁的方式,为什么这样的原因是redis事务的时间是没有限制的,也不知道前一个操作何时完成,redis不想让客户端等待,而是让客户端尽早知道。另外watch的乐观锁机制也是被动的去监听,如果出现了变化,那么就尽早让客户端知道改变已经发生,然后进行相关的策略,一句话就是为了快。

浏览 29
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报