Redis的请求/响应协议和往返时间详解

Redis是一种采用客户端-服务器（C/S）模型的TCP服务器，这种模型也被称作请求/响应协议。

这就意味着，一个请求通常需要经过以下步骤才能完成：

• 客户端会向服务器发送一个查询请求，然后从套接字（socket）读取服务器的响应数据，通常以一种阻塞的方式。

• 服务器会处理请求的命令，然后将响应数据发送回客户端。

例如，一个包含四条命令的序列如下所示：

• 客户端请求：INCR X

• 服务器响应：1

• 客户端请求：INCR X

• 服务器响应：2

• 客户端请求：INCR X

• 服务器响应：3

• 客户端请求：INCR X

• 服务器响应：4

客户端和服务器通过网络建立连接。这种网络链接可能非常快速或非常缓慢（在互联网上建立的网络链接，可能会在两台主机之间存在很多跳数）。无论网络延迟有多小，客户端将数据包发送至服务器，然后服务器再将响应数据发送回客户端，这都需要花费一定时间的。

这段时间被称为往返时间（RTT：Round Trip Time）。当一个客户端需要连续执行很多请求时，就很容易看出往返时间是如何影响系统性能的（例如，将很多元素添加至同一个列表，或者向一个数据库写入很多键）。例如，如果往返时间是250毫秒（例如，在互联网上建立的慢速网络链接），即使Redis服务器每秒钟能处理100k个请求，我们也只能每秒钟最多处理四个请求。

如果使用的网络接口是一个回环接口，那么往返时间会非常短（例如，在我的电脑上对127.0.0.1地址执行ping命令，得到的往返时间是0.044毫秒），但是如果你需要连续执行很多次写入操作，往返时间对于系统性能的消耗仍然非常大。

幸运的是，现在有办法可以改善上述用例的性能。

一、Redis管道

可以实现一种请求/响应服务器，即使当客户端尚未读取稍早的响应数据，这个服务器都能够继续处理新的请求。通过这种方法，客户端就可以向服务器发送多个命令，而根本不用等待任何返回数据，最后会在一个单独的步骤中读取所有的返回数据。

这种方式被称为管道，这种技术已经广泛使用了几十年。例如，很多POP3协议的实现已经支持这项功能特性，显著增加了从服务器下载新邮件的处理速度。

Redis在很久以前就已经支持管道了。因此，无论你正在运行的Redis版本是什么，你都可以使用Redis的管道功能。使用原生的netcat工具的示例如下所示：

这次我们还会执行三个命令，但是不会在每个命令调用时都有往返时间的消耗，而只会消耗一次往返时间。

为了能够清晰地理解管道的概念，当使用管道时，本文首个示例的操作顺序将如下所示：

• Client：INCR X

• Client：INCR X

• Client：INCR X

• Client：INCR X

• Server：1

• Server：2

• Server：3

• Server：4

重要提示：虽然客户端会使用管道发送多个命令，但是服务器会被强制使用内存来缓存返回数据。因此，如果你需要使用管道发送很多条命令，最好是将它们作为具有合理编号的批次进行发送。例如，先发送一批10k条命令，然后读取返回数据，然后再发送另一批10k条命令，如此往复。不同批次命令的处理速度几乎是相同的，但是为了缓存每个批次的10k条命令的返回数据，管道功能会额外占用Redis服务器的内存。

二、基准测试

在下面的基准测试中，我们将会使用Redis的Java客户端（Jedis），这个客户端支持管道功能，可用来测试管道功能带来的性能改善。基准测试的源码如下所示：

import redis.clients.jedis.Jedis;

import redis.clients.jedis.Pipeline;

public class JedisPipeline {

public static void main(String[] args) {

withoutPipelining();

withPipeLining();

}

private static void withoutPipelining() {

Jedis jedis = new Jedis("192.168.21.135", 6379);

long start = System.currentTimeMillis();

for (int i = 0; i < 10000; i++) {

jedis.ping();

}

long end = System.currentTimeMillis();

System.out.printf("without pipelining %f seconds ...\n", (end - start) / 1000.0);

jedis.close();

}

private static void withPipeLining() {

Jedis jedis = new Jedis("192.168.21.135", 6379);

Pipeline pipeline = jedis.pipelined();

long start = System.currentTimeMillis();

for (int i = 0; i < 10000; i++) {

pipeline.ping();

}

pipeline.syncAndReturnAll();

long end = System.currentTimeMillis();

System.out.printf("with pipelining %f seconds ...\n", (end - start) / 1000.0);

jedis.close();

}

}

上述的基准测试程序较为简单，它会连接到一个操作系统为CentOS 6.6的Redis服务器，这个服务器和运行基准测试程序的主机位于相同的局域网之内，因此单次的往返时间会非常小。运行结果如下图所示：

正如测试结果所示，使用管道，我们可以获得接近18倍的性能提升。

三、管道和脚本

通过Redis的脚本功能（Redis 2.6版本或更高版本可用），管道的很多用例都可以利用脚本获得更高的执行效率，这些脚本会执行服务器端需要的很多工作。脚本功能有一个很大的优势，它读写数据只会有最少的延迟，这样便会使得诸如读取、计算和写入等操作变得非常快速（在这个场景之中，管道不会有明显的效果，因为客户端在调用写入命令之前，需要先获得读取命令的返回数据）。

应用程序有时候可能需要通过管道发送EVAL或EVALSHA命令。这种情况是完全有可能的，Redis可以通过SCRIPT LOAD命令提供显式地支持（这条命令可以保证EVALSHA命令肯定会被调用，而且不会有执行失败的风险）。