Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Example Analysis of redis Cluster Scheme

2025-03-30 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >

Share

Shulou(Shulou.com)05/31 Report--

This article mainly shows you the "sample analysis of redis cluster scheme", which is easy to understand and clear. I hope it can help you solve your doubts. Let the editor lead you to study and learn the article "sample analysis of redis cluster scheme".

1. Master-slave mode

There are two main problems with storing data completely in a single redis:

Performance degradation caused by data backup and large data volume.

The master-slave mode of Redis provides a better solution to these two problems. Master-slave mode refers to the use of one redis instance as the host and the rest of the instances as the backup machine.

The data of the host and the slave are completely the same, and the host supports various operations such as writing and reading data, while the slave only supports synchronization and reading of the data with the host, that is to say, the client can write the data to the host. The host automatically synchronizes the data writing operation to the slave.

The master-slave mode solves the problem of data backup very well, and because the master-slave service data is almost consistent, the command for writing data can be sent to the host for execution, while the command for reading data can be sent to different slaves for execution. in order to achieve the purpose of reading and writing separation.

How master-slave replication (Master-Slave Replication) works:

After Slave starts from the node service and connects to Master, it will actively send a SYNC command. After receiving the synchronization command, the master node of the Master service will start the background save process and collect all the commands received to modify the dataset. After the background process is completed, Master will transfer the whole database file to Slave to complete a complete synchronization. The Slave slave node service saves the database file data and loads it into memory after receiving it. Since then, the Master master node continues to transmit all the collected modification commands and new modification commands to Slaves,Slave in turn. These data modification commands will be executed this time to achieve the final data synchronization.

If the link between Master and Slave is disconnected, Slave can automatically reconnect the Master, and after a successful connection, a full synchronization will be performed automatically.

Deployment:

Redis version:6.0.9

1. Copy 4 Redis configuration files respectively

Named master.conf slave1.conf slave2.conf slave3.conf

two。 Simple configuration of 4 profiles

The configuration files of Master nodes generally do not require special settings. Port is 6379 by default.

Slave1 node port setting 6380 and then configure a row of replicaof 127.0.0.1 6379

Slave2 node port setting 6381 and then configure a row of replicaof 127.0.0.1 6379

Slave3 node port setting 6382 and then configure a row of replicaof 127.0.0.1 6379

3. Open the Master node and 3 Slave nodes respectively

Redis-server master.conf

Redis-server slave1.conf

Redis-server slave2.conf

Redis-server slave3.conf

4. Verify the cluster master-slave status

Advantages and disadvantages of master-slave mode:

1. Advantages:

Multiple Slaves can be synchronized with the same Master.

Master can automatically synchronize data to slave, separate read and write, and share the reading pressure of master.

Synchronization between master and slave is carried out in a non-blocking manner. During synchronization, the client can still submit queries or update requests.

2. Disadvantages:

Without automatic fault tolerance and recovery, the downtime of master or slave may cause the client request to fail. You need to wait for the machine to restart or manually switch the client IP to recover.

Master is down. If the data is not synchronized before the downtime, there will be data inconsistency after switching IP.

It is difficult to support online expansion, and the capacity of Redis is limited by stand-alone configuration.

In fact, the master-slave mode of redis is very simple and rarely used in the actual production environment. It is not recommended to use the master-slave mode to provide high availability of the system in the actual production environment. The reason why it is not recommended to use is caused by its shortcomings. In the case of a very large amount of data or high requirements for the high availability of the system, the master-slave mode is also unstable. Although this model is very simple, but this model is the basis of other models, so understanding this model will be very helpful to the learning of other models.

Second, Sentinel mode (Sentinel)

As the name implies, the Sentinel is here to stand sentry for the Redis cluster, and once a problem is found, it can be dealt with accordingly. Its functions include

Monitor whether master and slave are running properly

When master breaks down, it can automatically convert a slave to master (if the eldest brother is dead, choose a younger brother)

Multiple Sentinels can monitor the same Redis, and Sentinels will automatically monitor each other.

When slave and other sentinel nodes are automatically discovered, Sentinels can periodically monitor whether these databases and nodes are out of service by sending regular PING commands.

If the PING's database or node times out (configured through sentinel down-after-milliseconds master-name milliseconds) and does not reply, the Sentinel considers it subjectively offline (sdown,s is Subjectively-subjectively). If master is offline, the Sentinel will send commands to other Sentinels to ask if they also think that the master is subjectively offline. If a certain number (that is, quorum in the configuration file) votes, the Sentinel will think that the master has been objectively offline (odown,o is Objectively-objectively), and elect the leading Sentinel node to initiate fault recovery to the master-slave system. If not enough sentinel processes agree to master offline, the objective offline status of master will be removed, and if the PING command sent by master to the sentinel process returns a valid reply, the subjective offline status of master will be removed.

