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

This document is translated from http://redis.io/topics/cluster-spec.

Introduction

This document is a specification (specification) document for Redis clustering functionality under development, and is divided into two parts:

The first part introduces the functions that have been implemented in the unstable branch so far.

The second part introduces those functions that have not been implemented yet.

The content of each part of the document may change with the design modification of the cluster function, in which the probability of modification of the unimplemented function is higher than that of the implemented function.

This specification contains all the knowledge needed to write a client library (client library), but please note that some of the details listed here may change in the future.

What is a Redis cluster?

Redis cluster is a distributed (distributed), fault-tolerant (fault-tolerant) Redis implementation, and the functions that can be used by clusters are a subset of the functions that can be used by ordinary stand-alone Redis (subset).

There are no central nodes or proxy nodes in the Redis cluster, and one of the main design goals of the cluster is to achieve linear scalability (linear scalability).

Redis cluster sacrifices part of fault tolerance in order to ensure consistency (consistency): the system will maintain data consistency as much as possible on the premise of limited (limited) resistance to network disconnection (net split) and node failure (node failure).

The cluster regards node failure as one of the special cases of network disconnection.

The fault tolerance of the cluster is achieved by using the node (node) of two roles (master node (master) and slave node (slave)):

The master node and the slave node are implemented using exactly the same server and their functions (functionally) are exactly the same, but the slave node is usually only used to replace the failed master node.

However, if you do not need to guarantee the consistency (read-after-write consistency) of the write-then-read operation, you can use the slave node to perform a read-only query.

Functional subset of Redis cluster implementation

The Redis cluster implements all commands that deal with a single database key in a stand-alone Redis.

The complex computing operations for multiple database keys, such as set union operation and collection operation, are not implemented, and those commands that theoretically need to use multiple database keys of multiple nodes are not implemented.

In the future, users may be able to perform read-only operations on multiple database keys in the compute node (computation node) of the cluster through the MIGRATE COPY command, but the cluster itself will not implement complex multi-key commands that need to move multiple database keys to and from multiple nodes.

Redis clusters do not support multiple databases like stand-alone Redis. Clusters only use the default database number 0 and cannot use the SELECT command.

Clients and servers in Redis Cluster Protocol

Nodes in a Redis cluster have the following responsibilities:

Hold key-value pairs of data.

Record the status of the cluster, including the mapping of keys to the correct node (mapping keys to right nodes).

Automatically discover other nodes, identify abnormal nodes, and select a new master node from the slave nodes if necessary.

To perform the tasks listed above, each node in the cluster establishes a "cluster connection" (cluster bus) with other nodes, which is an TCP connection that communicates using the binary protocol.

The Gossip protocol is used between nodes to do the following:

Propagate information about the cluster to discover new nodes.

Send PING packets to other nodes to check whether the target node is functioning properly.

Send cluster information when a specific event occurs.

In addition, cluster connections are also used to publish or subscribe information in the cluster.

Because cluster nodes cannot proxy command requests, clients should forward command requests to other nodes themselves when the node returns a-MOVED or-ASK redirection (redirection) error.

Because the client is free to send command requests to any node in the cluster, and can forward the command to the correct node based on the information provided by the redirection error when necessary, in theory, the client does not need to save the cluster state information.

However, if the client can save the mapping information between keys and nodes, it can effectively reduce the number of redirections that may occur, thus improving the efficiency of command execution.

Bond distribution model

The key space of the Redis cluster is divided into 16384 slot, and the maximum number of nodes in the cluster is 16384.

The recommended maximum number of nodes is about 1000.

Each master node is responsible for handling some of the 16384 hash slots.

When we say that a cluster is in a "stable" state, it means that the cluster is not performing a reconfiguration operation, and each hash slot is handled by only one node.

Reconfiguration refers to moving one / some slots from one node to another.

A master node can have any number of slave nodes, which are used to replace the master node when the master node is disconnected or the node fails.

The following is the algorithm responsible for mapping keys to slots:

HASH_SLOT = CRC16 (key) mod 16384

The following are the parameters used by the algorithm:

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

Length of the result: 16 bits

Number of polynomials (poly): 1021 (that is, x16 + x12 + x5 + 1)

Initialization value: 0000

Reflected input bytes (Reflect Input byte): False

Transmit output CRC (Reflect Output CRC): False

XOR constant for CRC output value (Xor constant to output CRC): 0000

The algorithm for the input "123456789" output: 31C3

