文章目录
一、请求/响应协议和RTT
Redis是一个使用客户端-服务器模型和所谓的请求/响应协议的 TCP 服务器。
通过以下步骤完成一个请求
- 客户端向服务器发送一个query，阻塞的从socket中读取，用于服务器响应
- 服务器处理指令然后返回响应给客户端
举例
Client: INCR X
Server: 1
Client: INCR X
Server: 2
Client: INCR X
Server: 3
Client: INCR X
Server: 4
RTT（往返时间）：客户端发出请求到服务端到从服务端接收到响应的时间
二、Redis管道
管道：客户端一次向服务器发送多条命令，最后统一读取响应。
举例：
$ (printf "PING\r\nPING\r\nPING\r\n"; sleep 1) | nc localhost 6379
+PONG
+PONG
+PONG
这样做我们不必为每一次的调用花时间，而是整体读取一次的时间。
举例：
Client: INCR X
Client: INCR X
Client: INCR X
Client: INCR X
Server: 1
Server: 2
Server: 3
Server: 4
当客户端通过管道向redis发送命令时，redis服务器在内存中将响应放在一个队列里。所以当你使用管道发送命令时，最好是发送成批数量的请求，例如10K的命令，然后读取响应，重复这个过程。成批处理的速度是接近的，当然缓存这10K命令的响应也会耗费额外的内存。
三、这不仅仅是RTT的问题
管道不仅仅是减少了往返时延的成本，同时极大的提高Redis服务器每秒可以执行操作的数量，在不使用流水线的情况下，从访问数据结构和生成响应的角度来看，为每个命令提供服务不会有很大的耗费，但是通过socket I/O的角度来看，这涉及到read()和write系统调用，这意味着从用户态到内核态，上下文切换非常的耗费系统资源。
通过管道，通常使用单个read() 系统调用读取许多命令，并通过单个 write() 系统调用传递多个响应。 正因为如此，每秒执行的总查询数最初随着管道的延长几乎呈线性增加，最终达到不使用管道获得的基线的 10 倍，如下图所示：
四、一个现实世界中的例子
通过java来测试管道带来的速度提升
package com.demo.service.Impl;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.Pipeline;
import redis.clients.jedis.params.SetParams;
public class Pipelining {
public static void pipe(Jedis jedis){
long start = System.currentTimeMillis();
Pipeline pipelined = jedis.pipelined();
for(int i = 0;i < 1000000;i++){
pipelined.set("pipe:" + i,String.valueOf(i), SetParams.setParams().ex(3000L));
}
pipelined.sync();
long end = System.currentTimeMillis();
System.out.println("管道：" + (end - start) + "ms");
}
public static void withoutPipe(Jedis jedis){
long start = System.currentTimeMillis();
for(int i = 0;i < 1000000;i++){
jedis.set("without:" + i,String.valueOf(i), SetParams.setParams().ex(3000L));
}
long end = System.currentTimeMillis();
System.out.println("不使用管道：" + (end - start) + "ms");
}
public static void main(String[] args) {
JedisPool pool = new JedisPool("localhost",6379,null,"123456");
Jedis jedis = pool.getResource();
pipe(jedis);
withoutPipe(jedis);
}
}
通过运行以上程序，你会发现使用管道技术，我们的速度提高了很多。
五、 Pipelining vs Scripting
使用Redis脚本（在 Redis 2.6 或更高版本中可用），可以使用执行服务器端所需的大量工作的脚本更有效地解决许多管道用例。 脚本的一大优点是它能够以最小的延迟读取和写入数据，使得读取、计算、写入等操作非常快（流水线在这种情况下无济于事，因为客户端在调用写入命令之前需要读取命令的回复）。
有时，应用程序可能还想在管道中发送 EVAL 或 EVALSHA 命令。 这是完全可能的，Redis 使用 SCRIPT LOAD 命令明确支持它（它保证可以调用 EVALSHA 而没有失败的风险）。
Appendix：为什么即使在环回接口上繁忙循环也很慢？
即使本页涵盖了所有背景，您可能仍然想知道为什么像下面这样的 Redis 基准测试（伪代码），即使在环回接口中执行，当服务器和客户端运行在同一台物理机器上时，速度也会很慢 ：
FOR-ONE-SECOND:
Redis.SET("foo","bar")
END
如果 Redis 进程和基准测试都在同一个盒子中运行，难道它只是将内存中的消息从一个地方复制到另一个地方，而不涉及任何实际延迟或网络？
原因是系统中的进程并不总是在运行，实际上是内核调度程序让进程运行。 因此，例如，当基准测试被允许运行时，它从 Redis 服务器读取回复（与执行的最后一个命令相关），并写入一个新命令。 该命令现在在环回接口缓冲区中，但为了被服务器读取，内核应该调度服务器进程（当前在系统调用中被阻止）运行，依此类推。 因此，实际上，由于内核调度程序的工作方式，环回接口仍然涉及类似网络的延迟。
基本上，在测量联网服务器中的性能时，繁忙循环基准测试是最愚蠢的事情。 明智的做法是避免以这种方式进行基准测试。