redis管道
1.redis管道介绍
redis采用的是CS架构，客户端与服务器端通过tcp协议进行连接通信，因此无论是发出请求还是接收响应，都必须经过网络传输。在tcp连接过程中，客户端和服务器端是通过阻塞式的一问一答方式进行通信的，即客户端必须接收到服务端完整的响应，才能进行后续请求。
有时我们会在短时间内发送大量互不依赖的命令(例如:后执行的命令不需要使用前面返回的结果)。由于网络传输不可避免的会造成一定的延迟，特别是在跨机器远程访问redis的时候，如果使用常规的方式，一条命令对应一次请求和响应的话，大量命令累计的延迟会显得很高。redis的设计者考虑到这一点，在底层的通信协议上，通过支持"管道(pipeline)"来解决这一问题。
简单示例：
普通命令：3次请求/响应
client：INCR num001；
server：1；
client：INCR num001；
server：2；
client：INCR num001；
server：3；
管道命令：1次请求/响应
client：INCR num001；
client：INCR num001；
client：INCR num001；
server：1；
server：2；
server：3；
redis管道可以在一次tcp的请求中同时发送多条命令，并且将响应结果一次性的返回给客户端。对于既定数量的命令请求，redis管道通过减少客户端和服务器端的通信次数，来达到减少通信传输中往返时间的目的，提高效率。
2.redis管道注意事项
1.由于redis的管道要求服务器一次性的将请求返回，因此redis服务端只能将靠前命令处理的结果暂时缓存起来。如果管道一次响应的数据量过多(大规模查询之类的)，可能会对redis服务器的内存造成较大的压力。因此，管道批量处理的命令数量并不是越多越好，需要结合实际需求，合理的决定一次管道批处理命令的数量。
2.redis的管道在客户端通常会设置一个命令缓冲区来存储即将被批量发送的命令，当缓冲区被填满时，才会一次性的将缓冲区的命令发送。这里需要注意的一点是：当业务上的同一批命令使用管道进行请求时，如果最后剩余的命令无法填满缓冲区，如果不使用相应的flush操作，这些命令将不会被发送出去，而是保留在命令缓冲区等待新的命令来填满缓冲区。
3.redis管道总结
redis的管道可以将多个命令打包，一次性的发送给服务器端处理，当命令之间不存在依赖关系时，相比于一条命令一次请求的普通操作方式，管道的操作几乎是对使用者透明的。
和redis的事务类似，redis管道能完成的操作也能够被更加灵活的redis脚本实现，但是脚本的可读性不强、可维护性差。个人认为，如果批量处理的命令之间不存在依赖关系时，优先使用管道；反之，则只能使用脚本了。
redis的管道技术在客户端和服务器端的实现还有很多细节值得探讨，限于个人能力，就不展开说明了。