The implementation of the CRC16 algorithm used by the cluster is given in Appendix A.

Fourteen bits of the 16-bit output generated by the CRC16 algorithm are used.

In our tests, the CRC16 algorithm can smoothly distribute different types of keys to 16384 slots.

Cluster Node attribute

Each node has a unique ID in the cluster, which is a hexadecimal representation of a 160-bit random number generated by / dev/urandom when the node is first started.

The node saves its ID to the configuration file, and the node will continue to use the ID as long as the configuration file is not deleted.

The node ID is used to identify each node in the cluster. A node can change its IP and port number without changing the node ID. The cluster can automatically recognize the change in the IP/ port number and broadcast this information to other nodes through the Gossip protocol.

The following is the associated information that each node has, and the node sends this information to other nodes:

The IP address and TCP port number used by the node.

The flag of the node (flags).

The node is responsible for handling the hash slot.

The last time a node sent a PING packet (packet) using a cluster connection.

The last time the node received an PONG packet in the reply.

The time the cluster marks the node as offline.

The number of slave nodes for this node.

If the node is a slave node, it records the node ID of the master node. If this is a master node, the ID column of the master node has a value of 0000000.

Some of the above information can be obtained by sending CLUSTER NODES commands to any node in the cluster (master or slave).

The following is an example of sending a CLUSTER NODES command to a master node in a cluster consisting of three nodes:

$redis-cli cluster nodesd1861060fe6a534d42d8a19aeb36600e18785e04: 0 myself-0 1318428930 connected 0-13643886e65cc906bfd9b1f7e7bde468726a052d1dae 127.0.0.1 connected 6380 master-1318428930 1318428931 connected 1365-2729d289c575dcbc4bdd2931585fd4339089e461a27d 127.0.1 connected 6381 master-1318428931 1318428931 connected 27304095

In the three lines of information listed above, the fields from left to right are: node ID, IP address and port number, flag (flag), the last time the PING was sent, the last time the PONG was received, the connection status, and the slot handled by the node.

Node handshake (implemented)

The node always accept the connection request from the cluster connection port and replies to the received PING packet, even if the PING packet comes from an untrusted node.

However, with the exception of PING, the node rejects all other packets that are not from the cluster node.

There are only two ways to get one node to admit that another node belongs to the same cluster:

One node can force the receiving node to admit that the sending node is a member of the cluster by sending MEET information to another node. One node sends CLUSTER MEET ip port information to another node only if the administrator explicitly sends it a MEET command.

In addition, if a trusted node propagates the information of a third-party node to another node, the node that receives the information will also identify the third-party node as a member of the cluster. That is, if A knows B, B knows C, and B propagates information about C to A, then A will also identify C as a member of the cluster and try to connect to C.

This means that if we add one / some new nodes to a cluster, the new nodes will eventually be connected to all other nodes already in the cluster.

This means that as long as the administrator explicitly specifies the trust relationship using the CLUSTER MEET command, the cluster can automatically discover other nodes.

This node identification mechanism makes the cluster more robust by preventing different Redis clusters from mix due to IP address changes or other network events.

When a node is disconnected from the network, it will actively connect to other known nodes.

MOVED steering

An Redis client can send command requests to any node in the cluster, including slave nodes. The node analyzes the command request, and if the command is a command that can be executed by the cluster, the node looks for the slot in which the key to be processed by the command is located.

If the hash slot you are looking for happens to be handled by the node that received the command, then the node executes the command directly.

On the other hand, if the slot being found is not handled by the node, the node will view the mapping record of the hash slot to the node ID saved within the node and report to the customer

The client replied with a MOVED error.

The following is an example of an MOVED error:

GET x-MOVED 3999 127.0.0.1:6381

The error message includes the hash slot 3999 to which the key x belongs, as well as 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.

Note that even if the client waits so long before resending the GET command that the cluster changes the configuration again so that node 127.0.0.1 MOVED 6381 no longer processes slot 3999, then when the client sends the GET command to node 127.0.0.1, the node will return a MOVED error to the client indicating that the node is now responsible for processing slot 3999.

Although we use ID to identify the nodes in the cluster, in order to make the client's redirection operation as simple as possible, the node directly returns the IP and port number of the target node in the MOVED error, rather than the ID of the target node.

Although not necessary, a client should record (memorize) the message that "slot 3999 is handled by node 127.0.0.1 6381", so that when another command needs to be executed on slot 3999, the client can speed up finding the right node.

