Redis(十七):批量操作Pipeline详解大数据

大多数情况下,我们都会通过请求-相应机制去操作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最好了。

原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/9742.html

(0)
上一篇 2021年7月19日
下一篇 2021年7月19日

相关推荐

发表回复

登录后才能评论