图书馆信息化网站建设,搜索引擎优化至少包括哪几步,网站怎么在工信部备案信息,秀洲住房与建设局网站写在前面去年下半年#xff0c;出于学习Redis的目的#xff0c;在看完《Redis in Action》一书后#xff0c;开始尝试翻译Redis官方文档。尽管Redis中文官方网站有了译本#xff0c;但是看别人翻译好的和自己翻译英文原文毕竟还是有很大的不同。这一系列文章之前发布在GitB…写在前面去年下半年出于学习Redis的目的在看完《Redis in Action》一书后开始尝试翻译Redis官方文档。尽管Redis中文官方网站有了译本但是看别人翻译好的和自己翻译英文原文毕竟还是有很大的不同。这一系列文章之前发布在GitBook上为了方便管理跟其他文章一起放在同一个平台遂全部迁移至简书。由于本人学习Redis时间不长认识有限同时也缺少实战经验翻译中有任何不恰当之处欢迎各位及时斧正本人将不胜感激。对英文官方文档感兴趣的朋友也可以直接访问https://redis.io/ 进行获取。使用流水线来提升redis的查询速度请求/响应协议和RTTRedis是一个使用客户端-服务端模型和请求/响应协议的TCP服务。这意味着完成一次请求通常需要经过以下步骤客户端向服务端发起一次查询请求并读取socket这通常是以阻塞方式来等待服务端响应。服务端处理命令并将响应发回给客户端。例如下面是一个4条命令序列的执行情况客户端INCR x服务端1客户端INCR x服务端2客户端INCR x服务端3客户端INCR x服务端4客户端和服务端通过网络来连接。这样的连接可以很快(loopback接口)也可以很慢(两台主机之间建立的是一个经过了多次跳转的网络连接)。不管网络延迟如何数据包从客户端发往服务端然后携带响应从服务端发往客户端总是会消耗时间的。这个时间被称为RTT(Round Trip Time)。当客户端需要一次性处理很多请求时很容易看到这是如何影响到性能的(比如说向一个列表中添加很多元素或者用很多键值填充数据库)。例如假设RTT时间为250毫秒(在网络连接很慢的网络条件下)那么即使服务端每秒可以处理100000个请求我们每秒最多也只能处理4个请求。如果使用loopback接口RTT时间就会短很多(例如在我的机器上ping127.0.0.1只需要0.044毫秒)但是如果我们需要批量处理很多写请求这个时间仍然是很大的一笔开销。好在我们还有一种方式可以来改善这种状况。Redis流水线即使客户端旧的请求还没有得到响应一个请求/响应服务器也可以处理新的请求。这样一来我们就可以一次向服务端发送多条命令而根本不用等待响应最后在一个步骤中读取所有回复。这就是流水线这是一种几十年来被广泛采用的技术。例如很多POP3协议的实现已经支持了这种特性它极大地加快了从服务器下载新邮件的过程。Redis很早就支持了流水线功能所以无论你正在使用的是哪个版本你都可以使用Redis的流水线技术。下面是一个使用这种原生能力的例子$ (printf PING\r\nPING\r\nPING\r\n; sleep 1) | nc localhost 6379PONGPONGPONG这一次我们没有为每次调用都消耗RTT而是4个命令只消耗一次时间。更明确地说通过使用流水线技术我们第一个例子的操作顺序将会是下面这个样子客户端: INCR x客户端: INCR x客户端: INCR x客户端: INCR x服务端:1服务端:2服务端:3服务端:4重要提示当客户端使用流水线技术来发送命令时服务端将不得不使用内存来排队答复。所以如果你需要使用流水线来发送很多命令最好是将他们按照合理的数量来分批处理比如先发送10000条命令读取响应再发送另外10000条命令等等。速度几乎是一样的但是将需要大量额外的内存来存储这10000条命令的答复。这不仅仅关乎RTT流水线不仅仅是一种用来减少RTT延迟成本的方式实际上对于一台给定的Redis服务器它极大地提高了每秒钟你所能处理的操作数量。一个事实是当不采用流水线技术时从访问数据结构并且产生响应的角度来看每一条命令的时间消耗都是很少的但是从处理socket IO的角度来看这个时间消耗确是很大的。它涉及到调用read()和write()这些系统调用这意味着要从用户侧到内核侧。而上下文切换是一个巨大的时间开销会严重影响响应速度。当使用流水线时一个简单的read()系统调用就可以读取很多命令同样的一个简单的write()系统调用就可以将很多回复传送出去。正因为如此每秒钟可以处理的查询命令的数量几乎随着管道长度的增加而呈线性增长最终可以达到不使用流水线这种基本情况时的10倍正如你从下图看到的那样image.png一些真实世界的代码样例在下面这个基准测试中我们将会使用基于Ruby的redis客户端支持流水线操作来测试流水线对于速度的提升效果require rubygemsrequire redisdef bench(descr)start Time.nowyieldputs #{descr} #{Time.now-start} secondsenddef without_pipeliningr Redis.new10000.times {r.ping}enddef with_pipeliningr Redis.newr.pipelined {10000.times {r.ping}}endbench(without pipelining) {without_pipelining}bench(with pipelining) {with_pipelining}在我的Mac OS X系统上执行上面这个简单的脚本将会得到如下的数据开启流水线功能后RTT已经被改善得相当低。without pipelining 1.185238 secondswith pipelining 0.250783 seconds如你所见开启流水线后我们把传输速度提升了5倍。流水线 VS 脚本使用Redis脚本(2.6及以上版本的redis可用)很多使用流水线的场景可以获得更高效的处理因为使用脚本可以在服务端执行大量工作。脚本的一大优势是它可以使读写数据只需要很小的时延使得读、计算和写操作变得很快(流水线在这种场景下做不到这一点因为客户端在调用写命令之前需要读命令的返回结果)有时候应用也会需要向流水线发送EVAL或者EVALSHA命令。这完全是有可能的并且Redis已经通过SCRIPT LOAD命令明确支持了这一点(它保证EVALSHA命令会调用成功)。附录为什么即使在loopback接口上一个忙碌的循环也很慢即使在这个页面的背景之下你还是会想知道为什么即使在loopback接口上执行并且服务端和客户端运行在同一台物理机上时一个一个像下面的Redis基准测试(伪代码)还是会很慢FOR-ONE-SECOND:Redis.SET(foo,bar)END毕竟如果Redis过程和基准测试运行在一起时难道它不是仅仅将信息在内存上从一个地方复制到另一个地方中间没有任何真正的延时和网络参与进来吗原因在于系统上的过程不是一直在运行实际上是内核调度器才让过程运行起来所以基准测试开始运行时从Redis服务端读取返回数据(跟最后一条执行的命令相关)并且写了一条新命令。现在命令存在于loopback接口的缓存里但是为了能够被服务端读取到内核会通过调度让服务端的过程(当前被阻塞在系统调用里)运行起来等等。所以在实际场景下因为内核调度器的工作机制loopback接口还是涉及到了类网络延时。基本上在网络服务器中测量性能时一个忙碌的循环基准测试是最愚蠢的事情。明智的做法是避免使用这种方法进行基准测试。
