复述是一种基于客户端——服务端模型以及请求/响应协议的TCP服务。这意味着通常情况下复述,客户端执行一条命令分为如下四个过程:
-
<李>发送命令李
<李>命令排队李
<李>命令执行
<李>返回结果李
客户端向服务端发送一个查询请求,并监听插座返回,通常是以阻塞模式,等待服务端响应。服务端处理命令,并将结果返回给客户端。客户端和服务端通过网络进行连接。这个连接可以很快,也可能很慢。无论网络如何延迟,数据包总是能从客户端到达服务端,服务端返回数据给客户端。
这个时间被称为RTT(往返时间),例如上面过程的发送命令和返回结果两个过程。当客户端需要连续执行多次请求时很容易看到这是如何影响性能的(例如,添加多个元素到同一个列表中),例如,如果RTT时间是250毫秒(网络连接很慢的情况下),即使服务端每秒能处理100 k的请求量,那我们每秒最多也只能处理4个请求。如果使用的是本地环回接口,RTT就短得多,但如如果需要连续执行多次写入,这也是一笔很大的开销。
下面我们看一下执行N次命令的模型:
我们可以使用管道改善这种情况.Pipeline并不是一种新的技术或机制,很多技术上都使用过.RTT在不同网络环境下会不同,例如同机房和同机房会比较快,跨机房跨地区会比较慢.Redis很早就支持管道技术,因此无论你运行的是什么版本,你都可以使用管道操作复述。
管道能将一组复述,命令进行组装,通过一次RTT传输给复述,再将这组复述,命令按照顺序执行并将结果返回给客户端上。图没有使用管道执行了N条命令,整个过程需要N次RTT。下图为使用管道执行N条命令,整个过程仅需要1次RTT:
复述,提供了批量操作命令(例如mget, mset等),有效的节约了RTT。但大部分命令是不支持批量操作的。
能也提供了对管道特性的支持。我们可以借助管道来模拟批量删除,虽然不会像mget和mset那样是一个原子命令,但是在绝大数情况下可以使用:
下表给出了不同网络环境下非管道和管道执行10000次操作的效果:
网络
延迟
非管道
管道
本机
0.17毫秒
573毫秒
134毫秒
内网服务器
0.41毫秒
1610毫秒
240毫秒
异地机房
7女士
女士78499
1104毫秒
因测试环境不同可能会得到不同的测试数据,本测试管道每次携带100条命令。
我们可以从上表中得出如下结论:
<李>管道执行速度一般比逐条执行要快。 <李>客户端和服务端的网络延时越大,管道的效果越明显。
下面我们看一下批量命令与管道的区别:
<李>原生批量命令是原子的,管道是非原子的。 <李>原生批量命令是一个命令对应多个键,管道支持多个命令。 <李>原生批量命令是复述,服务端支持实现的,而管道需要服务端和客户端的共同实现。
使用管道发送命令时,每次管道组装的命令个数不能没有节制,否则一次组装的命令数据量过大,一方面会增加客户端的等待时间,另一方面会造成一定的网络阻塞,可以将一次包含大量命令的管道拆分成多个较小的管道来完成。
好了,以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,谢谢大家对的支持。
复述,利用管道加速查询速度的方法
