1. 问题提出
如何优化频繁命令往返造成的性能瓶颈?
Redis是一种基于C/S一级请求响应协议的TCP服务,一个请求会遵循一下步骤:
- 客户端向服务端发送命令分四步(发送命令-> 命令排队-> 命令执行-> 返回结果),并监听Socket返回,通常以阻塞方式等待服务器响应。
- 服务端处理命令,并将结果返回给客户端
上述步骤两步称为:Round Trip Time(简称RTT,数据包往返于两端的时间)
如果同时需要执行大量的命令,那么就要等待上一条命令应答后再执行,这中间不仅仅多了RTT,而且还频繁调用系统IO,发送网络请求,同时需要Redis调用多次I/O,系统方法会从用户态切换到核心态,这样对进程上下文有比较大的影响,性能不太好。
2. 解决方案
管道可以一次性发送多条数据给服务端,服务端依此处理完毕后,通过一条响应一次将结果返回,通过减少于redis通信次数来降低往返时延。管道的实现原理是队列,先进先出特性就保证了数据的顺序性。
它本质上可以理解为批处理命令的优化措施,类似Redis的原生批命令(mget和mset)
3. 案例演示
- 首先创建一个txt文件
写入一系列命令
- 执行命令
|前面是参数,后面是命令,意思是将参数传给命令执行
cat cmd.txt | redis-cli -a 123456 --pipe
4. 总结
原生批量命令和管道区别:
- 原生批量命令是原子性的(例如mset,mget),pipeline是非原子性的
- 原生的批量命令一次只能执行一种命令,pipeline支持批量执行不同命令
- 原生批命令是服务端实现的,而pipeline需要服务端于客户端共同完成
Pipeline和事务对比:文章来源:https://www.toymoban.com/news/detail-802637.html
- 事务具有原子性,管道不具有
- 管道一次性将多条命令发送到服务器,事务是一条一条法,事务只有在接受到exex命令后才会才会执行,管道不会
- 执行事务时会阻塞其它命令执行,执行管道命令不会
使用管道注意事项:文章来源地址https://www.toymoban.com/news/detail-802637.html
- 管道缓存的指令只是会依此执行,不保证原子性,如果执行中指令发生异常,将会继续执行后序指令
- 使用pipeline组装的命令个数不能太多,不如会对数据量过大客户端阻塞的时间可能过久,同时服务端此时也被迫回复一个队列答复,占用很多内存
到了这里,关于Redis管道操作的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!