Shulou(Shulou.com)06/01 Report--

What the editor wants to share with you this time is what is the slicing mechanism of Redis Cluster cluster data. The article is rich in content, and interested friends can learn about it. I hope you can get something after reading this article.

Redis Cluster data slicing mechanism

Brief introduction of Redis Cluster

Redis Cluster is a distributed solution of Redis, which is officially launched in version 3.0, which effectively solves the needs of Redis distribution.

Redis Cluster is generally composed of multiple nodes, and the number of nodes is at least 6 in order to form a complete and highly available cluster, of which three are master nodes and three are slave nodes. The three master nodes allocate slots to handle command requests from the client, while the slave node can be used to replace the master node after a failure of the master node.

As shown in the figure above, the cluster consists of 6 Redis nodes, 3 masters and 3 slaves, which are respectively M1 Magi, M2, M3, S1, S2, S3. In addition to data replication between master and slave Redis nodes, all Redis nodes communicate with each other using Gossip protocol to exchange and maintain node metadata information.

In general, the master Redis node handles the read and write operations of the Clients, while the slave node handles only read operations.

Data slicing strategy

The most important point in distributed data storage scheme is data slicing, which is called Sharding.

In order to make the cluster scale horizontally, the first problem to be solved is how to allocate the whole data set to multiple nodes according to certain rules. The commonly used data slicing methods are: range slicing, hash slicing, consistent hash algorithm and virtual hash slot.

Range slicing assumes that the dataset is ordered, and putting the adjacent data together can well support traversal operations. The disadvantage of range slicing is that there are hot spots in the face of sequential writing. For example, for log type writes, the order of logs is generally related to time, and time is monotonously increasing, so the hot spot of writing is always in the last shard.

For relational databases, because table scans or index scans are often needed, range sharding strategies are basically used.

Redis Cluster uses virtual hash slot partition, and all keys are mapped to 0 ~ 16383 integer slots according to the hash function. The formula is: slot = CRC16 (key) & 16383. Each node is responsible for maintaining part of the slot and the key value data mapped by the slot.

Characteristics of Redis virtual slot partition:

Decoupling the relationship between data and nodes simplifies the difficulty of node expansion and contraction. Nodes maintain the mapping relationship of slots themselves, and do not need client or agent services to maintain slot partition metadata to support mapping queries among nodes, slots and keys, which are used in scenarios such as data routing and online cluster scaling.

Redis cluster provides a flexible scheme for node expansion and contraction. Without affecting the external service of the cluster, you can add nodes to the cluster for expansion or downsize some of the offline nodes. It can be said that slots are the basic unit of Redis cluster management data, and cluster scaling is the movement of slots and data between nodes.

Let's first take a look at the principle of Redis cluster scaling. Then learn how to ensure cluster availability during data migration or failure recovery of Redis nodes.

Expand cluster capacity

In order to make readers better understand the expansion operation of online nodes, we use the command of Redis Cluster to simulate the whole process.

When a new Redis node runs and joins the existing cluster, we need to migrate slots and data for it. First of all, the migration plan of slots should be specified for the new nodes to ensure that each node is responsible for a similar number of slots after migration, so as to ensure that the data of these nodes is uniform.

1) start a Redis node first, marked M4.

2) use the cluster meet command to add the new Redis node to the cluster. At the beginning, the new node is in the state of the master node, and since there is no responsible > slot, it cannot accept any read and write operations. Later, we will migrate the slot and fill it with data.

3) send the cluster setslot {slot} importing {sourceNodeId} command to the M4 node to prepare the data of the import slot.

4) send the cluster setslot {slot} migrating {targetNodeId} command to the source node, that is, M1 Magi M2 and M3 node, and let the source node > point prepare the data of the migration slot.

5) the source node executes the command cluster getkeysinslot {slot} {count} to obtain count keys belonging to slot {slot}, and then perform the operation > 6 to migrate the key value data.

6) execute migrate {targetNodeIp} "0 {timeout} keys {key... on the source node } command to batch migrate the acquired keys to the target node through the pipeline mechanism. The batch migration version of the migrate command is provided in Redis version 3.0.6 and above.

7) repeat steps 5 and 6 until all the key data under the slot is migrated to the target node.

