前言
Redis是一个著名的key-value存储系统,也是nosql中的最常见的一种。其实,个人认为,redis最强大的地方不在于其存储,而在于其强大的缓存作用。
我们可以把它想象成一个巨大的(多借点集群,聚合多借点的内存)的Map,也就是Key-Value。
所以,我们可以把它做成缓存组件。
官方推荐的Java版客户端是jedis,非常强大和稳定,支持事务、管道及有jedis自身实现。我们对redis数据的操作,都可以通过jedis来完成。
那我们就来看一看,jedis不同的调用方式:
(1)普通同步方式
这是一种最简单和最基础的调用方式,对于简单的数据存取需求,我们可以通过这种方式调用。
1
2
3
4
5
6
7
8
9
10
11
|
public void jedisNormal() { Jedis jedis = new Jedis( "localhost" ); long start = System.currentTimeMillis(); for ( int i = 0 ; i < 100000 ; i++) { String result = jedis.set( "n" + i, "n" + i); } long end = System.currentTimeMillis(); System.out.println( "Simple SET: " + ((end - start)/ 1000.0 ) + " seconds" ); jedis.disconnect(); } //每次set之后都可以返回结果,标记是否成功。 |
(2)事务方式(Transactions)
所谓事务,即一个连续操作,是否执行是一个事务,要么完成,要么失败,没有中间状态。
而redis的事务很简单,他主要目的是保障,一个client发起的事务中的命令可以连续的执行,而中间不会插入其他client的命令,也就是事务的连贯性。
1
2
3
4
5
6
7
8
9
10
11
12
13
|
public void jedisTrans() { Jedis jedis = new Jedis( "localhost" ); long start = System.currentTimeMillis(); Transaction tx = jedis.multi(); for ( int i = 0 ; i < 100000 ; i++) { tx.set( "t" + i, "t" + i); } List<Object> results = tx.exec(); long end = System.currentTimeMillis(); System.out.println( "Transaction SET: " + ((end - start)/ 1000.0 ) + " seconds" ); jedis.disconnect(); } //我们调用jedis.watch(…)方法来监控key,如果调用后key值发生变化,则整个事务会执行失败。另外,事务中某个操作失败,并不会回滚其他操作。这一点需要注意。还有,我们可以使用discard()方法来取消事务。 |
(3)管道(Pipelining)
管道是一种两个进程之间单向通信的机制。
那再redis中,为何要使用管道呢?有时候,我们需要采用异步的方式,一次发送多个指令,并且,不同步等待其返回结果。这样可以取得非常好的执行效率。
1
2
3
4
5
6
7
8
9
10
11
12
|
public void jedisPipelined() { 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(); } |
(4)管道中调用事务
对于,事务以及管道,这两个概念我们都清楚了。
在某种需求下,我们需要异步执行命令,但是,又希望多个命令是有连续的,所以,我们就采用管道加事务的调用方式。jedis是支持在管道中调用事务的。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
public void jedisCombPipelineTrans() { jedis = new Jedis( "localhost" ); long start = System.currentTimeMillis(); Pipeline pipeline = jedis.pipelined(); pipeline.multi(); for ( int i = 0 ; i < 100000 ; i++) { pipeline.set( "" + i, "" + i); } pipeline.exec(); List<Object> results = pipeline.syncAndReturnAll(); long end = System.currentTimeMillis(); System.out.println( "Pipelined transaction: " + ((end - start)/ 1000.0 ) + " seconds" ); jedis.disconnect(); } //效率上可能会有所欠缺 |
(5)分布式直连同步调用
这个是分布式直接连接,并且是同步调用,每步执行都返回执行结果。类似地,还有异步管道调用。
其实就是分片。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
public void jedisShardNormal() { List<JedisShardInfo> shards = Arrays.asList( new JedisShardInfo( "localhost" , 6379 ), new JedisShardInfo( "localhost" , 6380 )); ShardedJedis sharding = new ShardedJedis(shards); long start = System.currentTimeMillis(); for ( int i = 0 ; i < 100000 ; i++) { String result = sharding.set( "sn" + i, "n" + i); } long end = System.currentTimeMillis(); System.out.println( "Simple@Sharing SET: " + ((end - start)/ 1000.0 ) + " seconds" ); sharding.disconnect(); } |
(6)分布式直连异步调用
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
public void jedisShardpipelined() { List<JedisShardInfo> shards = Arrays.asList( new JedisShardInfo( "localhost" , 6379 ), new JedisShardInfo( "localhost" , 6380 )); ShardedJedis sharding = new ShardedJedis(shards); ShardedJedisPipeline pipeline = sharding.pipelined(); long start = System.currentTimeMillis(); for ( int i = 0 ; i < 100000 ; i++) { pipeline.set( "sp" + i, "p" + i); } List<Object> results = pipeline.syncAndReturnAll(); long end = System.currentTimeMillis(); System.out.println( "Pipelined@Sharing SET: " + ((end - start)/ 1000.0 ) + " seconds" ); sharding.disconnect(); } |
(7)分布式连接池同步调用
如果,你的分布式调用代码是运行在线程中,那么上面两个直连调用方式就不合适了,因为直连方式是非线程安全的,这个时候,你就必须选择连接池调用。
连接池的调用方式,适合大规模的redis集群,并且多客户端的操作。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
public void jedisShardSimplePool() { List<JedisShardInfo> shards = Arrays.asList( new JedisShardInfo( "localhost" , 6379 ), new JedisShardInfo( "localhost" , 6380 )); ShardedJedisPool pool = new ShardedJedisPool( new JedisPoolConfig(), shards); ShardedJedis one = pool.getResource(); long start = System.currentTimeMillis(); for ( int i = 0 ; i < 100000 ; i++) { String result = one.set( "spn" + i, "n" + i); } long end = System.currentTimeMillis(); pool.returnResource(one); System.out.println( "Simple@Pool SET: " + ((end - start)/ 1000.0 ) + " seconds" ); pool.destroy(); } |
(8)分布式连接池异步调用
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
public void jedisShardPipelinedPool() { List<JedisShardInfo> shards = Arrays.asList( new JedisShardInfo( "localhost" , 6379 ), new JedisShardInfo( "localhost" , 6380 )); ShardedJedisPool pool = new ShardedJedisPool( new JedisPoolConfig(), shards); ShardedJedis one = pool.getResource(); ShardedJedisPipeline pipeline = one.pipelined(); long start = System.currentTimeMillis(); for ( int i = 0 ; i < 100000 ; i++) { pipeline.set( "sppn" + i, "n" + i); } List<Object> results = pipeline.syncAndReturnAll(); long end = System.currentTimeMillis(); pool.returnResource(one); System.out.println( "Pipelined@Pool SET: " + ((end - start)/ 1000.0 ) + " seconds" ); pool.destroy(); } |
(9)需要注意的地方
事务和管道都是异步模式。在事务和管道中不能同步查询结果。比如下面两个调用,都是不允许的:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
Transaction tx = jedis.multi(); for ( int i = 0 ; i < 100000 ; i++) { tx.set( "t" + i, "t" + i); } System.out.println(tx.get( "t1000" ).get()); //不允许 List<Object> results = tx.exec(); … … Pipeline pipeline = jedis.pipelined(); long start = System.currentTimeMillis(); for ( int i = 0 ; i < 100000 ; i++) { pipeline.set( "p" + i, "p" + i); } System.out.println(pipeline.get( "p1000" ).get()); //不允许 List<Object> results = pipeline.syncAndReturnAll(); |
事务和管道都是异步的,个人感觉,在管道中再进行事务调用,没有必要,不如直接进行事务模式。
分布式中,连接池的性能比直连的性能略好(见后续测试部分)。
分布式调用中不支持事务。
因为事务是在服务器端实现,而在分布式中,每批次的调用对象都可能访问不同的机器,所以,没法进行事务。
总结
分布式中,连接池方式调用不但线程安全外,根据上面的测试数据,也可以看出连接池比直连的效率更好。
经测试分布式中用到的机器越多,调用会越慢。
好了,以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作能带来一定的帮助,如果有疑问大家可以留言交流,谢谢大家对服务器之家的支持。
原文链接:http://blog.csdn.net/u011130752/article/details/53483388