MyException - 我的异常网
当前位置:我的异常网» 数据库 » redis通译_redis管道

redis通译_redis管道

www.MyException.Cn  网友分享于:2015-08-26  浏览:0次
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命令是完全支持的(它保证执行没有失败的风险)


文章评论

程序员的一天:一寸光阴一寸金
程序员的一天:一寸光阴一寸金
程序员最害怕的5件事 你中招了吗?
程序员最害怕的5件事 你中招了吗?
科技史上最臭名昭著的13大罪犯
科技史上最臭名昭著的13大罪犯
60个开发者不容错过的免费资源库
60个开发者不容错过的免费资源库
看13位CEO、创始人和高管如何提高工作效率
看13位CEO、创始人和高管如何提高工作效率
2013年中国软件开发者薪资调查报告
2013年中国软件开发者薪资调查报告
旅行,写作,编程
旅行,写作,编程
亲爱的项目经理,我恨你
亲爱的项目经理,我恨你
老美怎么看待阿里赴美上市
老美怎么看待阿里赴美上市
什么才是优秀的用户界面设计
什么才是优秀的用户界面设计
我是如何打败拖延症的
我是如何打败拖延症的
当下全球最炙手可热的八位少年创业者
当下全球最炙手可热的八位少年创业者
程序员和编码员之间的区别
程序员和编码员之间的区别
Google伦敦新总部 犹如星级庄园
Google伦敦新总部 犹如星级庄园
Web开发人员为什么越来越懒了?
Web开发人员为什么越来越懒了?
鲜为人知的编程真相
鲜为人知的编程真相
编程语言是女人
编程语言是女人
“懒”出效率是程序员的美德
“懒”出效率是程序员的美德
程序员必看的十大电影
程序员必看的十大电影
团队中“技术大拿”并非越多越好
团队中“技术大拿”并非越多越好
不懂技术不要对懂技术的人说这很容易实现
不懂技术不要对懂技术的人说这很容易实现
做程序猿的老婆应该注意的一些事情
做程序猿的老婆应该注意的一些事情
代码女神横空出世
代码女神横空出世
漫画:程序员的工作
漫画:程序员的工作
“肮脏的”IT工作排行榜
“肮脏的”IT工作排行榜
Java程序员必看电影
Java程序员必看电影
为什么程序员都是夜猫子
为什么程序员都是夜猫子
10个调试和排错的小建议
10个调试和排错的小建议
10个帮程序员减压放松的网站
10个帮程序员减压放松的网站
程序员的鄙视链
程序员的鄙视链
十大编程算法助程序员走上高手之路
十大编程算法助程序员走上高手之路
 程序员的样子
程序员的样子
我跳槽是因为他们的显示器更大
我跳槽是因为他们的显示器更大
我的丈夫是个程序员
我的丈夫是个程序员
程序猿的崛起——Growth Hacker
程序猿的崛起——Growth Hacker
2013年美国开发者薪资调查报告
2013年美国开发者薪资调查报告
写给自己也写给你 自己到底该何去何从
写给自己也写给你 自己到底该何去何从
聊聊HTTPS和SSL/TLS协议
聊聊HTTPS和SSL/TLS协议
总结2014中国互联网十大段子
总结2014中国互联网十大段子
一个程序员的时间管理
一个程序员的时间管理
如何区分一个程序员是“老手“还是“新手“?
如何区分一个程序员是“老手“还是“新手“?
中美印日四国程序员比较
中美印日四国程序员比较
那些性感的让人尖叫的程序员
那些性感的让人尖叫的程序员
老程序员的下场
老程序员的下场
要嫁就嫁程序猿—钱多话少死的早
要嫁就嫁程序猿—钱多话少死的早
程序员周末都喜欢做什么?
程序员周末都喜欢做什么?
如何成为一名黑客
如何成为一名黑客
Web开发者需具备的8个好习惯
Web开发者需具备的8个好习惯
初级 vs 高级开发者 哪个性价比更高?
初级 vs 高级开发者 哪个性价比更高?
软件开发程序错误异常ExceptionCopyright © 2009-2015 MyException 版权所有