8) send the cluster setslot {slot} node {targetNodeId} command to all master nodes in the cluster, informing that the slot is assigned to the target node. In order to ensure that slot node mapping changes propagate in time, it is necessary to traverse and send to all master nodes to update the migrated slots to execute the new node.

Shrink cluster

To shrink a node is to take the Redis node offline, and the whole process requires the following operation flow.

1) first of all, you need to confirm whether the offline node has a responsible slot. If so, you need to migrate the slot to other nodes to ensure the integrity of the mapping of the entire cluster slot node after the node is offline.

2) when the offline node is no longer responsible for the slot or is a slave node, it can notify other nodes in the cluster to forget the offline node, and when all nodes forget to change the node, they can shut down normally.

Offline nodes need to migrate their own slots to other nodes, which is consistent with the previous process of node capacity expansion.

After the migration slot is completed, all nodes in the cluster need to be notified that they have forgotten to go offline, that is, other nodes will no longer exchange Gossip messages with the nodes to be offline.

The Redis cluster uses the cluster forget {downNodeId} command to add the specified node to the disabled list, and the nodes in the disabled list no longer send Gossip messages.

Client routing

In cluster mode, when a Redis node receives any key-related commands, it first calculates the slot corresponding to the key, finds the corresponding node according to the slot, and processes the key command if the node is itself; otherwise, it replies to the MOVED redirection error and informs the client to request the correct node. This process is called MOVED redirection.

It should be noted that Redis does not simply calculate the content of the key value when calculating the slot. When the content of the key value includes curly braces, it only calculates the contents in parentheses. For example, when key is user: {10000}: books, the hash is calculated only 10000.

The MOVED error example shows the following information, the hash slot 3999 to which the key x belongs, and the IP and port number 127.0.0.1 6381 of the node responsible for processing the slot. The client needs to resend the GET command request to the node it belongs to based on this IP and port number.

Because request redirection increases IO overhead, this is not an efficient way to use Redis clusters, but rather to use Smart cluster clients. By maintaining the mapping relationship between slot and Redis nodes internally, the Smart client can realize the key-to-node lookup locally, thus ensuring the maximum efficiency of IO, while MOVED redirection is responsible for assisting the client to update the mapping relationship.

The Redis cluster supports online migration slots (slot) and data to complete horizontal scaling. When the data corresponding to slot is migrated from the source node to the destination node, the client needs to migrate intelligently to ensure that key commands can be executed normally. For example, when slot data is migrated from the source node to the target node, part of the data may be on the source node and the other part on the target node.

Therefore, to sum up the above, the client command execution process is as follows:

The client sends a command to the source node according to the local slot cache, and if there is a key correspondence, it executes directly and returns the result to the client. If the node returns a MOVED error, update the local slot to Redis node mapping, and then re-initiate the request. If the data is being migrated, the node will reply with an ASK redirection exception. The format is: (error) ASK {slot} {targetIP}: {targetPort}

The client extracts the information of the target node from the ASK redirection exception, sends the asking command to the target node to open the client connection ID, and then executes the key command.

Although both ASK and MOVED control the redirection of the client, they are essentially different. ASK redirection indicates that the cluster is undergoing slot data migration, and the client cannot know when the migration will be completed, so it can only be a temporary redirection. The client will not update the mapping cache from slot to Redis nodes. However, the slot corresponding to the MOVED redirection key has been explicitly specified to the new node, so the slot-to-Redis node mapping cache needs to be updated.

Fail-over

When a small number of nodes in the Redis cluster fail, the cluster can provide services normally through automatic failover.

When a Redis node goes offline objectively, the Redis cluster will choose one of its slave nodes to replace it, so as to ensure the high availability of the cluster. This piece of content is not the core content of this article, interested students can learn by themselves.

However, there is one thing to pay attention to. By default, the entire cluster is unavailable when any of the 16384 slots in the cluster is not assigned to a node. Execute any key command to return to the CLUSTERDOWN Hash slot not served command. When the master node holding the slot goes offline, the entire cluster is unavailable during the period from fault discovery to automatic transfer, which is unbearable for most businesses. Therefore, it is recommended to configure the parameter cluster-require-full-coverage to no. When the master node fails, it will only affect the execution of the relevant commands responsible for the slot, and will not affect the availability of other master nodes.

After reading this article on what is the slicing mechanism of Redis Cluster cluster data, if you think the content of the article is good, you can share it with more people.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.