There are generally two types of Redis distributed solutions
(1) Client partition, the advantage is that the partition logic is controllable, but the disadvantage is that the client needs to handle data routing, high availability, failover, etc.
(2) The proxy scheme has the advantage of simplifying client logic and upgrades, and the disadvantage is that it increases the complexity of the architecture and performance loss.
Redis Cluster is an official distributed solution. It was officially launched from version 3.0. It is different from the above two solutions. It uses virtual slot partitioning and hash partitioning. It does not use consistent hashing (increase or decrease). The node will cause some data to fail to hit, and when a small number of nodes are used, node changes will affect the data mapping), but use the improved consistency hash-virtual slot partition method.
Redis Cluster uses 16384 virtual slots, which are allocated to node management.
Node communication uses the Gossip protocol, and commonly used messages are ping, pong, meet, fail. Each node keeps the full topology and slot information of the cluster (this avoids a single point). So send a request to any node, if the data is in the current node, it will hit, if not, it will return a MOVED IP PORT message, indicating the node information where the data is located, and the client only needs to resend it. That is, crc16(key)->slot_num->node or crc16(key)->slot_num->node returns MOVED information, and the client can redirect to the target node. Question: What if the target node is being expanded or removed? ? ? See analysis below.
Disadvantages of Redis Cluster:
1. There is a problem with batch operations. The mget and mset commands can only support keys with the same slot value (all can use hash_tag to map keys to the same slot)
2. The key transaction support is limited, it cannot cross nodes, and it cannot map large objects to different nodes
3. The replication structure only supports one layer, not the tree structure, that is, the slave node has only one layer
Cluster expansion and node removal
Cluster expansion
(1) Prepare a new node
(2) Join the cluster (just send the meet command to one node, and the Gossip protocol will be propagated to all nodes)
(3) Migration slot and data
3.1 Prepare a slot migration plan, that is, which slot to migrate, the default cluster will try to evenly allocate slots to each node
3.2 Send a command to the target node, and the target node prepares
3.3 Send commands to the source node, and the source node prepares
3.4 The source node cyclically obtains the key in the slot to be migrated
3.5 Migrate data from the source node to the target node in batches (the period is to ensure high availability (guaranteed by the ASK mechanism), how to ensure the following)
3.6 Send a command to all master nodes of the cluster, indicating that the slot has been migrated to the new node
cluster shrink
(1) The offline node is not responsible for the slot or the offline node is a slave node. It only needs to notify other nodes, and the offline node can be offline after the notification is successful.
(2) If the current node has a responsible slot, the same as the machine expansion step (3), migrate the slot responsible for this node out.
Cluster request routing
In order to improve efficiency, Jedis will additionally cache the mapping data from slot to node, so in general, the obtained node is correct. If the mapping between slot and node changes, there will be MOVED information, and the client will go to the node to obtain the slot. Update the local to the latest node information.
MOVED routing
1. crc16(key)->slot slot, if the node is the current node, process it, if the node is not the current node, return the MOVED information
2. The client resends the request to the node pointed to by MOVED
ASK redirect
1. crc16(key)->slot The slot finally enters the target node. If the slot is migrating and the object is not there, the ASK information is returned
2. The client sends a request to the node of the ASK information
So even in the slot migration process, the cluster can still guarantee high availability.