1. Consistent hash algorithm?
Taking distributed cache as an example, assuming that there are 3 cache servers (S0, S1, S2), and to distribute some pictures to different servers as evenly as possible, the method of hash algorithm is: (1) Use the name of the
picture As a key, and then perform a hash operation on it.
(2) Compute the remainder of the hash value to the number of servers to get the server number, and finally save it.
Take a chestnut:
csdn.jpg needs to be stored, we will get hash(csdn.jpg) = 5 -------> 5%3 = 2 and get the data stored in S2
Thinking:
The above algorithm seems to be able to balance the picture When obtaining data, you can also access the corresponding server according to the same idea, avoiding global scanning. However, at this time, the server has been expanded and S4 has been added. Can we still obtain data normally?
Assuming that csdn.jpg is still obtained according to the same idea, we will get hash(csdn.jpg)%4 = 1. Obviously, we cannot obtain data when we go to S1. At this time, the cache may collapse, and a large number of requests will fall to the database.
So what should we do?
Consistency hash algorithm
Consistency hash algorithm will create a hash ring with 2^32 slots (0 - 2 32-1), assuming that there are three servers A, B, and C, and A will perform hash (A)%2 32, get a number between 0 - 2^32-1, and then map it to the hash ring, as shown in the figure:
Next, we also take csdn.jpg as an example, we still calculate the value of hash(csdn.jpg)%2^32, and then map to the hash ring, and then start from this point, clockwise to the first server encountered , which is the server where the data will be stored.
What will happen if server D is added at this time?
If server D is inserted between A - C at this time, when requesting getKey(csdn.jpg), the server obtained clockwise is D, and the data is obtained from D Of course it will fail, because the data is cached on A. It seems that the cache is still invalid.
So what are the benefits of making a hash ring?
Although the cache of csdn.jpg is invalid after node D is added, the data distributed on AB, BC and DA are still valid, and only the data in the CD segment is invalid (the data exists in node A, but the server obtained clockwise is D). This ensures that the cached data will not fail in a large area like the hash algorithm, and also has the effect of reducing the pressure on the database.
Thinking:
Since the hash ring can guarantee that the data will only be partially invalidated when the server node changes, does the consistent hash end?
What is hash skew?
A, B, and C service nodes, it would be ideal if the hash rings are evenly distributed as shown in the above figure, but what will happen if their hash values are very similar?
The situation in the above figure is called hash skew. In this case, most of the data will be distributed in the CA segment. At this time, node A will be deleted, and a large number of requests will flow to node B, which will bring Huge pressure, and at the same time this part of the cache will be completely invalidated, which may cause a cache avalanche.
What should we do?
At this time, we may think of an old saying: There is strength in numbers.
If we have enough nodes, we should be able to prevent the problem of uneven distribution of server nodes.
Therefore, the concept of virtual nodes is introduced. Taking node A as an example, (A0, A1, A2...AN) is constructed virtually. As long as the data falls on these virtual nodes, it will be stored in node A. The same is true when reading. The A0 virtual node is obtained clockwise, and the data is obtained from the A node, which can solve the problem of uneven data distribution. as the picture shows:
2. Redis Cluster hash slot
Redis cluster uses hash slots of data fragmentation for data storage and data reading. The redis cluster has a total of 2^14 (16384) slots, and all master nodes will have a slot area such as 0 to 1000, and the number of slots can be migrated. The slave nodes of the master node do not allocate slots, but only have read permissions. But note that in the code, the redis cluster performs read and write operations on the master node, not the slave node for reading and the master node for writing as you think. When creating a new redis cluster for the first time, 16384 slots are evenly distributed by the master node.
Compared with consistent hashing
, it is not closed. The key positioning rule is to determine which slot area it belongs to based on the value of CRC-16(key)%16384, so as to determine which node the key belongs to. Consistent hashing is Find the node of the first hash (ip) clockwise according to the value of hash (key), so as to determine which node the key is stored in.
Consistent hashing is to create virtual nodes to realize data transfer after node downtime and ensure data security and cluster availability.
Redis cluster adopts the mechanism that the master node has multiple slave nodes to ensure the integrity of the data. The master node writes the data, and the slave node synchronizes the data. When the master node hangs up, the slave node will elect a node to become the master node through the election mechanism to achieve high availability. But here is one thing to consider. If the master node has a hotspot cache, and the access to a certain key increases sharply at a certain moment, the master node may die from overwork, and then after the slave node is elected as the master node, it also goes down. By analogy, causing a cache avalanche
Expansion and shrinkage
You can see that after the consistent hash algorithm adds and deletes nodes, the data will be redistributed to the nodes clockwise. The addition and deletion of nodes in redis cluster requires manual allocation of slots.
Create a new master node
Use the redis-trib.rb tool to create a master node./redis-trib.rb
add-node 172.60.0.7:6379 172.60.0.5:6379
Note:
192.168.10.219:6378 is a new node
192.168.10.219: Any old node in the 6379 cluster
Note: The newly created master node has no slot area, and slots need to be allocated to the master node, otherwise the cache will not be hit. The method of allocating slots is Baidu.
Delete the master node
1). If the master node has slave nodes, you need to transfer the slave nodes to other master nodes.
2). After the transfer, if the master node has a hash slot, transfer the hash slot to another master node, and then delete the master node
Note: The dynamic expansion and shrinkage of the redis cluster will not affect the use of the cluster.
3. Summary
1): Hash slot (slot space) compared with consistent hash (ring space) can achieve more even data distribution. There are
N nodes, and each node is accurately responsible for 1/N capacity
consistent hash. It uses The value returned by the hash function is random.
2): Hash slot is more convenient to add/delete nodes.
Assume that there are already R1, R2, and R3 nodes
. If you add R4 nodes, you only need to move some slots from R1, R2, and R3 to R4
. If you delete R1 nodes, you only need to The slot in R1 is moved to the R2 and R3 nodes, the slot movement between the nodes will not stop the service, and the cluster is always available.
When consistent hashing adds or deletes nodes, it will cause some data to fail to hit, and even cause a cache avalanche in severe cases.