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

What cluster solutions does Redis have? in view of this problem, this article introduces the corresponding analysis and solutions in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible way.

1. Basic principles

The master-slave replication mode contains one master database instance (master) and one or more slave database instances (slave), as shown in the following figure

The client can read and write to the master database and read to the slave database, and the data written by the master database will be automatically synchronized to the slave database in real time.

The specific working mechanisms are:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

After slave starts, a SYNC command is sent to master. After receiving the SYNC command, master saves the snapshot through bgsave (that is, RDB persistence described above), and uses a buffer to record the write commands executed during this period.

Master sends the saved snapshot file to slave and continues to record the write commands executed

After receiving the snapshot file, slave loads the snapshot file and loads the data

After the master snapshot is sent, the write command of the buffer is sent to slave, and the slave receives the command and executes it, completing the replication initialization.

Since then, every time master executes a write command, it will be sent to slave synchronously to maintain the consistency of data between master and slave.

two。 Deployment example

This example is based on Redis version 5.0.3.

Main configuration of redis.conf

# Network related # bind 127.0.0.1 # bind listening Nic IP, comment out or configure to 0.0.0.0 to enable any IP to access protected-mode no # disable protection mode, use password to access port 6379 # to set listening port. It is recommended to use custom port timeout 30 # for how long the client connection is idle in production environment (in seconds). 0: disable # generic configuration # daemonize yes # run pidfile / var/run/redis_6379.pid # pid process filename / usr/local/redis/logs/redis.log # log file location # RDB persistence configuration # save 900 1 # 900s execute bgsave for RDB persistence save 300 10 save 60 10000 # if RDB persistence is disabled You can add save "" rdbcompression yes # here whether to compress the RDB file. It is recommended to set it to no and exchange (disk) space for (CPU) time dbfilename dump.rdb # RDB file name dir / usr/local/redis/datas # RDB file save path, and the AOF file is also saved here # # AOF configuration # appendonly yes # the default value is no, which means that you do not use AOF incremental persistence. Use full persistence of RDB appendfsync everysec # optional values always, everysec,no. It is recommended to set the password for everysec # set password # requirepass 123456 # set a more complex password

To deploy the master-slave replication mode, you only need to adjust the configuration of slave slightly and add it to redis.conf.

Replicaof 127.0.0.1 6379 # master ip,port masterauth 123456 # master password replica-serve-stale-data no # if slave cannot be synchronized with master, set to slave unreadable to facilitate monitoring scripts to find problems

In this example, master port 6379 is configured on a single server, and the two slave ports are 7001 and 7002 respectively. Start master, and then start two slave.

[root@dev-server-1 master-slave] # redis-server master.conf [root@dev-server-1 master-slave] # redis-server slave1.conf [root@dev-server-1 master-slave] # redis-server slave2.conf

Enter the master database, write a data, and then enter a slave database, and you can immediately access the data just written to the master database. As shown below

[root@dev-server-1 master-slave] # redis-cli 127.0.0.1 auth 6379 > auth 123456 OK 127.0.0.1 auth 6379 > set site blog.jboost.cn OK 127.0.0.1 auth 6379 > get site "blog.jboost.cn" 127.0.0.1 auth 6379 > info replication # Replication role:master connected_slaves:2 slave0:ip=127.0.0.1,port=7001,state=online,offset=13364738,lag=1 slave1:ip=127.0.0.1,port=7002,state=online,offset=13364738 Lag=0... 127.0.0.1 lag=0 6379 > exit [root@dev-server-1 master-slave] # redis-cli-p 7001 127.0.1 root@dev-server-1 master-slave 7001 > auth 123456 OK 127.0.1 root@dev-server-1 master-slave 7001 > get site "blog.jboost.cn"

Execute the info replication command to view the information of other libraries connected to the database, as you can see above, there are two slave connected to master

3. Advantages and disadvantages of master-slave replication

Advantages:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

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.

Disadvantages:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

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.

Sentinel (sentry) mode

1. Basic principles

Sentinel mode is based on master-slave replication mode, but Sentinel is introduced to monitor and automatically handle failures. As shown in the picture

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

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

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.

The specific working mechanism of the Sentinel model:

Use sentinel monitor to locate the IP and port of master in the configuration file. A sentry can monitor multiple master databases. You only need to provide multiple configuration items. After the Sentinel starts, two connections are established with the master to be monitored:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

