[Redis] 3. Redis cluster deployment and redis cluster deployment

[Redis] 3. Redis cluster deployment and redis cluster deployment

A Redis cluster is an assembly that provides data sharing among multiple Redis nodes.
Redis clusters do not support the processing of multiple keys commands, because this requires moving data between different nodes, so as to achieve performance like Redis, unexpected errors may occur under high loads.
Redis clusters provide a certain degree of availability through partitioning. In the actual environment, when a node is down or not reachable, continue to process commands.

A Redis cluster is a distributed (distributed), fault-tolerant (fault-tolerant) Redis implementation. A cluster can use a subset (subset) of all functions available for a Single-host Redis instance ).

The Redis cluster does not have a central or proxy node. One of the main design goals of the cluster is to achieve linear scalability ).

Redis clusters sacrifice part of their fault tolerance to ensure consistency: the system will be limited to network disconnection (net split) and node failure (node failure) keep Data Consistency whenever possible.

Advantages of Redis clusters:

Data is automatically split to different nodes.
You can continue to process commands when some nodes in the cluster fail or are not reachable.
Data sharding of Redis Cluster
Redis cluster does not use consistent hash, but introduces the concept of hash slots.
The Redis cluster has 16384 hash slots. After each key is verified by CRC16, the modulo of 16384 is used to determine which slot to place. each node in the cluster is responsible for part of the hash slot. For example, if the current cluster has three nodes:
Node A contains hash slots ranging from 0 to 5500.
Node B contains hash slots ranging from 5501 to 11000.
Node C contains hash slots ranging from 11001 to 16384.
This structure is easy to add or delete nodes. for example, if I want to add A new node D, I need to obtain some slots from node A, B, and C to node D. if I want to remove node A, I need to move the slots in node A to Node B and node C, and then remove node A without any slots from the cluster. since the migration of a hash slot from one node to another does not stop the service, no matter whether you add or delete or change the number of hash slots for a node, the cluster will not be unavailable.

To make the cluster still available when some nodes fail or most of the nodes cannot communicate, the cluster uses a master-slave replication model where each node has a N-1 replica.
In our example, A cluster with three nodes, A, B, and C, if Node B fails, the entire cluster is unavailable because the range 5501-11000 is missing.
However, if we add a slave node A1, B1, C1, the entire cluster is composed of three master nodes and three slave nodes. After Node B fails, the cluster will elect B1 as the new master node to continue service, the entire cluster will not be unavailable because the slot cannot be found.
However, when both B and B1 fail, the cluster is unavailable.
Redis consistency guarantee
Redis does not guarantee strong data consistency. This means that in practice, the cluster may lose write operations under certain conditions.
The first reason is that the cluster uses asynchronous replication and write operations:
The client writes a command to master node B.
Master Node B replies the command status to the client.
The master node copies the write operation to the slave node B1, B2, and B3.
The master node replicates commands after a command response is returned, because if you need to wait for the copy operation to complete every time you process the command request, the speed at which the master node processes command requests will be greatly reduced-we must make a trade-off between performance and consistency. Note: Redis clusters may provide synchronous write methods in the future. Another possible cause of Redis cluster command loss is that the cluster has a network partition, and a client is isolated from a few instances, including at least one master node.
For example, assume that the cluster contains six nodes, namely A, B, C, A1, B1, and C1, where A, B, and C are the primary nodes, and A1, B1, and C1 are A, B, C slave node, and A client Z1. If A network partition occurs in the cluster, the cluster may be divided into two parties. Most of the Parties include nodes A, C, A1, B1, and C1, A small part of the party includes Node B and client Z1.
Z1 can still be written to master B. If the network partition takes a short time, the cluster will continue to operate normally. If the partition time is sufficient, most of the Parties will elect B1 as the new master, so the data written to B by Z1 is lost.
Note that the maximum time for sending write commands to master node B on the client Z1 is limited when the network is split. This time limit is called node timeout ), is an important configuration option for Redis clusters: