1。请求-响应协议和RTT：

redis是基于C/S模式的一个典型的TCP服务器。在沟通的过程中客户端和服务器端，客户端通常率先发起的请求，执行相应的任务，服务器接收请求后，最后将采集到的数据或处理结果回复客户。在这个过程中，客户在一个封锁的方式等待服务器返回的结果。看到下面的命令序列：

复制代码代码如下所示：

客户：增加X

服务器：1

客户：增加X

服务器：2

客户：增加X

服务器：3

客户：增加X

服务器：4



在请求和响应的每一对，我们要承担网络传输额外的开销。通常我们称这种开销的RTT（往返时间）。现在我们假设每个请求和响应时间是250毫秒，和我们的服务器可以在一秒钟100k数据的过程，但结果是，我们的服务器流程4每秒的请求数。为了解决这个问题，我们应该如何优化呢



二、管道（流水线）：

Redis已经在一个非常早期的版本命令管道提供支持。在给出具体的解释，我们首先将上述同步响应模式为一个基于命令行的异步响应模式，这将给你一个更好的感性认识。

复制代码代码如下所示：

客户：增加X

客户：增加X

客户：增加X

客户：增加X

服务器：1

服务器：2

服务器：3

服务器：4



从上面的例子中，我们可以看到，在发送命令，客户端可以不等待来自服务器的回复，但可以继续发送以下命令后，发送命令，所有的命令都会再次阅读之前回答。这节省了在同步模式下的成本。

最后，需要说明的是，如果Redis服务器发现客户端的请求是基于管道，然后服务器端将收到的每一个命令的应答数据并发送给客户端接收请求，处理后。



三，基准：

以下是从Redis官网的测试用例和测试结果。需要说明的是，这个测试是基于环回（127.0.0.1），因此RTT占用更少的时间。如果是基于实际的网络接口，那么管道机构的性能改进将更为重要。

复制代码代码如下所示：

require'rubygems

require'redis



替补席（描述）

起始时间

让

提出# {说明} # { }秒时间。现在开始

终点



DEF without_pipelining

R = redis.new

{ 10000.times

r.ping

}

终点



DEF with_pipelining

R = redis.new

r.pipelined {

{ 10000.times

r.ping

}

}

终点



工作台（没有管道）{

without_pipelining

}

工作台（管道）{

with_pipelining

}

没有流水线1.185238秒

使用流水线0.250783秒