在 Redis 中使用 Pipelining 提升查询速度

Redis 是一个client-server模式的 TCP 服务，也被称为Request/Response协议的实现。 这意味着通常一个请求的完成是遵循下面两个步骤：

• Client 发送一个操作命令给 Server，从 TCP 的套接字 Socket 中读取 Server 的响应值，通常来说这是一种阻塞的方式

• Server 执行操作命令，然后将响应值返回给 Client

举个例子：

Client: INCR XServer: 1Client: INCR XServer: 2Client: INCR XServer: 3Client: INCR XServer: 4复制代码

Clients 和 Servers 是通过网络进行连接。网络连接可能会很快（比如本机回环网络），也可能会很慢（比如两个主机之间存在多条网络）。不管网络怎么样，一个数据包从 Client 到 Server，然后相应值又从 Server 返回 Client 都需要一定的时间。

这个时间被称为 RTT(Round Trip Time)。当一个 Client 需要执行多个连续请求（比如添加许多个元素到一个 list 中，或者清掉 Redis 中许多个键值对），那么 RTT 是怎样影响到性能，这个也是很方便去计算的。如果 RTT 的时间为 250ms（假设互联网连接速度很常慢），即使 Server 可以每秒处理 100k 个请求，那么最多也只能接受每秒 4 个请求。

如果是本地回环网络，RTT 将会特别的短（比如作者的 localhost，RTT 的响应时间为 40ms），但是对于执行连续多次写操作时，也是一笔不小的消耗。

其实我们有其他办法来降低这种场景的消耗。

Redis Pipelining

在一个Request/Response方式的服务中有一个特性：即使 Client 没有收到之前的响应值，也可以继续发送新的请求。这种特性我们可以不用等待 Server 的响应，率先发送许多操作命令给 Server，再一次性读取 Server 的所有响应值。

这种方式被称为Pipelining技术，该技术近几十年来被广泛的使用。比如多 POP3 协议的实现就支持这个特性，大大的提升了从 server 端下载新的邮件的速度。

Redis 在很早的时候就支持该项技术，所以不管你运行的是什么版本，你都可以使用pipelining技术，比如这里有一个使用 netcat 工具的：

$ (printf "PING\r\nPING\r\nPING\r\n"; sleep 1) | nc localhost 6379+PONG+PONG+PONG复制代码

现在我们不需要为每一次请求付出 RTT 的消耗了，而是一次性发送三个操作命令。为了便于直观的理解，还是拿之前的例子说明，使用pipelining技术该例子的实现顺序如下：

Client: INCR XClient: INCR XClient: INCR XClient: INCR XServer: 1Server: 2Server: 3Server: 4复制代码

当 client 使用pipelining发送操作命令时，server 端将强制使用内存来排列响应结果。所以在使用pipelining发送大量的操作命令的时候，最好确定一个合理的命令条数，一批一批的发送给 Server 端，比如发送 10000 个操作命令，读取响应结果，再发送 10000 个操作命令，以此类推…虽然说耗时近乎相同，但是额外的内存消耗将是这 10000 操作命令的排列响应结果所需的最大值。为防止内存耗尽，尽量选择一个合理的值。

It’s not just a matter of RTT

Pipelining不是减少因为 RTT 造成消耗的唯一方式，但它确实帮助我们极大的提升每秒的执行命令数量。事实的真相是：从访问相应的数据结构并且生成答复结果的情况来看，不使用pipelining确实代价很低；但是从套接字 socket I/O 的情况来看，恰恰相反。因为这涉及到了read()和write()调用，需要从用户状态切换到内核状态。这种上下切换会特别损耗时间。

一旦使用了pipelining技术，很多操作命令将会从同一个read()调用中执行读操作，大量的答复结果将会被分发到同一个write()调用中执行写操作。基于此，随着管道的长度增加，每秒执行的查询数量最开始几乎呈直线型增加，直到不使用pipelining技术的基准的 10 倍，如下图所示： 

Some real world code example

不翻译，基本上就是说使用了pipelining提升了 5 倍性能。

Pipelining VS Scripting

Redis Scripting(2.6+版本可用)，通过使用在 Server 端完成大量工作的脚本Scripting，可以更加高效的解决大量pipelining用例。使用脚本Scripting的最大好处就是在读和写的时候消耗更少的性能，使得像读、写、计算这样的操作更加快速。（当 client 需要写操作之前获取读操作的响应结果时，pepelining就显得相形见拙。） 有时候，应用可能需要在使用pipelining时，发送 EVAL 或者 EVALSHA 命令，这是可行的，并且 Redis 明确支持这么这种SCRIPT LOAD命令。（它保证可可以调用 EVALSHA 而不会有失败的风险）。

Appendix: Why are busy loops slow even on the loopback interface?

那么为什么如下的 Redis 测试基准 benchmark 会执行这么慢，甚至在 Client 和 Server 在一个物理机上也是如此：

FOR-ONE-SECOND:    Redis.SET("foo","bar")END复制代码

毕竟 Redis 进程和测试基准benchmark在相同的机器上运行，并且这是没有任何实际的延迟和真实的网络参与，不就是消息通过内存从一个地方拷贝到另一个地方么？ 原因是进程在操作系统中并不是一直运行。真实的情景是系统内核调度，调度到进程运行，它才会运行。比如测试基准benchmark被允许运行，从 Redis Server 中读取响应内容，并且写了一个新的命令。这时命令将在回环网络的套接字中，但是为了被 Redis Server 读取，系统内核需要调度 Redis Server 进程，周而复始。所以由于系统内核调度的机制，就算是在本地回环网络中，仍然会涉及到网络延迟。 简单的说就是在网络服务器中衡量性能时，使用本地回环网络测试并不是一个明智的方式。应该避免使用此种方式来测试基准。

最后

如果你觉得这篇文章对你有点用的话，麻烦请给我们的开源项目点点 star:http://github.crmeb.net/u/defu不胜感激 ！

免费获取源码地址：http://www.crmeb.com

PHP 学习手册：https://doc.crmeb.com

技术交流论坛：https://q.crmeb.com