Redis pre-slicing technology to achieve

In peacetime, we will create multiple Redis instances to alleviate the single redis stress paradigm. However, as the number of caches increases. To Redis for extensions is a non--don't matter. There are several methods for Redis to expand the possibilities. Let's add each Redis maximum memory instance.

and lacks flexibility and scalability. On the Redis official web site, pre-shard technology is mentioned. This article will explain the pre-shard technology and explain how Jedis supports the shards at the same time.

First, Redis pre-shard technology

Build multiple Redis instances on a single server. When you need to expand. Can be extended using the replication mechanism. As usual, the following steps are:

1) Create an empty Redis instance on the new server.

2) Configure the new Redis instance as the slave instance of the source instance to lead the source data to the new instance.

3) Stop the client (e.g. Jedis).

4) Update the client-configured instance IP to the new server address.

Note that this replaces the old IP address and cannot be appended or swapped in the order of the addresses.

5) Send the slaveof NO one command on the new server. Make it no longer a slave instance.

6) Restart the client with the new configuration.

7) Finally stop old instances that are no longer used on the old server.

Here's a question, replace the old IP address. can keyword be mapped to the appropriate new Redis instance before mapping to the old Redis instance? Analysis will be performed later in this article.

Second, Jedis to the realization of the Shard technology

Jedis supports sharding technology. Several major classes are involved. Mainly divided into two parts:

1) record the address information for each Redis instance. As can be seen from the class diagram, Shardinfo and jedisshardinfo implement this function;

2) Use a consistent hash algorithm. Mapping of keyword and Redis instances. It can be seen from the class diagram that sharded provides a base class for this functionality, and Binaryshardedjedis and Shardedjedis are respectively implementations of bytes and strings.

When the Sharded class is created, an initialization method is run. Through the hash algorithm, each Redis instance obtains 160 hash value, and the value as TreeMap key, the Redis instance's Shardinfo information as value. Note: When calculating the hash value. Instead of using an IP address, an alias is used.

The alias is either set in Shardinfo or generated by a certain rule. The following code can be seen in detail:

    private void Initialize (list<s> shards) {nodes = new Treemap<long, s> (); for (int i = 0; I! = Shards.size (); + + i) {    final S shardinfo = Shards.get (i);    if (shardinfo.getname () = = null) for (int n = 0; n < * Shardinfo.getweight (); n++) {    nodes.put (This.algo.hash ("S hard-"+ i +"-node-"+ N),    shardinfo);}    elsefor (int n = 0; n < * Shardinfo.getweight (); n++) {Nodes.put (This.algo.hash (Shardinfo.getname (    ) + "*"    + shardinfo.getweight () + N), shardinfo);}    Resources.put (Shardinfo, Shardinfo.createresource ());}    }

By not using an IP address for hashing, you can avoid the data in the cache from being inaccessible when the IP address changes.

Here are answers to the questions raised earlier.

As a matter of fact. This is the implementation of the consistent hashing algorithm. This algorithm is also used by memcached. A 160 hash value. is actually a single instance of a virtual node on the Hashi. Assuming that a virtual node is not established, a node is stressed when it is augmented or deleted, assuming that a virtual node is established that can break down the pressure onto each Redis instance.



Copyright notice: This article Bo Master original article. Blog, not reproduced without consent.

Redis pre-slicing technology to achieve