An introduction to the Redis cluster cluster

  • 2020-06-19 12:03:03
  • OfStack

1. Introduction

There are two main Redis cluster patterns:

Master-slave cluster, distributed cluster.

The former is mainly for high availability or read and write separation, while the latter is for better storage data and load balancing.

The redis cluster provides two benefits

1. Automatically shard data (split) to multiple nodes

2. When one of the nodes in the cluster fails, redis can continue to process client requests.

An redis cluster contains 16,384 hash slots (hash slot), and every data in the database belongs to one of those 16,384 hash slots. The cluster USES the formula CRC16(key) % 16384 to calculate which slot the key key belongs to. Each node in the cluster is responsible for processing a one-part hash slot.

Master-slave replication in a cluster

Each node in the cluster has 1 to N replicas, of which 1 is the master node and the rest are slave nodes. If the master node goes offline, the cluster will set one slave node of this master node as the new master node and continue to work. This way the cluster will not fail due to the offline of 1 master node

Note:

1. The redis cluster will stop working if one of its master nodes and all of its slave nodes go offline. The redis cluster does not guarantee a strong 1 for data, and under certain circumstances the redis cluster will lose write commands that have already been executed

2. Using asynchronous replication (asynchronous replication) is one of the reasons that redis clusters may lose write commands. Sometimes, due to network reasons, if the network is disconnected for too long, the redis cluster will enable the new master node and the data sent to the master node will be lost.

2. Principle of master-slave switching

The master-slave principle of Redis is similar to that of MySQL in that two machines are set up, 1 master-slave. This is often referred to as hot and cold standby. Set up two sentinel processes at the same time as the master and slave to detect if the master node is down. If the primary node is down, the appropriate node is immediately selected from the slave node as the new primary node. This is similar to VIP(virtual IP technology).

Redis cluster TCP port

Each node in the Redis cluster needs to open two TCP connections, which require two ports, the regular Redis TCP command ports for serving clients (for example 6379) and the ports obtained by adding 10000 and command ports (10000+6379), which are cluster ports (for example 16379).

The second large port is used for the cluster bus, a node-to-node communication channel using the base 2 protocol. The nodes use the cluster bus for fault detection, configuration update, failover authorization, and so on. The client should not attempt to communicate with the cluster bus port. To ensure proper use of the Redis command port, make sure both ports are open in the firewall, otherwise the Redis cluster node will not be able to communicate.

The command port and cluster bus port offsets are fixed, always at 10000.

Note that in order for the Redis cluster to work properly, you need to:

1. The normal client communication port (usually 6379) for communicating with clients is open to all clients that need to reach the cluster and all other cluster nodes (using the client port for key migration).

2. The cluster bus port (client port + 10000) must be accessible from all other cluster nodes.

If you do not open these two TCP ports, your cluster will not work properly.

Cluster buses use different base 2 protocols for node-to-node data exchange, which is more suitable for exchanging information between nodes with little bandwidth and processing time.

4.Redis cluster and Docker

Currently, the Redis cluster does not support the NAT address environment and is in a general environment where the IP address or TCP port is remapped.

Docker USES a technique called port mapping: a program running in an Docker container may be exposed to a different port than the one the program thinks it is using. This is useful for running multiple containers on the same port at the same time on the same 1 server.

To make Docker compatible with Redis Cluster, you need to use Docker's host networking mode. For more information, see the net = host option in the Docker document.

5.Redis cluster data sharding

The Redis cluster does not use a hash of 1, but a different form of sharding, where each key is conceptually part of what we call a hash slot.

There are 16,384 hash slots in the Redis cluster. To calculate the hash slots for a given key, we simply take CRC16 of 16384 modules.

Each node in the Redis cluster is responsible for a subset of the hash slots; for example, you might have a cluster with three nodes, where:

1. Node A contains hash slots from 0 to 5500. 2. Node B contains hash slots from 5501 to 11,000. 3. Node C contains hash slots from 11001 to 16383.

This allows nodes in the cluster to be added and removed easily. For example, if I want to add a new node, D, I need to move some hash slots from nodes A, B, C to D. Similarly, if I want to remove node A from the cluster, I can just move the hash slots used by A to B and C, and when node A will be empty, I can remove it from the cluster completely.

Because there is no downtime to move a hash slot from one node to another, there is no downtime to add and remove the node or change the percentage of hash slots occupied by the node.