A connection is used to subscribe to the _ sentinel_:hello channel of master and to obtain information about other sentinel nodes that monitor the master

Another connection periodically sends commands such as INFO to master to obtain the information of master itself.

After establishing a connection with master, the Sentinel performs three actions:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Send INFO commands to master and slave periodically (usually once every 10 seconds, instead of once per second when master is marked as subjectively offline)

Send your own messages regularly to the _ sentinel_:hello channel of master and slave

Periodically (once per second) send PING commands to master, slave, and other sentinels

Sending the INFO command can obtain the relevant information of the current database and realize the automatic discovery of new nodes. So the sentry only needs to configure the master database information to automatically discover its slave information. After obtaining the slave information, the Sentinel will also establish two connections with the slave to perform monitoring. Through the INFO command, the sentry can get the latest information of the master-slave database and perform corresponding operations, such as role changes.

Next, the Sentinel sends a message to the sentinel:hello channel of the master-slave database to share its own information with the Sentinels who are also monitoring these databases, sending the Sentinel's ip port, running id, configuration version, master name, master ip port and master configuration version. This information is useful for the following purposes:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Other sentinels can use this information to determine whether the sender is a newly discovered sentinel, and if so, create a connection to the sentry to send the PING command.

Other sentinels can use this information to determine the version of master. If the version is higher than the directly recorded version, it will be updated.

When automatic discovery of slave and other sentinel nodes is implemented, Sentinels can regularly monitor whether these databases and nodes are out of service by sending PING commands on a regular basis.

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. If the PING command sent by master to the sentinel process returns a valid reply, the subjective offline state 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, and the election uses the Raft algorithm:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

The sentinel node that found master offline (we call him A) sent orders to each sentinel, asking him to choose himself as the lead sentry.

If the target sentinel node has not selected anyone else, it will agree to elect An as the lead sentry.

If more than half of the sentinels agree to elect An as the leader, A will be elected.

If multiple sentinel nodes take the lead in the election at the same time, there may be a round of voting and no candidate wins. At this time, each node waiting for a random time will launch a request to run again for the next round of voting until the lead sentry is elected.

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. The selection rules are as follows:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Choose the highest priority among all online slave, and the priority can be configured through slave-priority

If there are multiple slave with the highest priority, select the one with the largest replication offset (that is, the more complete the replication)

If all the above conditions are the same, select the slave with the smallest id

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.

two。 Deployment demonstration

This example is based on Redis version 5.0.3.

The Sentinel mode is based on the master-slave replication mode described above. The configuration file for Sentinel is sentinel.conf, which is added to the file.

Sentinel monitor mymaster 127.0.0.1 6379 1 # mymaster defines the name of a master database, followed by the ip of master. Port,1 indicates that at least one Sentinel process consent is required to judge master as invalid. If this condition is not met, automatic failover (failover) will not execute sentinel auth-pass mymaster 123456 # master password sentinel down-after-milliseconds mymaster 5000 # 5s does not reply to PING, then master is considered subjectively offline. The default is 30s sentinel parallel-syncs mymaster 2 # to specify the maximum number of slave instances that can synchronize new master instances when performing a failover. When there are more slave instances, the smaller the number and the longer the synchronization time, the longer the time it takes to complete the failover. Sentinel failover-timeout mymaster 300000 # if the failover operation is not completed within that time (ms), the failover is considered to have failed The production environment needs to set this value according to the amount of data.

A Sentinel can monitor multiple master databases by adding multiple sets according to the above configuration

Start three sentinel on port 2637936379j46379 respectively

[root@dev-server-1 sentinel] # redis-server sentinel1.conf-sentinel [root@dev-server-1 sentinel] # redis-server sentinel2.conf-sentinel [root@dev-server-1 sentinel] # redis-server sentinel3.conf-sentinel

It can also be started using the redis-sentinel sentinel1.conf command. The cluster now contains one master, two slave, and three sentinel, as shown in the figure

Let's simulate the scenario where master hangs up. Execute kill-9 3017 to kill the master process, and then go to slave and execute info replication to check.