Note that when the cluster is in a stable state, all clients eventually keep a hash slot-to-node mapping record (map of hash slots to nodes), making the cluster very efficient: the client can send command requests directly to the correct node without having to redirect, agent, or any other entity (entiy) that may have a single point of failure (single point failure).

In addition to MOVED redirection errors, a client should be able to handle ASK redirection errors described later.

Cluster online reconfiguration (live reconfiguration)

Redis clusters support adding or removing nodes while the cluster is running.

In fact, the add operation of the node and the delete operation of the node can be abstracted into the same operation, that is, move the hash slot from one node to another:

Adding a new node to the cluster is equivalent to moving the slots of other existing nodes into a blank new node.

Removing a node from the cluster is equivalent to moving all the slots of the removed node to other nodes in the cluster.

Therefore, the core of implementing online reconfiguration of Redis clusters is the ability to move slots from one node to another. Because a hash slot is actually a collection of keys, what a Redis cluster really needs to do when it rehash is to move some keys from one node to another.

To understand how a Redis cluster moves slots from one node to another, we need to introduce the subcommands of the CLUSTER command, which are responsible for managing the slot translation table (slots translation table) of the cluster nodes.

The following subcommands are available for the CLUSTER command:

CLUSTER ADDSLOTS slot1 [slot2]... [slotN] CLUSTER DELSLOTS slot1 [slot2]... [slotN] CLUSTER SETSLOT slot NODE nodeCLUSTER SETSLOT slot MIGRATING nodeCLUSTER SETSLOT slot IMPORTING node

The first two commands ADDSLOTS and DELSLOTS are used to assign (assign) or remove nodes to nodes, respectively, and when slots are assigned or removed, nodes propagate this information to the entire cluster through the Gossip protocol. The ADDSLOTS command is usually used as a means of quickly assigning individual slots to individual nodes when a new cluster is created.

The CLUSTER SETSLOT slot NODE node subcommand assigns the specified slot slot to the node node.

As for the CLUSTER SETSLOT slot MIGRATING node command and the CLUSTER SETSLOT slot IMPORTING node command, the former is used to migrate the slot slot in the given node node out of the node, while the latter is used to import the given slot slot into the node node:

When a slot is set to MIGRATING, the node that used to hold the slot will continue to accept command requests for the slot, but the node will process the command request only if the key handled by the command still exists in the node.

If the key used by the command does not exist with the node, the node returns a-ASK redirection (redirection) error to the client, telling the client to send the command request to the migration target node of the slot.

When a slot is set to the IMPORTING state, the node accepts the command request for the slot only after it has received the ASKING command.

If the client does not send an ASKING command to the node, the node uses the-MOVED redirection error to redirect the command request to the node that is really responsible for handling the slot.

The above instructions about MIGRATING and IMPORTING are a little difficult to understand, so let's use a practical example to illustrate it.

Suppose now that we have two nodes An and B, and we want to move slot 8 from node A to node B, so we:

Send the command CLUSTER SETSLOT 8 IMPORTING A to Node B

Send the command CLUSTER SETSLOT 8 MIGRATING B to node A

Whenever the client sends a command request about hash slot 8 to other nodes, these nodes return redirection information to node A to the client:

If the key to be processed by the command already exists in slot 8, the command will be handled by node A.

If the key to be processed by the command does not exist in slot 8 (for example, to add a new key to the slot), the command is handled by node B.

This mechanism will cause node A to no longer create any new keys for slot 8.

At the same time, a special client redis-trib and the Redis cluster configuration program (configuration utility) move the keys in slot 8 in node A to node B.

The move operation of the key is performed by the following two commands:

CLUSTER GETKEYSINSLOT slot count

The above command causes the node to return keys in count slot slots, and for each key returned by the command, redis-trib sends a MIGRATE command to node A, which atomic the specified key from node A to node B. during the move key, both nodes are blocked to avoid contention conditions.

The following is how the MIGRATE command works:

MIGRATE target_host target_port key target_database id timeout

The node that executes the MIGRATE command connects to the target node and sends the serialized key data to target, and once the target returns OK, the node deletes its own key from the database.

From the perspective of an external client, at some point in time, the key key exists either on node An or on node B, but not on both node An and node B.

Because the Redis cluster only uses database 0, when the MIGRATE command is used to perform cluster operations, the value of target_database is always 0.

The target_database parameter exists to make the MIGRATE command a generic command that can act on other functions outside the cluster.

