[size=medium][color=blue][b]redis的管道(Pipelining)操作是一种异步的访问模式[/b][/color][/size],一次发送多个指令,不同步等待其返回结果。这样可以取得非常好的执行效率。这就是管道,调用方法如下:
redis是一个cs模式的tcp server,使用和http类似的请求响应协议。一个client可以通过一个socket连接发起多个请求命令。每个请求命令发出后client通常会阻塞并等待redis服务处理,redis处理完后请求命令后会将结果通过响应报文返回给client。基本的通信过程如下:
[quote]Client: INCR X
Server: 1
Client: INCR X
Server: 2
Client: INCR X
Server: 3
Client: INCR X
Server: 4[/quote]
基本上四个命令需要8个tcp报文才能完成。由于通信会有网络延迟,假如从client和server之间的包传输时间需要0.125秒。那么上面的四个命令8个报文至少会需要1秒才能完成。这样即使redis每秒能处理100个命令,而我们的client也只能一秒钟发出四个命令。这显示没有充分利用 redis的处理能力。除了可以利用mget,mset 之类的单条命令处理多个key的命令外我们还可以利用pipeline的方式从client打包多条命令一起发出,不需要等待单条命令的响应返回,而redis服务端会处理完多条命令后会将多条命令的处理结果打包到一起返回给客户端。通信过程如下:
[quote]Client: INCR X
Client: INCR X
Client: INCR X
Client: INCR X
Server: 1
Server: 2
Server: 3
Server: 4[/quote]
假设不会因为tcp报文过长而被拆分。可能两个tcp报文就能完成四条命令,client可以将四个incr命令放到一个tcp报文一起发送,server则可以将四条命令的处理结果放到一个tcp报文返回。通过pipeline方式当有大批量的操作时候。我们可以节省很多原来浪费在网络延迟的时间。需要注意到是用 pipeline方式打包命令发送,redis必须在处理完所有命令前先缓存起所有命令的处理结果。打包的命令越多,缓存消耗内存也越多。所以并是不是打包的命令越多越好。具体多少合适需要根据具体情况测试。下面是个jedis客户端使用pipeline的测试:
输出:
[quote]withoutPipeline: 11341
usePipeline: 344[/quote]
测试结果还是很明显有较大的差距,所以多次操作用pipeline还是有明显的优势。我用的是Win7中的Jedis Java客户端程序连接局域网的Linux虚拟机上的Redis Server。
参考:http://blog.youkuaiyun.com/freebird_lb/article/details/7778919
@Test
public void test3Pipelined() {
Jedis jedis = new Jedis("localhost");
Pipeline pipeline = jedis.pipelined();
long start = System.currentTimeMillis();
for (int i = 0; i < 100000; i++) {
pipeline.set("p" + i, "p" + i);
}
List<Object> results = pipeline.syncAndReturnAll();
long end = System.currentTimeMillis();
System.out.println("Pipelined SET: " + ((end - start)/1000.0) + " seconds");
jedis.disconnect();
}redis是一个cs模式的tcp server,使用和http类似的请求响应协议。一个client可以通过一个socket连接发起多个请求命令。每个请求命令发出后client通常会阻塞并等待redis服务处理,redis处理完后请求命令后会将结果通过响应报文返回给client。基本的通信过程如下:
[quote]Client: INCR X
Server: 1
Client: INCR X
Server: 2
Client: INCR X
Server: 3
Client: INCR X
Server: 4[/quote]
基本上四个命令需要8个tcp报文才能完成。由于通信会有网络延迟,假如从client和server之间的包传输时间需要0.125秒。那么上面的四个命令8个报文至少会需要1秒才能完成。这样即使redis每秒能处理100个命令,而我们的client也只能一秒钟发出四个命令。这显示没有充分利用 redis的处理能力。除了可以利用mget,mset 之类的单条命令处理多个key的命令外我们还可以利用pipeline的方式从client打包多条命令一起发出,不需要等待单条命令的响应返回,而redis服务端会处理完多条命令后会将多条命令的处理结果打包到一起返回给客户端。通信过程如下:
[quote]Client: INCR X
Client: INCR X
Client: INCR X
Client: INCR X
Server: 1
Server: 2
Server: 3
Server: 4[/quote]
假设不会因为tcp报文过长而被拆分。可能两个tcp报文就能完成四条命令,client可以将四个incr命令放到一个tcp报文一起发送,server则可以将四条命令的处理结果放到一个tcp报文返回。通过pipeline方式当有大批量的操作时候。我们可以节省很多原来浪费在网络延迟的时间。需要注意到是用 pipeline方式打包命令发送,redis必须在处理完所有命令前先缓存起所有命令的处理结果。打包的命令越多,缓存消耗内存也越多。所以并是不是打包的命令越多越好。具体多少合适需要根据具体情况测试。下面是个jedis客户端使用pipeline的测试:
package com.jd.redis.client;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.Pipeline;
publicclass PipelineTest {
/**
* @param args
*/
publicstaticvoid main(String[] args) {
int count = 1000;
long start = System.currentTimeMillis();
withoutPipeline(count);
long end = System.currentTimeMillis();
System.out.println("withoutPipeline: " + (end-start));
start = System.currentTimeMillis();
usePipeline(count);
end = System.currentTimeMillis();
System.out.println("usePipeline: " + (end-start));
}
privatestaticvoid withoutPipeline(int count){
Jedis jr = null;
try {
jr = new Jedis("10.10.224.44", 6379);
for(int i =0; i<count; i++){
jr.incr("testKey1");
}
} catch (Exception e) {
e.printStackTrace();
}
finally{
if(jr!=null){
jr.disconnect();
}
}
}
privatestaticvoid usePipeline(int count){
Jedis jr = null;
try {
jr = new Jedis("10.10.224.44", 6379);
Pipeline pl = jr.pipelined();
for(int i =0; i<count; i++){
pl.incr("testKey2");
}
pl.sync();
} catch (Exception e) {
e.printStackTrace();
}
finally{
if(jr!=null){
jr.disconnect();
}
}
}
}输出:
[quote]withoutPipeline: 11341
usePipeline: 344[/quote]
测试结果还是很明显有较大的差距,所以多次操作用pipeline还是有明显的优势。我用的是Win7中的Jedis Java客户端程序连接局域网的Linux虚拟机上的Redis Server。
参考:http://blog.youkuaiyun.com/freebird_lb/article/details/7778919
介绍Redis管道(Pipelining)操作,一种异步访问模式,允许客户端批量发送命令减少网络延迟,显著提高执行效率。
549

被折叠的 条评论
为什么被折叠?



