Redis 笔记（15）— 管道 pipeline（客户端将批量命令打包发送用来节省网络开销）

Redis 是一种基于客户端-服务端模型以及请求/响应协议的 TCP 服务。这意味着通常情况下一个请求会遵循以下步骤：

• 客户端向服务端发送一个查询请求，并监听 Socket 返回，通常是以阻塞模式，等待服务端响应。
• 服务端处理命令，并将结果返回给客户端。

一个 client 可以通过一个 socket 连接发起多个请求命令。

每个请求命令发出后 client 通常会阻塞并等待 redis 服务处理，redis 处理完后请求命令后会将结果通过响应报文返回给 client 。

客户端和服务端通过网络进行连接。这样的连接可能非常快，也可能非常慢（在广域网上经过多个结点才能互通的两个主机）。但是无论是否存在网络延迟，数据包从客户端传输到服务端，以及客户端从服务端获得相应都需要花费一些时间。这段时间就成为往返时延( Round Trip Time)。

因此当客户端需要执行一串请求的时候，很容易看出它对性能的影响（例如往同一个队列中加入大量元素，或者往数据库中插入大量的键）。如果RTT时长为250毫秒（在基于广域网的低速连接环境下），即使服务器每秒可以处理 10 万个请求，但是实际上我们依然只能每秒处理最多4个请求。
如果处于一个回路网络中，RTT 时长则相当短（我的主机 ping 127.0.0.1时只需要0.044ms），但是如果你执行一大串写入请求的时候，还是会有点长。

1. 管道

一个请求/相应服务可以实现为，即使客户端没有读取到旧请求的响应，服务端依旧可以处理新请求。通过这种方式，可以完全无需等待服务端应答地发送多条指令给服务端，并最终一次性读取所有应答。管道技术最显著的优势是提高了 redis 服务的性能。

通过 pipeline 方式当有大批量的操作时候。我们可以节省很多原来浪费在网络延迟的时间。需要注意到是用 pipeline 方式打包命令发送，redis 必须在处理完所有命令前先缓存起所有命令的处理结果。打包的命令越多，缓存消耗内存也越多。所以并是不是打包的命令越多越好。具体多少合适需要根据具体情况测试。

如果连续执行多条指令，那就会花费多个网络数据包来回的时间。如下图所示。

调整读写顺序，使得两个连续的写操作和两个连续的读操作总共只会花费一次网络来回，就好比连续的 request 操作合并了，连续的 response 操作也合并了一样。

这便是管道操作的本质，它并不是服务器的什么特性，服务器根本没有任何区别对待，还是收到一条消息，执行一条消息，回复一条消息的正常的流程。客户端通过对管道中的指令列表改变读写顺序就可以大幅节省 IO 时间，从而提升性能。