We have optimized the MIGRATE command to remain efficient even when transferring complex data such as list keys containing multiple elements.

However, although MIGRATE is very efficient, for a cluster with a large number of keys and a very large amount of key data, cluster reconfiguration can take a lot of time and may cause the cluster to be unable to adapt to applications that have strict response time requirements.

ASK steering

In the previous introduction to MOVED steering, we said that in addition to MOVED steering, there is another ASK steering.

When a node needs a client to permanently a command request for one slot to another node, the node returns a MOVED redirection to the client.

On the other hand, when the node needs to redirect the client to another node only in the next command request, the node returns the ASK redirection to the client.

For example, in the example of slot 8 listed in the previous section, because the keys contained in slot 8 are scattered in node An and node B, when the client does not find a key in node A, it should turn to node B. but this shift should affect only one command query Instead of letting the client find node B directly every time: before all the keys belonging to slot 8 held by node An are migrated to node B, the client should access node A before accessing node B.

Because this shift is targeted at only one of the 16384 slots, the performance loss caused by the shift to the cluster is acceptable.

For the above reasons, if we want to continue looking for node B after finding node A, then the client should send an ASKING command before sending a command request to node B, otherwise the command request for the slot with IMPORTING status will be rejected by node B.

The node that receives the client ASKING command sets an one-time flag (flag) for the client so that the client can execute a command request for the slot in the IMPORTING state.

From the client's point of view, the full semantics (semantics) of the ASK turn is as follows:

If the client receives an ASK redirection, the sending object of the command request is adjusted to the specified node.

Send an ASKING command before sending a real command request.

There is no need to update the slot 8-to-node mapping recorded by the client: slot 8 should still be mapped to node A, not node B.

Once the migration of Node A for slot 8 is completed, when Node A receives the command request for slot 8 again, it returns the MOVED turn to the client and forwards the command request for slot 8 to Node B for a long time.

Note that even if the client has Bug and maps slot 8 to node B prematurely, as long as the client does not send an ASKING command, the client will encounter a MOVED error when sending a command request and turn it back to node A.

Fault tolerance

Node failure detection

The following is the implementation of node failure detection:

When one node sends a PING command to another node, but the target node fails to return a reply to the PING command within a given time limit, the node that sent the command marks the target node as PFAIL (possible failure, which may be invalid).

The time limit for waiting for a reply from the PING command is called the Node timeout period (node timeout), which is a node option (node-wise setting).

Every time a node sends a PING command to another node, it randomly broadcasts the information of three nodes it knows, one of which is whether the node has been marked as PFAIL or FAIL.

When a node receives information from other nodes, it records those nodes that are marked as invalid by other nodes. This is called a failure report (failure report).

If a node has marked a node as PFAIL, and according to the failure report received by the node, most other master nodes in the cluster also think that the node has entered the failure state, then the node will mark the status of that failed node as FAIL.

Once a node is marked as FAIL, information about the failure of that node is broadcast to the entire cluster, and all nodes that receive this information mark the failed node as FAIL.

To put it simply, if a node wants to mark another node as invalid, it must first consult other nodes and get the consent of most of the master nodes.

Because expired failure reports are removed, the primary node must be based on the recently received failure report if it wants to mark a node as FAIL.

The FAIL state of a node is removed in the following two cases:

If the FAIL is marked as a slave node, the FAIL tag will be removed when that node comes back online.

It is meaningless to retaning the FAIL state of the slave node because it does not handle any slots. Whether a slave node is in the FAIL state or not determines whether the slave node can be promoted to the master node if necessary.

If a master node has been marked with FAIL, four times the node timeout time has elapsed, and ten seconds later, the failover operation for the slot of the master node has not been completed, and the master node has been re-online, then remove the FAIL tag for that node.

In the second case, if the failover does not complete successfully and the primary node comes back online, the cluster continues to use the original primary node, eliminating the need for administrator intervention.

Cluster status detection (partially implemented)

Whenever a configuration change occurs in the cluster (either a hash slot update or a node goes into a failed state), each node in the cluster scans (scan) the nodes it knows.

Once the configuration is completed, the cluster enters one of the following two states:

FAIL: the cluster is not working properly. When a node in the cluster enters a failure state, the cluster cannot process any command requests, and the cluster node returns an error reply for each command request.

OK: the cluster works properly, and none of the nodes responsible for handling all 16384 slots is marked as FAIL.

