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工具的示例如下所示:

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),这个客户端支持管道功能,可用来测试管道功能带来的性能改善。基准测试的源码如下所示:

  1. import redis.clients.jedis.Jedis;
  2. import redis.clients.jedis.Pipeline;
  3. public class JedisPipeline {
  4. public static void main(String[] args) {
  5. withoutPipelining();
  6. withPipeLining();
  7. }
  8. private static void withoutPipelining() {
  9. Jedis jedis = new Jedis("192.168.21.135", 6379);
  10. long start = System.currentTimeMillis();
  11. for (int i = 0; i < 10000; i++) {
  12. jedis.ping();
  13. }
  14. long end = System.currentTimeMillis();
  15. System.out.printf("without pipelining %f seconds ...\n", (end - start) / 1000.0);
  16. jedis.close();
  17. }
  18. private static void withPipeLining() {
  19. Jedis jedis = new Jedis("192.168.21.135", 6379);
  20. Pipeline pipeline = jedis.pipelined();
  21. long start = System.currentTimeMillis();
  22. for (int i = 0; i < 10000; i++) {
  23. pipeline.ping();
  24. }
  25. pipeline.syncAndReturnAll();
  26. long end = System.currentTimeMillis();
  27. System.out.printf("with pipelining %f seconds ...\n", (end - start) / 1000.0);
  28. jedis.close();
  29. }
  30. }

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

管道的基准测试结果

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

三、管道和脚本

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

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