Redis Cluster principle

One, Redis cluster

The Redis cluster implementation is a built-in data auto-sharding mechanism that maps all keys into 16,384 slots within the cluster, and each Redis instance in the cluster is responsible for reading and writing the slots in the section. The cluster client connects to any Redis instance in the cluster to send commands, and when Redis instance receives a request for its own non-responsible slot, it returns the Redis instance address in the slot where the key is requested to the client. After receiving the client, the original request is automatically re-sent to this address, externally transparent. Exactly which slot a key belongs to is determined by CRC16 (key)% 16384.

Note: The cluster must have more than 3 master nodes, otherwise it will fail when the cluster is created, and we will practice it later.

So, let's assume that there are now 3 nodes that have formed the cluster: A, B, C three nodes, which can be three ports on a single machine or three different servers. So, by 哈希槽 (hash slot) allocating 16,384 slots in the same way, the slots that each of their three nodes assume are:

• Node A covers 0-5460;
• Node B covers 5461-10922;
• Node C covers 10923-16383.

Second, the master-slave model of Redis cluster
In order for a partial node to fail, or to remain available when communication with most nodes is not possible, the Redis cluster employs a master-slave model of 1 (the primary service itself) to N replicas (N-1 additional slave servers) per node.
In our example, the cluster has a,b,c three nodes, and if node B fails the cluster will not continue to serve because we no longer have a way to service the hash slots in the 5501-11000 range.
However, if after we create the cluster (or later), we add a slave server for each primary server, so that the final cluster is composed of the primary server a,b,c and the server A1,B1,C1, if the B-node failure system continues to service.
The B1 node replicates the B-node, and the cluster elects the B1 node as the new primary server and continues to operate correctly.

Third,the consistency guarantee of Redis cluster

Redis clusters do not guarantee strong consistency. In practice, this means that under certain conditions, the Redis cluster may lose some of the write request commands received by the system.

The first reason why a redis cluster loses a write request is because asynchronous replication is used. This means that the following things have happened during the write:

• Your client writes to primary Server B.
• master Server B replies OK to your client.
• master Server B propagates write operations to its slave servers b1,b2 and B3.

As you can see, B does not wait for confirmation from B1,B2,B3 before replying to the client, because this is a high latency cost, so if your client writes something, B confirms the write operation, but when it sends a write operation to it crashes from the server, one of the servers is promoted to the primary server, This write operation was lost permanently.

This is very similar to what happens in most databases that are configured to refresh data to disk per second, which is a scenario that can be inferred from the experience of traditional database systems that do not previously include distributed systems. Similarly, you can improve consistency by forcing the database to flush data to disk before replying to the client, but this often greatly degrades performance.

Basically, there is a tradeoff between performance and consistency.

Note: In the future, Redis clusters might or may allow users to perform synchronous write operations if necessary.

Redis Cluster lost write operation there is another scenario in which the client and a few instances that contain at least one primary server are isolated when the network is split.

For example, our cluster consists of a total of 6 nodes from A,B,C,A1,B1,C1, 3 primary servers, and 3 slave servers. There is also a client that we call Z1.

After segmentation occurs, it is possible to split the side of the A,C,A1,B1,C1, the other side of the split is B and Z1. Z1 can still write to B that can accept write requests. If the split is resumed within a short period of time, the cluster will continue normally. However, if the split lasts enough time, the B1 on most of the split side is promoted to the primary server, and the write request Z1 sent to B is lost.

Note that the number of write operations sent to B by the Z1 has a maximum window: if the majority of the sides of the segment elect one from the server to the primary server after a sufficient amount of time, the minority side of each primary server node will stop accepting write requests.

This amount of time is a very important configuration directive for the Redis cluster, called node timeout.

After the node time-out expires, the primary server node is considered invalid and can be replaced with a copy. Similarly, after the node timeout expires, the primary server node is not aware of the majority of other primary server nodes, then goes into an error state and stops accepting write requests.

Redis Cluster principle