大多数情况下，我们都会通过请求-相应机制去操作redis。只用这种模式的一般的步骤是，先获得jedis实例，然后通过jedis的get/put方法与redis交互。由于redis是单线程的，下一次请求必须等待上一次请求执行完成后才能继续执行。然而使用Pipeline模式，客户端可以一次性的发送多个命令，无需等待服务端返回。这样就大大的减少了网络往返时间，提高了系统性能。
下面用一个例子测试这两种模式在效率上的差别：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
|
public
class
PiplineTest {
private
static
int
count =
10000
;
public
static
void
main(String[] args){
useNormal();
usePipeline();
}
public
static
void
usePipeline(){
ShardedJedis jedis = getShardedJedis();
ShardedJedisPipeline pipeline = jedis.pipelined();
long
begin = System.currentTimeMillis();
for
(
int
i =
0
;i<count;i++){
pipeline.set(
"key_"
+i,
"value_"
+i);
}
pipeline.sync();
jedis.close();
System.out.println(
"usePipeline total time:"
+ (System.currentTimeMillis() - begin));
}
public
static
void
useNormal(){
ShardedJedis jedis = getShardedJedis();
long
begin = System.currentTimeMillis();
for
(
int
i =
0
;i<count;i++){
jedis.set(
"key_"
+i,
"value_"
+i);
}
jedis.close();
System.out.println(
"useNormal total time:"
+ (System.currentTimeMillis() - begin));
}
public
static
ShardedJedis getShardedJedis(){
JedisPoolConfig poolConfig =
new
JedisPoolConfig();
poolConfig.setMaxTotal(
2
);
poolConfig.setMaxIdle(
1
);
poolConfig.setMaxWaitMillis(
2000
);
poolConfig.setTestOnBorrow(
false
);
poolConfig.setTestOnReturn(
false
);
JedisShardInfo info1 =
new
JedisShardInfo(
"127.0.0.1"
,
6379
);
JedisShardInfo info2 =
new
JedisShardInfo(
"127.0.0.1"
,
6379
);
ShardedJedisPool pool =
new
ShardedJedisPool(poolConfig, Arrays.asList(info1,info2));
return
pool.getResource();
}
}
|
输出结果：
|
1
2
|
useNormal total time:
772
usePipeline total time:
112
|
从测试的结果可以看出，使用pipeline的效率要远高于普通的访问方式。
那么问题来了，在什么样的情景下适合使用pipeline呢？
有些系统可能对可靠性要求很高，每次操作都需要立马知道这次操作是否成功，是否数据已经写进redis了，那这种场景就不适合。
还有的系统，可能是批量的将数据写入redis，允许一定比例的写入失败，那么这种场景就可以使用了，比如10000条一下进入redis，可能失败了2条无所谓，后期有补偿机制就行了，比如短信群发这种场景，如果一下群发10000条，按照第一种模式去实现，那这个请求过来，要很久才能给客户端响应，这个延迟就太长了，如果客户端请求设置了超时时间5秒，那肯定就抛出异常了，而且本身群发短信要求实时性也没那么高，这时候用pipeline最好了。
来源：oschina
链接：https://my.oschina.net/u/4270692/blog/4133068