The Redis cluster supports multiple key operations as long as all key involved in a single command execution (or entire transaction or Lua script execution) belong to the same 1 hash slot. Users can use a concept called a hash tag to force multiple key to become part 1 of the same hash slot.

The Hash tag is recorded in the Redis clustering specification documentation, but the point is that if there is a substring within the keyword {} bracket, then only the contents within the curly brace '{}' are hashed, for example this{foo}key and another{foo}key are guaranteed to be in the same hash slot and can be used in a command with multiple key as arguments.

6. Master slave model of Redis cluster

To remain available if a subset of the primary server nodes fails or cannot communicate with most nodes, the Redis cluster USES the master-slave model, where each hash slot runs from 1 (the primary server itself) to N copies (N-1 additional slave nodes).

In the cluster where we have examples of nodes A, B, C, if node B fails, the cluster cannot continue because we have no way to provide a hash slot in the range of 551-11,000. However, when the cluster is created (or later), we add one slave node for each master server node so that the final cluster consists of A, B, C as the master server node, and A1, B1, C1 as the slave nodes, and the system can continue to run if node B fails. If node B1 replicates B and B fails, the cluster will force node B1 to be the new primary server node and will continue to operate correctly.

Note, however, that the Redis cluster cannot continue if nodes B and B1 fail at the same time.

7.Redis Cluster 1 sex guarantee

The Redis cluster does not guarantee a strong 1 sex. In practice, this means that in some cases the Redis cluster may lose the writes that the system confirms to the customer.

The first reason the Redis cluster can lose writes is because it USES asynchronous replication. This means that the following things happen during writing:

1. Your client is writing to the primary server node B 2. Master server node B replies to your client for confirmation. 3. Master server node B propagates writes to its slave servers B1, B2, and B3.

As you can see the main server nodes B before reply the client does not wait for B1, B2, B3 confirmation, because it can cause serious delay of Redis losses, so if your client to write something, the primary node B confirmed, it will be written to send to it from the server node crashed before storage, one from the station (didn't receive written) can promote station is given priority to, lost to forever.

This is very similar to what happens to most databases configured to flush data to disk per second, because past experience is related to traditional database systems and does not involve distributed systems, so you can already infer this. Again, by forcing the database to flush the data on disk before replying to the client, you can improve performance by 1, but this usually results in very low performance. This is equivalent to synchronous replication in Redis Cluster.

Basically, there is a tradeoff between performance and 1.

Redis cluster also supports synchronous write when absolutely necessary, through WAIT command implementation, which makes the possibility of loss to reduce, but please note that even using synchronous replication, Redis cluster could not realize the consistency of the complete: it is always possible reason often happens, the unacceptable writing from equipment were selected primarily.

Another noteworthy situation is that the Redis cluster also loses data writes, which occurs when the network is partitioned and the client is isolated from a small number of instances that contain at least one primary server.

Take the 6-node cluster consisting of A, B, C, A1, B1, C13 master stations and 3 slave stations as an example. We have one more customer and we're going to call Z1.

After a partition occurs, there may be A, C, A1, B1, C1 on one side of the partition, and B and Z1 on the other side.

Z1 can still write B, and it will also accept Z1. If the partition is restored in a short time, the cluster will continue normally. However, if the partition takes a long time to promote B1 to the master of most side partitions, the write operation sent by Z1 to B will be lost.

Note that the number of writes Z1 can send to B has a maximum window (maximum window) : if most sides of the partition have enough time to select a slave as the primary device, each master node on the minority side will stop accepting writes.

This time value is a very important configuration directive for the Redis cluster, called node timeout (node timeout).

After the node has timed out, the primary node is considered invalid and can be replaced by its copy 1. Similarly, after the node has timed out, the master node is unaware of most of the other master nodes, enters an error state and stops accepting writes.

8.redis fault tolerance mechanism

Each redis provides the ping command sent to each other among nodes to test the health status of each node. When the connected nodes in the cluster receive the ping command sent by other nodes, one pong string will be returned

Redis Voting Mechanism: If one node A send B ping didn't get pong returns, then A will notify the other nodes to send B ping again, if more than one and a half of cluster nodes send B ping didn't get back, then B was filled game over, so in order to avoid a single point of failure, 1 kind for redis each node provides a backup node, The B node server is started immediately after the B node is suspended.

conclusion


Related articles: