今天看啥
热点:

redis翻译_redis管道


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 our very first example will be the following:
显然,pipelining 的操作过程是这样的:
Client: INCR X
Client: INCR X
Client: INCR X
Client: INCR X
Server: 1
Server: 2
Server: 3
Server: 4 IMPORTANT NOTE:While the client sends commands using pipelining, the server will be forced to queue the replies, using memory. So if you need to send a lot of commands with pipelining, it is better to send them as batches having a reasonable number, for instance 10k commands, read the replies, and then send another 10k commands again, and so forth. The speed will be nearly the same, but the additional memory used will be at max the amount needed to queue the replies for this 10k commands.
当client使用pipelining发生一些命令时,redis server将使用内存为应答创建一个队列。因此你使用pipelining发生很多命令,一个好的做法是,合理地批量发送,比如,10k一个批次,得到返回后在发生10k。速度大概是一样的,但是redis server为了这个10k的命令要花费内存去创建应答队列。

Some benchmark

In the following benchmark we'll use the Redis Ruby client, supporting pipelining, to test the speed improvement due to pipelining:
下面是使用ruby支持pipelining客户端的例子:
require 'rubygems'
require 'redis'

def bench(descr)
    start = Time.now
    yield
    puts "#{descr} #{Time.now-start} seconds"
end

def without_pipelining
    r = Redis.new
    10000.times {
        r.ping
    }
end

def with_pipelining
    r = Redis.new
    r.pipelined {
        10000.times {
            r.ping
        }
    }
end

bench("without pipelining") {
    without_pipelining
}
bench("with pipelining") {
    with_pipelining
}
Running the above simple script will provide the following figures in my Mac OS X system, running over the loopback interface, where pipelining will provide the smallest improvement as the RTT is already pretty low:
在mac os x上运行上面的脚步,和没有使用pipelining 运行的比较如下:
without pipelining 1.185238 seconds
with pipelining 0.250783 seconds
As you can see, using pipelining, we improved the transfer by a factor of five.
可以发现,使用pipelining传输速度提升了5倍

 

Pipelining VS Scripting

Using Redis scripting (available in Redis version 2.6 or greater) a number of use cases for pipelining can be addressed more efficiently using scripts that perform a lot of the work needed at the server side. A big advantage of scripting is that it is able to both read and write data with minimal latency, making operations like read, compute, write very fast (pipelining can't help in this scenario since the client needs the reply of the read command before it can call the write command).
大量的实验证明,为pipelining 使用脚步可以在服务端处理更多的工作。一个大优点是,使用脚步可以让读和写延迟小,使得读、写、计算变得很快(在客户端需要收到返回才发送命令的情况时,pipelining 是不能满足的) Sometimes the application may also want to send EVAL or EVALSHA commands in a pipeline. This is entirely possible and Redis explicitly supports it with the SCRIPT LOAD command (it guarantees that EVALSHA can be called without the risk of failing).
一些应用可能想在pipeline里发生EVAL 或者EVALSHA命令。使用SCRIOT LOAD命令是完全支持的(它保证执行没有失败的风险)

www.bkjia.comtruehttp://www.bkjia.com/DB2/1019090.htmlTechArticleredis翻译_redis管道 Redis is a TCP server using the client-server model and what is called a Request/Response protocol. redis使用的是基于tcp协议的client-server模型,也...

相关文章

相关搜索: 管道

帮客评论

视觉看点