Shardedjedis (distributed) use method under Jedis (i)

The original project was useful to Redis as a caching service, and only one redis was able to satisfy the service at first, and as the project slowly went on, it was found that one could not meet the existing project requirements, because Redis operations were atomic, resulting in a decrease in query efficiency at the same time as read-write caching. But since we're still using 2. x version, or no clustering functionality (Redis authors have joined the cluster feature in version 3.0), so they can only implement distributed caching using one of the included versions of the 2.x version called Shardedjedis.

Shardedjedisis throughConsistent HashTo achieve distributed cache, through a certain strategy to assign different keys to different Redis server, to achieve the purpose of scale-out. SoShardedjedisHow the interior is implemented, the article will be slowly explained.

1.ShardedjedisHow to use

ShardedjedisThe use of methods in addition to the configuration of a little difference, and other Jedis basically similar, one thing to note isShardedjedisMulti-command operation not supported,like Mget, Mset, Brpop and so on Redis command can be one-time operation of multiple key commands, including which, you can see Jedis under the multikeycommands This class, where the face contains all the multi-command operation. It's nice to know that the Redis author has filtered these commands out of the Shardedjedis , and they don't call them when they're used.

Okay, now look at the basic use

 　　 //set up configuration for connection poolingJedispoolconfig Poolconfig =NewJedispoolconfig (); Poolconfig.setmaxtotal (2); Poolconfig.setmaxidle (1); Poolconfig.setmaxwaitmillis (2000); Poolconfig.settestonborrow (false); Poolconfig.settestonreturn (false); //set up Redis informationString host = "127.0.0.1"; Jedisshardinfo ShardInfo1=NewJedisshardinfo (host, 6379, 500); Shardinfo1.setpassword ("Test123"); Jedisshardinfo ShardInfo2=NewJedisshardinfo (host, 6380, 500); Shardinfo2.setpassword ("Test123"); Jedisshardinfo ShardInfo3=NewJedisshardinfo (host, 6381, 500); Shardinfo3.setpassword ("Test123"); //Initialize ShardedjedispoolList<jedisshardinfo> infolist =arrays.aslist (ShardInfo1, ShardInfo2, ShardInfo3); Shardedjedispool Jedispool=NewShardedjedispool (Poolconfig, infolist); //perform other operations such as queryingShardedjedis Jedis =NULL; Try{Jedis=Jedispool.getresource (); Jedis.set ("Test", "test"); Jedis.set ("Test1", "Test1"); String Test= Jedis.get ("Test");            SYSTEM.OUT.PRINTLN (test); ......        } finally {             //must be closed after use, back to the connection pool
　　　if (jedis!=null) {

Jedis.close ();
}        }                

Jedis must be closed after getting it, this is the same as we use the database connection pool, put in the finally block to ensure that the Jedis is closed.

PS: If you use the JDK version 1.7 or above, you can use the 1.7 try-with-resources statement

       Try (Shardedjedis Jedis = Jedispool.getresource ()) {            Jedis.set ("test", "Test");            Jedis.set ("Test1", "test1");             = Jedis.get ("test");            SYSTEM.OUT.PRINTLN (test);        }

try-with-resources 's effect is the same as the one we've written above, just Jedis.close () syntax it will help us invoke it, it will call us in try-with-resources by default Statement that is declared in the the Close method of the object that implements the closeable interface (like the Shardedjedis above), which is used by the database connection connection and some input and output streams that we often use.

From the code, in addition to the initialization of Shardedjedispool need to join a number of Redis server information, the other and Jedis use similar.

When initializing shardedjedispool , we can also pass in shardedjedis uses a HASH algorithm that supports murmur_hash and md5 two algorithms, which by default are used (You can view the redis.clients.util.hashing Class View related information)

You can also pass in keytagpattern To specify the distribution strategy of our key, all of which can match the Keytagpattern Key (through regular matching) will be placed in the same Redis, the default is to use key directly to determine. Redis comes with a sharded. Keytagpattern, as follows

Pattern Default_key_tag_pattern = Pattern.compile ("\\{(. +?) \\}");

We can use the following code to actually test the

Shardedjedis Jedis =Jedispool.getresource ();

Jedis.set ("Cnblog", "Cnblog"); Jedis.set ("Redis", "Redis"); Jedis.set ("Test", "test"); Jedis.set ("123456", "1234567"); Client client1= Jedis.getshard ("Cnblog"). Getclient (); Client Client2= Jedis.getshard ("Redis"). Getclient (); Client Client3= Jedis.getshard ("Test"). Getclient (); Client Client4= Jedis.getshard ("123456"). Getclient (); ////print key in which serverSystem.out.println ("Cnblog in Server:" + client1.gethost () + "and port is:" +Client1.getport ()); System.out.println ("Redis in Server:" + client2.gethost () + "and port is:" +Client2.getport ()); System.out.println ("Test in Server:" + client3.gethost () + "and port is:" +Client3.getport ()); System.out.println ("123456 in Server:" + client4.gethost () + "and port is:" + client4.getport ());

Look at the output content:

You can see that the 4 Key,cnblog and Redis we saved are in the same Redis server, and the other two are in a separate Redis server.

ShardedjedisA consistent hash algorithm is used to determine the location of each key, how to calculate, in the next article will be studiedJedisThe source code to see.

Shardedjedis (distributed) use method under Jedis (i)