This is the 25th day of my participation in the First Challenge 2022

Yesterday we talked about the implementation of JedisPool, today we look at the implementation of JedisCluster, we know that Redis will automatically help us to do a data fragment, a node will be divided into 16384 data pieces, can help us do some key distribution and mapping. In this way, if some nodes go down, the HashSlot of other nodes will not be affected, ensuring availability in certain cases. Let’s take a look at this.

JedisCluster

First, let’s look at constructors. This class gives us a lot of overloaded constructors, and we only need to see the last one called, which is the following:

Node is our node, with some simple configuration, and then calls the constructor of the parent class. If we click on it, we can see that it initializes a node handler and a maximum number of attempts:

Then we click on the connection handler and see the following constructor:

Then we click on the parent constructor and see that it caches some cluster information and then performs an initialization like this:

Here you can see some initialization information, which is common configuration.

There’s a method under this class which is the following method, and that method has a variable called slots. What’s that for? Slotindo is a collection of node information. Slotindo is the information of each node, including the upper limit of slot 0, the lower limit of slot 1, the information of the primary node at slot 2, and the information of the secondary node at slot 3.

Gets the set of slots

The following is the operation of parsing node information, obtaining node information and allocating node information. Only the information parsed is the information of the master node, then the allocation is carried out. If it is not the master node, the IP and address splicing is used as the key, and the jedispool is cached as the value.