The sentry believes that after the master is objectively offline, the fault recovery operation needs to be carried out by the leading sentry of the election.

After the lead sentry is selected, the leader begins to recover the system and selects a new master from the database of the failed master.

After selecting the slave that needs to be succeeded, the lead sentry sends a command to the database to upgrade it to master, then sends a command to other slave to accept the new master, and finally updates the data. Update the stopped old master to the new master slave database so that it can resume service and continue to run as slave.

The Sentinel mode is based on the previous master-slave replication mode. The configuration file of the Sentinel is sentinel.conf. Add the following configuration in the corresponding directory, and make sure that the ports do not conflict:

Port 26379protected-mode nodaemonize yespidfile "/ var/run/redis-sentinel-26379.pid" logfile "/ data/redis/logs/sentinel_26379.log" dir "/ data/redis/6379" sentinel monitor mymaster 127.0.0.1 6379 2 # # specify the host IP address and port, and specify that when two Sentinels think the host is dead, the host will be switched for disaster recovery # sentinel auth-pass mymaster pwdtest@2019 # # when requirepass is enabled in the Redis instance Here, you need to provide the password sentinel down-after-milliseconds mymaster 3000 # #. If you set the number of seconds for which the host does not respond, the timeout for sentinel failover-timeout mymaster 180000 # # failover is considered to be failed. Here, it is set to three minutes.

The format is as follows:

View Sentinel status:

3. Redis cluster mode (Cluster)

Cluster adopts a centerless structure, which has the following characteristics:

The client is directly connected to the redis node. The client does not need to connect to all the nodes in the cluster, but can connect to any available node in the cluster.

The specific working mechanism of the Cluster mode:

On each node of the Redis, there is a slot (slot) with values ranging from 0 to 16383, with a total of 16384 slots

When we access key, Redis will get a result according to CRC16's algorithm, and then calculate the remainder of 16384, so that each key will correspond to a hash slot numbered between 0 and 16383. Through this value, we can find the node corresponding to the corresponding slot, and then automatically jump to the corresponding node for access operation.

To ensure high availability, Cluster mode also introduces master-slave replication mode, in which a master node corresponds to one or more slave nodes. When the master node goes down, the slave node is enabled.

When other master nodes ping a master node A, if more than half of the master nodes time out to communicate with A, then the master node An is considered to be down. If both master node An and its slave nodes are down, the cluster can no longer provide services.

Redis cluster, to ensure that the node corresponding to 16384 slots is working properly. If a node fails, the slots it is responsible for will also fail, and the whole cluster will not work.

In order to increase the accessibility of the cluster, the officially recommended solution is to configure node as a master-slave structure, that is, a master master node with n slave slave nodes. At this time, if the primary node fails, Redis Cluster will select a rising primary node from the slave node according to the election algorithm, the whole cluster will continue to provide services, and Redis Cluster itself provides the ability to fail over and fault tolerance.

The cluster node in Cluster mode is configured with a minimum of 6 nodes (according to the election mechanism of cluster and the implementation of master-slave backup, redis requires at least 6 nodes with three masters and three slaves to form a redis cluster, because at least half of the nodes are required to determine whether a node is down and master-slave backup is needed), in which the master node provides read and write operations, the slave node serves as a standby node, does not provide requests, but is only used as a failover.

Cluster cluster deployment

According to the election mechanism of cluster and the implementation of master-slave backup, redis requires at least six nodes of three masters and three slaves to form a redis cluster. The test environment can start six redis nodes on one physical machine, but at least two or three physical machines must be prepared in the production environment. (three virtual machines are used here)

The Cluster mode is based on the Sentinel mode. When there is so much data that it needs dynamic expansion, the first two are not good. It is necessary to slice the data and distribute the redis data to multiple machines according to certain rules.

This mode supports dynamic expansion, nodes can be added or deleted online, and the client can connect to any master node for reading and writing, but the slave node is only for backup. As for why dynamic expansion can be achieved, it is mainly because the Redis cluster does not use consistent hash, but uses hash slots. The Redis cluster will have 16384 hash slots. Each key is checked by CRC16 and then modulates 16384 to decide which slot to place, and each node of the cluster is responsible for part of the hash slot.

Then it is easy to add or remove nodes, for example, if I want to add a new node, I only need to come from some of the existing nodes; if I want to remove a node, just move the slot of that node to another node, and then remove the A node without any slots from the cluster. Because moving hash slots from one node to another does not stop service, no matter adding, deleting or changing the number of hash slots of a node will not cause the cluster to be unavailable.

It should be noted that simultaneous processing of multiple key (such as MSET/MGET) is not supported in this mode, because redis needs to distribute the key evenly across each node, and creating key-value at the same time in the case of high concurrency will degrade performance and lead to unpredictable behavior.