[root@dev-server-1 sentinel] # redis-cli-p 7001 127.0.0.1 auth > auth 123456 OK 127.0.0.1 auth 7001 > info replication # Replication role:slave master_host:127.0.0.1 master_port:7002 master_link_status:up master_last_io_seconds_ago:1 master_sync_in_progress:0 # omit 127.0.0.1 auth 7001 > exit [root@dev-server-1 sentinel] # redis-cli -p 7002 127.0.0.1 info replication 7002 > auth 123456 OK 127.0.0.1 info replication # Replication role:master connected_slaves:1 slave0:ip=127.0.0.1 Port=7001,state=online,offset=13642721,lag=1 # ellipsis

You can see that slave 7002 has been successfully promoted to master (role:master), receiving a connection from slave 7001. At this point, check the slave2.conf configuration file and find that the configuration of replicaof has been removed. In the configuration file of slave1.conf, replicaof 127.0.0.1 6379 has been changed to replicaof 127.0.0.1 7002. Restart master, you can also see that the configuration item of replicaof 127.0.0.1 7002 has been added to the master.conf configuration file. It can be seen that after the eldest brother (master) is in the lower position, he can only be a slave when he comes out again. Hedong has been in the west for 30 years.

3. Advantages and disadvantages of Sentinel Model

Advantages:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Sentinel mode is based on master-slave replication mode, so there are some advantages of master-slave replication mode, and so does Sentinel mode.

In Sentinel mode, when master hangs up, it can be switched automatically and the system is more available.

Disadvantages:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

It also inherits the disadvantage that the master-slave mode is difficult to expand online, and the capacity of Redis is limited by stand-alone configuration.

Additional resources are required to start the sentinel process, which is relatively complex to implement, and the slave node does not provide services as backup nodes

Cluster mode

1. Basic principles

Sentinel mode solves the problem that master-slave replication can not fail over automatically and can not achieve high availability, but it is still difficult to expand online and the capacity of Redis is limited by stand-alone configuration. Cluster mode realizes the distributed storage of Redis, that is, each node stores different content to solve the problem of online expansion. As shown in the picture

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

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

All redis nodes are interconnected with each other (PING-PONG mechanism), and binary protocols are used internally to optimize transmission speed and bandwidth.

The fail of a node takes effect only when more than half of the nodes in the cluster detect failure.

The client is directly connected to the redis node and does not need an intermediate proxy layer. The client does not need to connect to all the nodes in the cluster, just connect to any available node in the cluster

The specific working mechanism of the Cluster mode:

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

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

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

4. 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 the master node An and its slave nodes are down, then the cluster can no longer provide services.

In Cluster mode, the cluster node is configured with a minimum of 6 nodes (3 master and 3 slaves, because more than half of them are needed), in which the master node provides read and write operations, and the slave node is used as a backup node, which does not provide requests and is only used for failover.

two。 Deployment demonstration

This example is based on Redis version 5.0.3.

The deployment of Cluster mode is relatively simple, first of all in redis.conf

Port 7100 # in this example, the 6 node ports are 7100, 7200, 7300, 7400, 7500, and 7600 daemonize yes # r, respectively, to run pidfile / var/run/redis_7100.pid # pidfile file in the background, corresponding to 7100, 7200, 7400, 7400, and 7500, cluster-enabled yes # turn on cluster mode masterauth passw0rd # if a password is set, you need to specify the configuration file of master password cluster-config-file nodes_7100.conf # cluster, also corresponding to six nodes, including 7100,7200, cluster-node-timeout 15000 # request timeout defaults to 15 seconds. It can be set by yourself.

Launch six instances on port 7100pc7200pr 7300pr 7400pl 7500pi 7600 (if it is one instance for each server, the configuration can be the same)

[root@dev-server-1 cluster] # redis-server redis_7100.conf [root@dev-server-1 cluster] # redis-server redis_7200.conf...

Then use the command to form the six instances into a cluster of 3 master nodes and 3 slave nodes

Redis-cli-- cluster create-- cluster-replicas 1 127.0.0.1 cluster-replicas 7100 127.0.0.1 cluster-replicas 7200 127.0.0.1 cluster-replicas 7300 127.0.0.1 cluster-replicas 7500 127.0.1 passw0rd

The execution result is as shown in the figure

You can see that 7100, 7200, 7300 as the three master nodes, the assigned slot is 0-5460, 5461-10922, 10923-16383, 7600 as the slave of 7100, and 7500 as the slave,7400 of 7300, as the slave of 7200, respectively.

