1. 问题提出

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

Redis是一种基于C/S一级请求响应协议的TCP服务，一个请求会遵循一下步骤：

1. 客户端向服务端发送命令分四步（发送命令-> 命令排队-> 命令执行-> 返回结果），并监听Socket返回，通常以阻塞方式等待服务器响应。
2. 服务端处理命令，并将结果返回给客户端

上述步骤两步称为：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. 总结

原生批量命令和管道区别：

1. 原生批量命令是原子性的（例如mset，mget），pipeline是非原子性的
2. 原生的批量命令一次只能执行一种命令，pipeline支持批量执行不同命令
3. 原生批命令是服务端实现的，而pipeline需要服务端于客户端共同完成

Pipeline和事务对比：

1. 事务具有原子性，管道不具有
2. 管道一次性将多条命令发送到服务器，事务是一条一条法，事务只有在接受到exex命令后才会才会执行，管道不会
3. 执行事务时会阻塞其它命令执行，执行管道命令不会

使用管道注意事项：

1. 管道缓存的指令只是会依此执行，不保证原子性，如果执行中指令发生异常，将会继续执行后序指令
2. 使用pipeline组装的命令个数不能太多，不如会对数据量过大客户端阻塞的时间可能过久，同时服务端此时也被迫回复一个队列答复，占用很多内存