Redis管道Pipelining原理详解

客户端和服务器通过网络进行连接。该连接可以很快（loopback接口）或很慢（建立一个多次跳转的网络连接）。无论网络如何延迟，数据包总是能从客户端到达服务器，并从服务器返回数据回复客户端。

这个时间被称之为 RTT (Round Trip Time - 往返时间)。当客户端需要在一个批处理中执行多次请求时，这很影响性能（例如添加许多元素到同一个list，或者用很多Keys填充数据库）。如果RTT时间是250ms（在一个很慢的连接下），即使服务器每秒能处理100k的请求数，我们每秒最多也只能处理4个请求。

如果采用loopback接口，RTT就短得多（比如我的主机ping 127.0.0.1只需要44毫秒），但它在一次批量写入操作中仍是一笔巨大开销。还好一种方法可以改善这种情况。

Redis 管道（Pipelining）

===================================================================================

一次 请求/响应服务器 能实现处理新的请求，即使旧的请求还未被响应。这样即可将多个命令发送到服务器，而不用等待响应，最后在一个步骤中读取该响应。

这就是管道（pipelining），一种几十年来广泛使用的技术。许多POP3协议支持这个功能，大大加快从服务器下载新邮件的过程。

Redis很早就支持管道（pipelining），因此无论你运行的是什么版本，你都可以使用管道（pipelining）操作Redis。

Pipelining不仅是一种减少往返时间的延迟成本的方法，还大大提高了你在给定的Redis服务器中每秒可执行的总操作量。这是由于以下事实的结果：从访问数据结构和产生响应的角度来看，不使用pipelining，服务每个命令非常廉价，但从执行socket I/O角度来看这非常昂贵。

这涉及到调用read和write的系统调用，这意味着从用户态到内核态。上下文切换是巨大的速度损失。

但当使用Pipelining时，通常使用单个read系统调用读取许多命令，并且通过单