Redis cluster, redis Cluster

Redis cluster, redis Cluster
Cluster understanding

In fact, many places may be exposed to the concept of clusters. Why is there a cluster? Simply put, it is just how good people do things. It was originally a task that a person had to work hard to complete. Now it is done by ten people, and ten people can do it easily. In the case of massive data, today, if you want to process and store more data, but do not have powerful support for large computers, cluster is a good choice.

Redis also supports clusters. Redis clusters share data through [sharding] (in fact, all clusters involved in the database usually have the concept of sharding or partitioning ).

Let's take a brief look at what we need to learn about Redis clusters, just like a summary before class in college. First, since it is a cluster, it must be a part of the cluster-[node]. What are the nodes? What is the difference from a common Redis server? Second, what is a part as mentioned above? What should I do when I give the score? Third, the cluster is composed of many computer servers. What should I do if one of them goes down? Is the whole cluster paralyzed? How can we prevent and handle node downtime in this cluster? Replication and Failover are involved here.

Several concept nodes to be explained

The cluster must be about nodes. The cluster composed of nodes does not have any clusters on any node. You can clearly understand what nodes are, [The node is the Redis server running in cluster mode]. The difference between the nodes in the cluster and the common Redis server is not difficult to predict, the common Redis server is only a single-host server. It honestly processes the commands sent from the client, and then returns the processing results honestly. the nodes are different. In addition to these, the nodes are still part of the cluster, take into account the data used in the cluster, such as information about other nodes in the cluster, shaking hands with other nodes, and determining whether other nodes are offline.

Cluster Mode

In fact, the cluster mode has been introduced in the node. The straightforward point is that the server runs in a state, and the straightforward point is actually a flag in a configuration file, redis. conf has a configuration item. [cluster-enabled yes] determines whether the value of this configuration item is yes when the Redis server is started. If yes, the cluster mode of the server is enabled, to make the server a node in cluster mode, [Note that a node in cluster mode cannot be a cluster, one by one, and finally a node, it cannot be a network and needs to be connected. here we need to use a redis command, cluster meet ip port, to connect two nodes to form a cluster]

Slice and slot

The concept of partitioning is not hard to understand. It can be imagined that a sesame cake is too big to be processed. If you cut it, the sesame seeds on it will be distributed to different parts, sharding is a verb used to separate the pie. [sharding refers to the process of splitting data and distributing it to different machines, the concept of partition is also used.] The above concepts are found in a MongoDb book and I think they can also be used in Redis. However, they are a bit different. [Note, redis sharding actually divides a big pancake into many small biscuits and then spreads sesame seeds on the biscuits. As for which small biscuits should be used, this requires computing, through sesame features] the major point is that the entire database in the cluster is regarded as a big biscuit, which is divided into 16384 small biscuits [Slot], the keys in the database (that is, sesame in the example) all belong to these slots. Which of the following is the "slot" of this slice? We can use commands to assign [slots assignment, cluster addslots slots] slots are from 0 to 16383, but after all the slots are allocated to the node, the cluster database is actually online, you can accept the command for processing keys sent from the client. One step here is that each node transmits their respective slot assignment information, that is, everyone knows which node handles the slots.

In the cluster, how does one split the command into a slot when the cluster database is online? How does one handle the commands sent from the client? Which node is responsible for the operation key commands sent from so many nodes? For example, if I want node A to send A [set data "zhangsan"] command through computation, the data key is saved in the No. 368 slot, node A will check whether it manages the No. 368 slot. If it is not owned by node A, it will be managed by the node and then Redirected this command to the node managing the No. 368 slot. The same is true for the [get data] command. First, calculate the slot of the data key and run the command redirected to that node.

Resharding and resharding change the slot allocation. Change the slot assigned to a node to another node. The resharding operation of the Redis cluster is performed by the redis-trib management software, during the sharding process, the cluster does not need to be taken offline, and the source and target nodes can continue to process command requests. For detailed implementation principles, refer to the Redis help documentation. Replication and Failover are essential and the most important part. the nodes in the Redis cluster are divided into the master node and slave node (this is not a bit familiar, redis is also a master server and slave server. You can refer to the Redis guard for better understanding.) normally, the master node is responsible for processing command requests. The slave node is only responsible for copying the content of the master node, however, if the master node goes offline, other running master nodes will select one from the slave node as the new master node (which is the same as the Sentinel) so how can we determine whether a node is offline? (The Sentinel system is used to monitor each server. If the server is deprecated beyond the configured duration, failover is performed.) check whether a node is deprecated, mutual detection is performed between nodes. Each node regularly sends ping commands to other nodes. If pong is received within the specified time, It is online normally, otherwise, the node that sends the ping command is marked as suspected offline. If half of the nodes mark a node as suspected offline, the suspected offline node is marked as offline, failover is performed.

Copyright Disclaimer: This article is an original article by the blogger and cannot be reproduced without the permission of the blogger.