文章目录
- 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 --pipe
4. 总结
原生批量命令和管道区别：
- 原生批量命令是原子性的（例如mset，mget），pipeline是非原子性的
- 原生的批量命令一次只能执行一种命令，pipeline支持批量执行不同命令
- 原生批命令是服务端实现的，而pipeline需要服务端于客户端共同完成
Pipeline和事务对比：
- 事务具有原子性，管道不具有
- 管道一次性将多条命令发送到服务器，事务是一条一条法，事务只有在接受到exex命令后才会才会执行，管道不会
- 执行事务时会阻塞其它命令执行，执行管道命令不会
使用管道注意事项：
- 管道缓存的指令只是会依此执行，不保证原子性，如果执行中指令发生异常，将会继续执行后序指令
- 使用pipeline组装的命令个数不能太多，不如会对数据量过大客户端阻塞的时间可能过久，同时服务端此时也被迫回复一个队列答复，占用很多内存
