Redis is a TCP server using the client-server model and what is called a Request/Response protocol.
redis使用的是基于tcp协议的client-server模型，也可以叫做
Request/Response 协议模型. This means that usually a request is accomplished with the following steps:
它的意思是指通常一个请求完成分为下面的步骤
The client sends a query to the server, and reads from the socket, usually in a blocking way, for the server response.
客户端对redis服务器发生查询请求，通过socket连接redis服务器端，通常在收到返回之前是阻塞的
The server processes the command and sends the response back to the client
redis服务器执行命令并且发送结果返回给客户端 So for instance a four commands sequence is something like this:
因此rdis实例执行4个命令的顺序大概是这样的：
Client: INCR X
Server: 1
Client: INCR X
Server: 2
Client: INCR X
Server: 3
Client: INCR X
Server: 4 Clients and Servers are connected via a networking link. Such a link can be very fast (a loopback interface) or very slow (a connection established over the Internet with many hops between the two hosts). Whatever the network latency is, there is a time for the packets to travel from the client to the server, and back from the server to the client to carry the reply.
客户端与redis服务器通过网络连接。这样的连接可以是非常快的（一个本地回送端口）或者是非常慢（通过Internet连接的两个主机）。然而不管这个网络因素如何，有一个数据包到服务器，服务器就会返回一个应答。(解释：请求发出到收到返回的这个时间叫RTT) This time is called RTT (Round Trip Time). It is very easy to see how this can affect the performances when a client needs to perform many requests in a row (for instance adding many elements to the same list, or populating a database with many keys). For instance if the RTT time is 250 milliseconds (in the case of a very slow link over the Internet), even if the server is able to process 100k requests per second, we'll be able to process at max four requests per second.
这个个过程的时间开销叫RTT（一个来回时间）.显然，当一个客户端连续不断地发生请求（增加很多元素进同一个list，或者获取很多key）对性能是有影响的。因此如果一个redis实例的RTT 时间是250毫米（连接的网络比较慢），尽管redis理论上每秒可以处理100k的请求，我们每秒也只能处理4个请求. If the interface used is a loopback interface, the RTT is much shorter (for instance my host reports 0,044 milliseconds pinging 127.0.0.1), but it is still a lot if you need to perform many writes in a row.
如果网络使用的是会送接口，RTT 时间就短很多(比如我ping本机的实例只要44毫米)，但是如果连续不断地发送命令仍然会比较长。 Fortunately there is a way to improve this use case.
幸运的是有一些改进的案例.
Redis Pipelining A Request/Response server can be implemented so that it is able to process new requests even if the client didn't already read the old responses. This way it is possible to send
multiple commands to the server without waiting for the replies at all, and finally read the replies in a single step.
一个Request/Response 的sever可以执行新的requests，尽管client没收到以前的respones。这个方式是向server发送很多命令，不等待应答，直到最后一次性读取所有的应答。 This is called pipelining, and is a technique widely in use since many decades. For instance many POP3 protocol implementations already supported this feature, dramatically speeding up the process of downloading new emails from the server.
这种方式就叫pipelining(管道),是十几年前就被广泛使用的技术。例如，POP3协议已经实现了这种特性，大大加快了从服务器
下载邮件的速度。 Redis supports pipelining since the very early days, so whatever version you are running, you can use pipelining with Redis. This is an example using the raw netcat utility:
redis在早期就已经支持pipelining，因此不管哪个版本你都可以使用pipelining。下面是一个使用netcat的例子：
$ (printf "PING\r\nPING\r\nPING\r\n"; sleep 1) | nc localhost 6379
+PONG
+PONG
+PONG This time we are not paying the cost of RTT for every call, but just one time for the three commands
不是每个call都花一个RTT时间，而是一个RTT 时间执行3个命令。 To be very explicit, with pipelining the order of operations of o |