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

This article mainly introduces "how to build a Redis cluster". In the daily operation, I believe many people have doubts about how to build a Redis cluster. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts about "how to build a Redis cluster". Next, please follow the editor to study!

Prepare the node

Since it is to build a cluster, then the nodes must be multi-node, generally speaking, the number of nodes is at least 6 to ensure a highly available cluster. In addition, each node needs to be configured with cluster-enabled yes. Since the configuration of each node is the same except for different ports, we have taken the configuration of a node as an example to introduce the configuration of a cluster node. The specific configuration is as follows:

# Node Port

Port 6379

# enable cluster mode

Cluster-enabled yes

# Node timeout (in milliseconds)

Cluster-node-timeout 15000

# Cluster internal configuration file

Cluster-config-file "nodes-6379.conf"

Let's start 6 nodes:

. / src/redis-server redis-6379.conf

. / src/redis-server redis-6380.conf

. / src/redis-server redis-6381.conf

. / src/redis-server redis-6382.conf

. / src/redis-server redis-6383.conf

. / src/redis-server redis-6384.conf

When the node starts successfully, if there is no cluster configuration file, Redis will automatically create one, and the file name is the name specified by the cluster-config-file parameter in our Redis configuration file. If a cluster profile exists at startup, the node initializes the cluster information with the contents of the configuration file. The specific startup process is shown in the following figure:

Redis in cluster mode also has a cluster configuration file in addition to the original configuration file. This is because when the information of nodes in the cluster changes, such as adding nodes, node downline, failover and so on. The node automatically saves the cluster state to the configuration file. And the cluster configuration file does not need to be modified by the user, but is automatically maintained by Redis.

Since we have just started the 6379 node, Redis generates the nodes-6379.conf file in the root path of Redis by default. Let's take a look at the contents of the file.

Nodes-6379.conf:

3f9fa1009630b24e8049117b8492503af64dbabb: 637916379 myself,master-00 connected 3612 5257 7743 8021 8280 9558 11276 12216 12539 14895

Vars currentEpoch 0 lastVoteEpoch 0

The contents of the file record the initial state of the cluster. Includes the node ID. It is made up of a 40-bit hexadecimal string and is the unique identity used to distinguish cluster nodes. What is mentioned above is that the node ID is not running ID. They are very different. Because the node ID is created only once when the cluster is initialized, the cluster configuration file will be loaded and reused when the node is restarted, and the running ID of Redis will change each time it is restarted. In addition, we can also get the information of the cluster nodes through the cluster nodes command.

Each node can only recognize its own node information for the time being. Although we started 6 nodes, they didn't know each other existed. So next we need to shake hands with the nodes and let them connect with each other in order to form a cluster.

Node handshake

Node handshake means that a group of nodes running in cluster mode communicate with each other through Gossip protocol, so that they can perceive the existence of other nodes. The node handshake is a step in which the cluster communicates with each other. The specific operation is to issue the following command on the client:

Cluster meet {ip} {port}

The execution logic in the figure above is that cluster meet 127.0.0.1 6380 allows nodes 6379 and 6380 nodes to shake hands. The cluster meet command is an asynchronous command that returns immediately after execution. Initiates handshake communication with the target node within the Redis.

Let's execute the following command to get other nodes to join the cluster and you can use the cluster nodes command to see if other nodes have joined the cluster.

When any node in the cluster executes the cluster meet command to join the new node, the handshake status will spread through the cluster through the message, so that other nodes will automatically discover the new node and initiate the handshake process. After the node establishes the handshake, the cluster does not work because the cluster is offline and all data reading and writing is disabled.

We read the prompt and found that the provider slot did not provide a service. This is because we have not allocated slots for Redis yet.

Distribution slot

The Redis cluster maps all the data to 16384 slots. Each key is mapped to a fixed slot, and only when the node assigns slots can it respond to the key commands associated with those slots. In Redis, you can assign slots to nodes through the cluster addslots command. The specific commands are as follows:

According to the above command, we have allocated an average of 16384 slot to 6379, 6380, and 6381 nodes. We can check the cluster status through the cluster info command.

From the figure above, we know that the status of the cluster is ok, indicating that the cluster has entered a state of one. And all slots have been assigned nodes, execute the cluster nodes command to see the allocation relationship between nodes and slots:

Because we have assigned slots to the first three front points, and there are other three nodes that are not used. This is because a complete cluster, each responsible processing slot should have a slave node to ensure automatic failover in the event of a failure. In cluster mode, the nodes of Redis are divided into master nodes and slave nodes. Because we assign slots to the master node, the slave node can mainly copy the slot information and related data of the master node. In Redis, we can make a node a slave through the cluster replicate {nodeId} command. The above command can only be executed on the slave node, and nodeId is the ID of the master node, not running ID.

Master-slave replication in Redis cluster mode uses the replication process described in the previous article and still supports full and partial replication. We can still view the cluster status and replication relationships through the cluster nodes command.

The above content is to manually build a cluster environment using the Gossip protocol in Redis. From the above building, we know that manually building a cluster can deepen our understanding and details of the Redis cluster process, but it also has its disadvantages, that is, there are many steps. When there are too many cluster nodes, the greater the complexity and time cost of manually building the cluster. So in order to help us build a cluster environment quickly, Redis provides redis-trib.rb tools. With this tool, we can quickly build a Redis cluster. In the next article, we will cover the detailed use of the redis-trib.rb tool.

At this point, the study on "how to build a Redis cluster" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.