This means that even if only part of the hash slot in the cluster does not work properly, the entire cluster will stop processing any commands.

However, the cluster will still function normally between the time when the node has a problem and the time it is marked as FAIL, so it is still possible that the cluster can only handle command requests for a subset of 16384 slots at some point.

Here are two situations in which a cluster enters the FAIL state:

At least one hash slot is not available because the node responsible for processing the slot has entered the FAIL state.

Most of the primary nodes in the cluster are offline. When most of the master nodes enter the PFAIL state, the cluster also enters the FAIL state.

The second check is necessary, because to change a node from the PFAIL state to the FAIL state, most of the primary nodes must vote, but when most of the primary nodes in the cluster are in the failed state, there is no way to mark a node as FAIL state with only one or two nodes.

Therefore, with the second check condition, as long as most of the master nodes in the cluster go offline, the cluster can judge a node as FAIL without requesting the views of these master nodes, thus causing the entire cluster to stop processing command requests.

Election from node

Once a master node enters the FAIL state, if the master node has one or more slave nodes, one of the slave nodes will be upgraded to the new master node, while the other slave nodes will begin to copy the new master node.

The new master node is elected by all the slave nodes under the offline master node. The following are the election conditions:

This node is the slave node of the offline master node.

The number of slots handled by the offline master node is not empty.

The data of the slave node is considered to be reliable, that is, the disconnection time of the replication connection (replication link) between the master and slave nodes cannot exceed the product of the node timeout period (node timeout) multiplied by the REDIS_CLUSTER_SLAVE_VALIDITY_MULT constant.

If a slave node meets all the above conditions, the slave node will send an authorization request to the other master nodes in the cluster, asking them if they are allowed to upgrade to the new master node.

If the slave node that sent the authorization request satisfies the following attributes, the master node will return FAILOVER_AUTH_GRANTED authorization to the slave node, agreeing to the slave node's

Upgrade requirements:

The authorization request is sent by a slave node, and the master node to which it belongs is in the FAIL state.

Of all the slave nodes of the offline master node, the node ID of this slave node is the smallest in sorting.

This slave node is in a normal running state: it is not marked as FAIL, nor is it marked as PFAIL.

Once a slave node is authorized by most of the master nodes within a given time limit, it begins to perform the following failover operations:

Tell the other nodes through the PONG packet (packet) that this node is now the master.

Tell other nodes through the PONG packet that this node is an upgraded slave node (promoted slave).

Claiming all hash slots handled by the offline master node.

Explicitly broadcasts a PONG packet to all nodes, accelerating the progress of other nodes in identifying this node instead of waiting for a timed PING / PONG packet.

All other nodes update the configuration accordingly according to the new primary node, especially:

All slots taken over by the new master node will be updated.

All slaves of the offline master node will notice the PROMOTED flag and begin to copy the new master node.

If the offline master node comes back online, it will detect the PROMOTED flag and adjust itself to the slave node of the current master node.

During the life cycle of the cluster, if a master node with the PROMOTED identity becomes a slave node for some reason, then the node will lose its PROMOTED identity.

Publish / subscribe (implemented, but still needs improvement)

In a Redis cluster, the client can subscribe to any node or send information to any node, and the node will forward the information sent by the client.

In the current implementation, the node broadcasts the received information to all other nodes in the cluster, and in future implementations, bloom filter or other algorithms may be used to optimize this operation.

Appendix A: reference for ANSI implementation of CRC16 algorithm

