Shulou(Shulou.com)05/31 Report--

This article introduces the knowledge of "what are the functions of Redis cluster". In the operation of actual cases, many people will encounter such a dilemma. Then let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

What is a Redis cluster

Redis Cluster is an advanced version of Redis that is distributed and allows a single point of failure.

Redis cluster does not have the most important or central node, one of the main goals of this version is to design a linear scalable (nodes can be added or deleted at will?) The function of.

Redis cluster may sacrifice part of the function of allowing single point of failure for the sake of data consistency, so when network failure and node failure occur, the system will try its best to ensure data consistency and validity. (here we think that node failure is a special case of network failure)

In order to solve the problem of single point of failure, we need both masters and slaves. Even if the master node (master) and the slave node (slave) are functionally consistent, even if they are deployed on the same server, the slave node is only used to replace the failed master node. In fact, it should be said that if there is no need for the slave node to read-after-write (write and read the data immediately in case the data cannot be obtained during data synchronization), then the slave node only accepts read-only operations.

Implemented subset

The Redis cluster stores all single key in a non-distributed version of Redis. For compound operations such as union and intersection, it is not implemented.

In the future, a new type of node called "Computation Node" may be added. This kind of node is mainly used to handle the read-only operation of multi-key in the cluster, but the read-only operation of multi-key will not be transferred to the Computation Node node in the cluster and then calculated.

The Redis cluster version will no longer support multiple databases like the stand-alone version, there is only database 0 in the cluster version, and the SELECT command is not available.

The agreement between client and server in Redis Cluster Edition

In the Redis cluster version, nodes have a responsibility / obligation to save data and their own state, including mapping data (key) to the correct node. All nodes should automatically detect other nodes in the cluster and change the slave node of the failed node to the master node after the failed node is found (in the original text, "if necessary" may mean that the slave node needs to be set up or exists).

Cluster nodes use TCP bus and binary protocols to interconnect and dispatch tasks. Each node uses the gossip protocol to send ping packets to other nodes in the cluster to determine whether the other nodes are working properly. Cluster bus can also be used to execute PUB/SUB commands between nodes.

When a cluster node is found to be unanswered, the redirections errors-MOVED and-ASK command is used and redirected to the available node. In theory, the client can send a request to any node in the cluster and get the redirection at will, that is to say, the client does not actually care about the state of the cluster. However, the client can also cache the corresponding node of the data, which can eliminate the redirection work of the server, which can improve the efficiency to a certain extent.

What are the functions of Redis cluster

Keys allocation mode

A cluster can contain up to 4096 nodes (but we recommend setting up a few hundred nodes at most).

All master nodes control the percentage of 4096 key spaces. When the cluster is stable, that is, the cluster configuration will not be changed (change the configuration refers to the addition and deletion of nodes), then a node will only serve one hash slot. (but the service node (master) can have multiple slave nodes to prevent a single point of failure)

The algorithm used to calculate which hash slot key belongs to is as follows:

HASH_SLOT = CRC16 (key) mod 4096

Name: XMODEM (also known as ZMODEM or CRC-16/ACORN)

Width: 16 bit

Poly: 1021 (That is actually x ^ 16 + x ^ 12 + x ^ 5 + 1)

Initialization: 0000

Reflect Input byte: False

Reflect Output CRC: False

Xor constant to output CRC: 0000

Output for "123456789": 31C3

Here we will take the 12 bytes after CRC16. In our test, for 4096 slots, the CRC16 algorithm is the most suitable.

Cluster node characteristics

Each node in the cluster has a unique name. A 160 bit random number with the name of the node in hexadecimal, which will be enabled immediately when the node gets the name. The node name is permanently saved to the node settings file unless the system administrator manually deletes the node configuration file.

The node name is the identification of each node in the cluster. It is allowed to modify the node IP and address without changing the node ID. Cluster bus automatically acquires the changed node settings through the gossip protocol.

Each node can learn the information of other nodes, including: IP port, status, managed hash slots, time when cluster bus last sent PING, time last received PONG, number of slave nodes, node ID.

Both master and slave nodes can obtain the above information through the CLUSTER NODES command

Examples are as follows:

$redis-cli cluster nodes

D1861060fe6a534d42d8a19aeb36600e18785e04: 0 myself-0 1318428930 connected 0-1364

3886e65cc906bfd9b1f7e7bde468726a052d1dae 127.0.0.1 connected 6380 master-1318428930 1318428931 connected

D289c575dcbc4bdd2931585fd4339089e461a27d 127.0.0.1 connected 6381 master-1318428931 1318428931

Node interaction

All nodes are always allowed to accept connection requests from the cluster bus and reply even if the node requesting the PING is untrusted. However, all packets from non-clustered nodes is ignored.

There are only two situations in which a node considers other nodes to be part of a cluster:

If a node introduces itself using MEET message. The MEET message command forces other nodes to think of themselves as part of the cluster. Only the system administrator uses the CLUSTER MEET ip port command node to send MEET message to other nodes.

Another way is through the recommendation mechanism between cluster nodes. For example, if Node A knows that Node B belongs to the cluster, and Node B knows that Node C belongs to the cluster, then B will send a gossip message informing Avatar that node C belongs to the cluster. When A gets the gossip information, it tries to connect to C.

This means that when we join a node to the cluster in any way, all nodes in the cluster automatically establish a trusted connection to the new node. In other words, the cluster has the ability to automatically identify all nodes, but this only occurs when the system management forces a trusted connection between the new node and any node in the cluster.

This mechanism makes the cluster system more robust.

When one node fails, the rest of the nodes try to connect to all other known nodes to determine the robustness of the other nodes.

Redirection of moved data

Redis clients are allowed to send commands to any node in the cluster, including slave nodes. The accessed node will analyze the data needed in the command (in this case, only a single key is requested) and determine which node the data is stored on by determining the hash slot.

If the requested node has hash slot data (in this case, the request data has not been migrated or the hash slot has been recalculated after data migration), the result will be returned directly, otherwise an MOVED error will be returned.

The MOVED error is as follows:

GET x

-MOVED 3999 127.0.0.1 purl 6381

This error includes the hash slot (3999) where the requested data is located and the IP: Port to which the data currently belongs. The client needs to access the returned IP: port to obtain data. Even if the cluster configuration has been changed while the client is requesting and waiting for the data to return (that is, the node ID to which the requested key belongs in the configuration file has been redirected to the new IP: port), the target node will still return an MOVED error.

So although the nodes in the cluster use the node ID to determine their identity, the map is still paired by the IP: ports of the hash slot and Redis nodes.

The client is not required but should try to remember that hash slot 3999 has now been transferred to 127.0.0.1 6381. In this way, when a new command needs to get data from hash slot 3999, it has a higher chance of getting the correct target node from hash slot.

Assuming that the cluster is stable enough (without adding or deleting nodes), then all clients will have a copy of the data of the corresponding hash slots node, which can make the whole cluster more efficient, because each command will be directed directly to the correct node, and there is no need to find the node through the node or recalculate the corresponding node of the hash slot.

The cluster does not go offline to update the configuration

The Redis cluster supports adding and deleting nodes online. In fact, adding and deleting nodes are essentially the same for the system, because they both migrate hash slot from one node to another.

Add nodes: add an empty node to the cluster and move the hash slot from the existing nodes to the new node.

Delete nodes: the cluster deletes an existing node and distributes the hash slot among other existing nodes.

So the core of implementing this function is to migrate slots. In fact, from a point of view, hash slot is just a collection of key, so all the Redis cluster has to do is move a pile of key from one instance to another when resharding.

This is the end of the content of "what are the functions of Redis Cluster"? thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.