管道
Redis提供的这种加速存取效率，这个技术本质是由客户端提供的，和服务器没有直接的关系
管道就是打包多条无关命令批量执行，以减少多个命令分别执行消耗的网络交互时间（TCP网络交互），可以显著提升Redis的性能；
管道使用的场景并不适用于，必须知道每次交互结果的场景或者当前的执行依赖于上一次的执行结果等等，相反的，比较适用于对于可靠性不高，允许一定程度的失败，并且不需要立即得到执行的反馈，比如群发短信服务；
管道本质
- 客户端进程调用write将信息写到操作系统内核为套接字分配的发送缓冲send buffer中。
- 客户端操作系统内核将发送缓冲的内容发送到网卡，网卡硬件将数据通过“国际路由”送到服务器的网卡
- 服务器操作系统内核将网卡的数据放到内核为套接字分配的接收缓冲recv buffer 中
- 服务器进程调用read从接收缓冲中取出消息进行处理
- 服务器进程调用write将相应消息写到内核为套接字分配的发送缓冲send buffer中
- 服务器操作系统内核将发送缓冲的内容发送到网卡，网卡硬件将数据通过“国际路由”送到客户端的网卡
- 客户端操作系统内核将网卡的数据放到内核为套接字分配的接收缓冲recv buffer中
- 客户端进程调用read从接收缓冲中取出消息返回给上层业务逻辑进行处理
- 结束
write操作只负责将数据写到本地操作系统内核的发送缓冲中就返回，剩下交给操作系统异步将数据送到目标机器。如果发送缓冲满了，那么需要等到缓冲空出空间，这才是写操作IO的真正耗时
read操作从目标机器拉取数据，实际read操作只负责将数据从本地操作系统内核的接收缓冲中取出来，如果缓冲是空的则等待数据到来，这个是read操作IO的真正耗时
所以对于管道来说，连续的write操作并不耗时，之后第一个read操作会等待网络的来回开销，之后的消息都到了内核的读缓冲