/ * Copyright 2001-2010 Georges Menie (www.menie.org) * Copyright 2010 Salvatore Sanfilippo (adapted to Redis coding style) * All rights reserved. * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions are met: * * Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * Neither the name of the University of California, Berkeley nor the * names of its contributors may be used to endorse or promote products * derived from this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND ANY * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE REGENTS AND CONTRIBUTORS BE LIABLE FOR ANY * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * / * CRC16 implementation acording to CCITT standards * * Note by @ antirez: this is actually the XMODEM CRC 16 algorithm, using the * following parameters: * * Name: "XMODEM", also known as "ZMODEM" "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 * / static const uint16_t crc16tab [123456789] = {0x0000 0x1021, 0x2042, 0x3063, 0x4084, 0x50a5, 0x60c6, 0x70e7, 0x8108, 0x9129xa14a, 0xb16b, 0xc18cdirection 0xd1ad0xe1cece.0xf1ef, 0x1231, 0x0210, 0x3273, 0x22522x5b5x5x4294, 7x2f07f02x6d6, 0933, 90x6x8x0b37bxa035dd03xc0xc0xc0x3xe0x3xe0x3xc0x3xc0x3xc0x3xc0x3x3xc0x3xc0x3xc0x3x3x3x3x3x3x3xc0x3xc0x3xc0x3xc0x3xc0x3xc0x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x3x6x3x3x3x3x3x3x3x3F0x3x3F0x3x3F0x3x3 0xa56a,0xb54b,0x8528,0x9509,0xe5ee,0xf5cf,0xc5ac,0xd58d, 0x3653,0x2672,0x1611,0x0630,0x76d7,0x66f6,0x5695,0x46b4, 0xb75b,0xa77a,0x9719,0x8738,0xf7df,0xe7fe,0xd79d,0xc7bc, 0x48c4,0x58e5,0x6886,0x78a7,0x0840,0x1861,0x2802,0x3823, 0xc9cc,0xd9ed,0xe98e,0xf9af,0x8948,0x9969,0xa90a,0xb92b, 0x5af5,0x4ad4,0x7ab7,0x6a96,0x1a71,0x0a50,0x3a33,0x2a12, 0xdbfd,0xcbdc,0xfbbf,0xeb9e,0x9b79,0x8b58,0xbb3b,0xab1a, 0x6ca6,0x7c87,0x4ce4,0x5cc5,0x2c22,0x3c03,0x0c60,0x1c41, 0xedae,0xfd8f,0xcdec,0xddcd,0xad2a,0xbd0b,0x8d68,0x9d49, 0x7e97,0x6eb6,0x5ed5,0x4ef4,0x3e13,0x2e32,0x1e51,0x0e70, 0xff9f,0xefbe,0xdfdd,0xcffc,0xbf1b,0xaf3a,0x9f59,0x8f78, 0x9188,0x81a9,0xb1ca,0xa1eb,0xd10c,0xc12d,0xf14e,0xe16f, 0x1080,0x00a1,0x30c2,0x20e3,0x5004,0x4025,0x7046,0x6067, 0x83b9,0x9398,0xa3fb,0xb3da,0xc33d,0xd31c,0xe37f,0xf35e, 0x02b1,0x1290,0x22f3,0x32d2,0x4235,0x5214,0x6277,0x7256, 0xb5ea 0xa5cb,0x95a8,0x8589,0xf56e,0xe54f,0xd52c,0xc50d, 0x34e2,0x24c3,0x14a0,0x0481,0x7466,0x6447,0x5424,0x4405, 0xa7db,0xb7fa,0x8799,0x97b8,0xe75f,0xf77e,0xc71d,0xd73c, 0x26d3,0x36f2,0x0691,0x16b0,0x6657,0x7676,0x4615,0x5634, 0xd94c,0xc96d,0xf90e,0xe92f,0x99c8,0x89e9,0xb98a,0xa9ab, 0x5844,0x4865,0x7806,0x6827,0x18c0,0x08e1,0x3882,0x28a3, 0xcb7d,0xdb5c,0xeb3f,0xfb1e,0x8bf9,0x9bd8,0xabbb,0xbb9a, 0x4a75,0x5a54,0x6a37,0x7a16,0x0af1,0x1ad0,0x2ab3,0x3a92, 0xfd2e,0xed0f,0xdd6c,0xcd4d,0xbdaa,0xad8b,0x9de8,0x8dc9, 0x7c26,0x6c07,0x5c64,0x4c45,0x3ca2,0x2c83,0x1ce0,0x0cc1, 0xef1f,0xff3e,0xcf5d,0xdf7c,0xaf9b,0xbfba,0x8fd9,0x9ff8, 0x6e17,0x7e36,0x4e55,0x5e74,0x2e93,0x3eb2,0x0ed1,0x1ef0} Uint16_t crc16 (const char * buf, int len) {int counter; uint16_t crc = 0; for (counter = 0; counter < len; counter++) crc = (crc8) ^ * buf++) & 0x00FF]; return crc;}

Summary

The above is the whole content of the detailed explanation of redis cluster specification in this article. I hope it will be helpful to you. Interested friends can refer to: detailed analysis of Redis cluster failure, Redis source code analysis: cluster manual failover, detailed explanation of migration from nodes, brief description of the difference between Redis and MySQL, etc. If there are any deficiencies, please leave a message and carefully correct it. Thank you for your support to the website!

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.