We connect 7100 to set a value

[root@dev-server-1 cluster] # redis-cli-p 7100-c-a passw0rd Warning: Using a password with'- a'or'- u 'option on the command line interface may not be safe. 127.0.0.1 located at 7100 > set site blog.jboost.cn-> Redirected to slot [9421] located at 127.0.1 located at 7200 OK 127.0.1 located at 7200 > get site "blog.jboost.cn" 127.0.0.1

Note that the-c parameter is added to indicate cluster mode, otherwise (error) MOVED 9421 127.0.0.1 NOAUTH Authentication required error is reported, password is specified with-a parameter, otherwise (cluster) NOAUTH Authentication required error is reported.

From the above command, we can see that the slot calculated by key for site is 9421, which falls on 7200 nodes, so if there is Redirected to slot [9421] located at 127.0.0.1 slot 7200, the cluster will jump automatically. Therefore, the client can connect to any node to access the data.

You can view the node information of the cluster through cluster nodes

127.0.0.1 cluster nodes eb28aaf090ed1b6b05033335e3d90a202b422d6c 7500 slave c1047de2a1b5d5fa4666d554376ca8960895a955 0 1584165266071 5 connected 4cc0463878ae00e5dcf0b36c4345182e021932bc 127.0.0.1 c1047de2a1b5d5fa4666d554376ca8960895a955 7400 slave 5544aa5ff20f14c4c3665476de6e537d76316b4a 0 1584165267074 4 connected dbbb6420d64db22f35a9b6fa460b0878c172a2fb 127.0.0.1cluster nodes eb28aaf090ed1b6b05033335e3d90a202b422d6c 7100 master-01584165266000 1 connected 0-5460 d4b434f5829e73e7e779147e905eea6247ffa5a2 127.0.1 slave dbbb6420d64db22f35a9b6fa460b0878c172a2fb 01584165265000 6 connected 5544aa5ff20f14c4c3665476de6e537d76316b4a 127.0.0.1anger 720000 myself,master-01584165267000 2 connected 5461-10922 c1047de2a1b5d5fa4666d554376ca8960895a955 127.0.0.1Rose 7300 "17300 master-0158416526803 connected 10923-16383

We use kill-9 pid kill process to verify the high availability of the cluster. Re-enter the cluster to execute cluster nodes to see 7200 fail, but 7400 becomes master, restart 7200, and you can see that 7200 has become slave.

3. Advantages and disadvantages of Cluster mode

Advantages:

1. There is no central architecture, and the data is distributed in multiple nodes according to slot.

two。 Each node in the cluster has an equal relationship, and each node stores its own data and the state of the entire cluster. Each node is connected to all other nodes, and these connections remain active, which ensures that we only need to connect to any node in the cluster to get the data of other nodes.

3. Can be extended linearly to more than 1000 nodes, and nodes can be added or deleted dynamically

4. It can realize automatic failover, exchange status information between nodes through gossip protocol, and use voting mechanism to complete the role transition from slave to master.

Disadvantages:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

The implementation of the client is complex, and the driver is required to implement Smart Client, cache slots mapping information and update it in time, which improves the difficulty of development. At present, only JedisCluster is relatively mature, and exception handling is not perfect, such as the common "max redirect exception".

Nodes are judged to be offline for some reason (the blocking time is greater than cluster-node-timeout). This kind of failover is not necessary.

Data is replicated asynchronously, which does not guarantee the strong consistency of the data.

Slave acts as a "cold standby" and cannot relieve the pressure of reading.

Batch operation limit. Currently, only key with the same slott value is supported to perform batch operation. It is not friendly to mset, mget, sunion and other operations.

Key transaction operations support wired, and only support multi-key transaction operations on the same node. Transaction functions cannot be used when multiple key distributes different nodes.

Multiple database spaces are not supported. Stand-alone redis can support 16 db, and only one can be used in cluster mode, that is, db 0

Redis Cluster mode does not recommend the use of pipeline and multi-keys operations to reduce the scenarios generated by max redirect.

This is the end of the answers to the questions about Redis's cluster solutions. I hope the above content can be of some help to you. If you still have a lot of doubts to solve, you can follow the industry information channel for more related knowledge.

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.