foreword
Earlier we talked about how to build Redis Cluster, which is also based on the principle of application priority, so there is almost no reference to its basic concepts and principles, but after learning how to build Redis Cluster, we still need to know something about it. So in this blog, we will learn some related knowledge of Redis Cluster together.
guide
Before starting the explanation of Redis Cluster, friends who are not familiar with Redis Cluster and don’t know how to build Redis Cluster can go to the following blog first:
Java development - Redis cluster construction that allows you to avoid detours
After reading this blog, we will start to popularize some basic knowledge in it.
Redis Cluster
What is Redis Cluster?
We must first know that Redis Cluster is a decentralized sharding cluster that appeared after Redis3.0. The traditional Redis cluster is implemented based on master-slave replication plus sentinels. In the previous article, the blogger also has a detailed construction process and principle analysis:
Java development - Master-slave replication of Redis that allows you to avoid detours
Java development - in-depth understanding of the principle of Redis sentinel mechanism
Friends in need go to check it out by themselves. In this traditional Redis cluster, there can only be one node at most to provide write services, and no one can change this.
Different from the traditional Redis cluster mode, after Redis3.0, Redis Cluster supports multi-master and multi-slave methods, that is, multiple master nodes can be started at the same time, and other slave nodes can be linked under the master node. During this process, the Cluster will distribute the data to multiple master nodes, and these master nodes can also provide external read and write services. This method breaks through the memory size limit of Redis stand-alone storage and expands the storage capacity of the cluster. Not only that, each master node of Redis Cluster has at least one slave node. When a master node hangs up, Redis Cluster switches its slave node to a new master node through failover.
Summary: Redis Cluster is a decentralized Redis cluster. Each node will maintain intercommunication with other nodes, exchange information, detect newly added nodes, and monitor shrinking nodes through the gossip protocol. The biggest advantage is that Redis Cluster does not require any proxy, and the client will directly connect to the nodes in the cluster.
Note: Each redis needs to release two port numbers, one is 6379, and the other is +10000 on this basis, that is, 16379, which is used for communication between nodes! ! !
Fragmentation
When creating a Redis Cluster cluster, you need to ensure at least 6 Redis services. Don’t doubt, there are 6. The master nodes in these 6 Redis will divide the 16384 Slot slots of redis according to certain rules. We call this process Fragmentation will also be what we will explain next.
Slot slot is an important concept of Redis Cluster, which splits the hash table into multiple small hash tables and distributes these small hash tables on different nodes. Each node manages one or more Slot slots, and each Slot slot contains certain data. This fragmentation method can improve the scalability and reliability of Redis, and avoid the problem of all data loss when a single point of failure occurs.
hash modulo
Hash modulo is similar to the way we use HashMap to select addresses. We perform hash calculation on the key of the value to be stored, which is actually a crc16 check. Based on the final value, it is determined which Slot it should be assigned to. And this Slot also determines which node it is on.
There is a problem here. When expanding or shrinking, the Slot slot may need to be re-allocated, which will cause the key to recalculate the storage location, resulting in cache failure, but we should also know that this situation does not always occur. .
consistent hashing
Consistent hashing forms the hash value into a closed virtual ring with a size between 0 and 2^32-1. Are you familiar with this value? Let's look at the picture below:
This is a state diagram before expansion. We calculate the hash value of the key, determine its position on the ring, and then start searching clockwise. The first node we find is the node where the key is located. Isn’t it very simple?
But when we need to insert or delete nodes in this ring, there is no need to recalculate the keys in the entire ring/cluster, and the consistent hash algorithm will limit the impact of adding or deleting nodes to adjacent nodes , without affecting other nodes. As shown below:
When we add a new node5 between node2 and node4, only part of the data of node4 will be migrated to node5 at this time. If the service of node4 is offline, then the data of node4 will only be migrated to the adjacent node3. Yes Isn't it amazing?
The consistent hashing algorithm is good when there are many nodes, but when there are few nodes, the slot or data will be unevenly distributed due to the deletion of nodes. For the first 4 nodes in the above figure, If a node is deleted, the data of a node will inevitably change from a quarter (1/4) to a half (1/2).
The above is the worst result, but when expanding and shrinking, how to allocate the slots when reallocating, this rule is in our hands. For example, manual allocation is easy to cause food, and Slot has an automatic balancing algorithm, which is done by rehash operation through redis-trib. But I still want to remind everyone, use it with caution in the production environment! ! !
Virtual Node + Consistent Hash
Sometimes, the distribution of nodes on the ring is seriously uneven, that is, the distribution of slots is uneven, and the number of nodes is small, which will lead to avalanche and data skew. At this time, a new method based on consistent hashing is proposed. The way of the virtual node, as shown in the figure below:
Note: Real nodes are not placed on the hash ring, only virtual nodes are placed! ! !
This method changes the method of preempting the hash ring through the actual node into the method of preempting the virtual node under the actual node. Simply put, the virtual node is used to map the actual node. The advantage is that when expanding or shrinking, Other nodes only need to allocate part of the slots under their own virtual nodes to achieve even distribution of slots. This looks like a load balancing distribution method, which is exactly what we want.
election strategy
Before I say it, I would like to recommend a few blogs to you:
Detailed explanation of the principle of Redis cluster mode (Cluster)
redis (6) Redis Cluster cluster principle
Redis Learning (2) Redis Cluster Cluster
Everyone’s blogs have their own strengths and weaknesses, so they need to be checked comprehensively. Below, the blogger writes some of his thoughts on the election of Redis Cluster, hoping to help everyone.
As we said in the previous Redis sentinel cluster mode, the communication between Redis uses the gossip protocol, which contains a variety of messages, including ping, pong, meet, fail, etc. What do they do? Let's first understand them one by one.
- Ping: Each node will send ping commands to other nodes every second, including its own status and metadata information of the cluster it maintains;
- pong: pong is a reply to ping and meet messages, including its own status and other information, and is also used for information broadcast and update;
- meet: A node sends a meet command to a newly joined node. As soon as the two nodes meet, the new node joins the cluster, and then starts to communicate with other nodes through the ping command;
- Fail: After the slave node judges that its master node fails, it broadcasts fail to other nodes, notifies other nodes that a certain node is down, and then starts the election;
After passing the fail broadcast, the election will not start immediately. There is a compatible strategy for network jitter. There is such a parameter in the configuration file: cluster-node-timeout. After this time, the ping information of this node cannot be received, and the election strategy will start.
Before explaining, we want to declare that only the master node has the right to elect, and the slave node is only responsible for master-slave replication. If you configure the read permission, the slave node will also have the right to read. In addition, the slave node also has It can only be broadcast and has no other rights. (If I am wrong, please correct me) I think this thing can be concluded from the terminal output tested during the previous cluster building process. I went back and looked at it, and found that there is no screenshot of the cluster election process, but in the sentinel cluster, We can see the sentinel election process, but there is no reference value here, and we will take screenshots for you to see when we build a cluster later.
- When the master goes down, the first to find that it is offline is usually its own slave, and the master status changes to FAIL;
- The slave first increases its own epoch (currentEpoch) by one, and requests other masters to vote for itself. This message broadcasts the FAILOVER_AUTH_REQUEST packet to every master in the cluster through the slave;
- After that, the slave will wait at least twice as long as NODE_TIMEOUT to receive the voting results. Regardless of the value of NODE_TIMEOUT, it will wait at least 2 seconds. This is the market for the broadcast to be received by the other party. The broadcast is once per second, so it is 2s;
- The master responds to the slave with FAILOVER_AUTH_ACK after receiving the vote, and will not vote for other slaves of the same master within (NODE_TIMEOUT*2) time, because the master may have more than one slave, but at the same time, only one slave can initiate an election;
- If the epoch value of the slave receiving the FAILOVER_AUTH_ACK response is smaller than its own epoch, it will be discarded directly. Otherwise, once the slave receives the FAILOVER_AUTH_ACK from most masters, it declares that it has won the election;
- If the slave does not win the election within twice the NODE_TIMEOUT time (at least 2 seconds), it will give up this election, and then re-initiate the election after four times the NODE_TIMEOUT time (at least 4 seconds);
currentEpoch is a parameter related to the state of the cluster, which can be used as an incremental version number for recording changes in the state of the cluster. Each cluster node will record the current currentEpoch through server.cluster->currentEpoch. When a cluster node is created, whether it is a master or a slave, the currentEpoch is 0. If the node receives a packet from another node, the sender's currentEpoch (the message header will contain the sender's currentEpoch) is greater than the currentEpoch of the current node, then the current The node will update the currentEpoch to the sender's currentEpoch. As a result, the currentEpoch of all nodes in the cluster will eventually reach a consensus, which is equivalent to reaching a consensus on the cognition of the cluster state, which is also the meaning of the existence of the cluster, that is, to achieve final consistency.
epilogue
So far, the knowledge points about Redis Cluster have been introduced to you. What other secrets do you know about Redis Cluster? Welcome to the comment area to add, let's discuss together. But having said that, there are not many companies that can afford Redis Cluster, right? Just these six nodes cost a lot of money every year, not to mention there are other service nodes. It can only be said that the companies that can afford it are really inhumane!