做空调管路网站,出售app软件的平台,主机网站建设,网站后台管理系统html文章目录 1. 问题提出2. 解决方案3. 案例演示4. 总结 1. 问题提出
如何优化频繁命令往返造成的性能瓶颈#xff1f;
Redis是一种基于C/S一级请求响应协议的TCP服务#xff0c;一个请求会遵循一下步骤#xff1a;
客户端向服务端发送命令分四步#xff08;发送命令- … 文章目录 1. 问题提出2. 解决方案3. 案例演示4. 总结 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 --pipe4. 总结
原生批量命令和管道区别
原生批量命令是原子性的例如msetmgetpipeline是非原子性的原生的批量命令一次只能执行一种命令pipeline支持批量执行不同命令原生批命令是服务端实现的而pipeline需要服务端于客户端共同完成
Pipeline和事务对比
事务具有原子性管道不具有管道一次性将多条命令发送到服务器事务是一条一条法事务只有在接受到exex命令后才会才会执行管道不会执行事务时会阻塞其它命令执行执行管道命令不会
使用管道注意事项
管道缓存的指令只是会依此执行不保证原子性如果执行中指令发生异常将会继续执行后序指令使用pipeline组装的命令个数不能太多不如会对数据量过大客户端阻塞的时间可能过久同时服务端此时也被迫回复一个队列答复占用很多内存