Set up a cluster

Here we directly build a more complex Cluster pattern cluster, which is also the most widely used in the process of enterprise development.

1. Build the directory of each node in redis

The final directory structure is as follows

two。 Modify the redis configuration one by one

Take 9001 as an example, the other five are similar.

Edit / data/redis-cluster/9001/redis.conf

The redis.conf is modified as follows:

Port 9001 (port number of each node) daemonize yesappendonly yes / / enable aofbind 0.0.0.0 (bind the current machine IP) dir "/ data/redis-cluster/9001" (data file storage location Add yourself to the last line of shortcut shift+g) pidfile / var/run/redis_9001.pid (pid 9001 and port to correspond) logfile "/ data/redis-cluster/logs/9001.log" cluster-enabled yes (start cluster mode) cluster-config-file nodes9001.conf (9001 and port to correspond) cluster-node-timeout 150003. Start redis nodes one by one

/ data/redis-cluster/bin/redis-server / data/redis-cluster/9001/redis.conf

/ data/redis-cluster/bin/redis-server / data/redis-cluster/9002/redis.conf

/ data/redis-cluster/bin/redis-server / data/redis-cluster/9003/redis.conf

/ data/redis-cluster/bin/redis-server / data/redis-cluster/9004/redis.conf

/ data/redis-cluster/bin/redis-server / data/redis-cluster/9005/redis.conf

/ data/redis-cluster/bin/redis-server / data/redis-cluster/9006/redis.conf

Now check to see if it is enabled successfully, as shown in the following figure.

Ps-el | grep redis

4. Cluster configuration

Although the nodes start successfully at this time, they are not in a cluster yet and cannot find each other. The test will report an error: (error) CLUSTERDOWN Hash slot not served.

As shown in the following figure

Redis-cli-- cluster create 10.32.176.80 cluster-replicas 9002 10.32.176.80 cluster-replicas 9002 10.32.176.80 cluster-replicas 9003 10.32.176.80

-cluster-replicas 1 refers to the number of slaves, indicating that we want to create one slave node for each master node in the cluster.

The red marquee is a total of 16384 slots assigned to the three primary nodes.

The yellow box is the allocation of the master and slave nodes.

The blue box is the details of each node.

5. test

Now connect through the client command and take a look at the status and node information through the cluster command.

/ data/redis-cluster/bin/redis-cli-c-h 10.32.176.80-p 9001cluster infocluster nodes

The effect figure is as follows, and the cluster is built successfully.

Now write a message to the master node 9001, we can get the information at the master node 9002, and each node in the cluster can communicate.

6. Fail-over

Detailed explanation of failover mechanism

The node in the cluster will send a PING message to other nodes (the PING message will carry the information of the current cluster and node). If the corresponding PONG message is not received within the specified time, the node will be marked as suspected offline. When more than half of the primary nodes assigned slot slots think that this node is suspected to be offline (that is, other nodes PING-PONG with this node more frequently), then the node is really offline. After other nodes receive the broadcast that a node has gone offline, modify their own internal cluster maintenance information to the fact that the node has gone offline.

Node qualification: then the slave node is qualified, and each slave node checks the last disconnection time with the master node, and if this value exceeds the setting of the profile, the slave node is disqualified. Time to prepare for the election: a delay trigger mechanism is used here, mainly to give higher priority to those with low delay, those with low delay to participate in the election in advance, and those with high delay to participate in the election later. (the delay is determined according to the last disconnection time with the master node.)

Election voting: when a slave node is eligible for election, an election request will be made to other master nodes with slot slots, and the higher the priority slave node is, the more likely it is to become the master node. When the number of votes obtained from the slave node reaches a certain value (for example, if there are N master nodes in the cluster, as long as one slave node wins the NMP2 master 1 vote), it will be replaced as the master node.

Replace the master node: the elected slave node executes slaveof no one to change its state from slave to master, then executes clusterDelSlot operation to cancel the slot responsible for the failed master node, and executes clusterAddSlot to assign these slots to itself, and then broadcasts its own pong message to the cluster, informing all nodes in the cluster that the current slave node has become the master node.

Take over related operations: the new master node takes over the slot information of the previously failed master node and receives and processes command requests related to its own slot.

Failover test

This is the case of the specific nodes in the cluster before. I can simplify it to the following, so I can look back at the cluster information in the picture.

Here, the process of shutting down the port 9001 is simulated to hang up the primary node.

Log in to a dead redis node and be denied service, enter through a master node that is still running, and then view the information in the cluster again.

In short, the previous cluster information is changed to the following

Now, I restart the primary node that just died and re-check the nodes within the cluster, as shown in the following figure

In short, the nodes in the cluster are now as follows

The above is all the content of the article "sample Analysis of redis Cluster Scheme". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

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.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Database

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report