This article brings you relevant knowledge about Redis, which mainly introduces the related issues of master-slave mode, sentinel mode and Redis Cluster mode. I hope it will be helpful to everyone.
Recommended learning: Redis tutorial
Introduction to the redis cluster solution (master-slave mode, sentinel mode, Redis Cluster mode)
There are two main problems in completely storing data in a single redis:
Data backup and performance degradation caused by large data volume.
The master-slave model of Redis provides a better solution to these two problems. The master-slave mode refers to using one redis instance as the host and the remaining instances as backup machines.
The data of the host and the slave are completely consistent. The host supports various operations such as data writing and reading, while the slave only supports synchronization and reading of data with the host. In other words, the client can Write to the host, and the host automatically synchronizes the data writing operation to the slave.
The master-slave mode solves the data backup problem very well, and because the master-slave service data is almost consistent, commands to write data can be sent to the host for execution, while commands to read data can be sent to different slaves. Machine execution, thereby achieving the purpose of separation of reading and writing.
How Master-Slave Replication works:
After the Slave slave node service starts and connects to the Master, it will actively send a SYNC command. After receiving the synchronization command, the Master service master node will start the background save process and collect all received commands for modifying the data set. After the background process is completed, the Master will transfer the entire database file to the Slave to complete a complete synchronization. . The Slave slave node service saves and loads the database file data into memory after receiving it. After that, the Master node continues to transmit all the collected modification commands and new modification commands to the Slaves in sequence. The Slaves will execute these data modification commands this time to achieve final data synchronization.
If the link between Master and Slave is disconnected, Slave can automatically reconnect to Master. After the connection is successful, a full synchronization will be automatically performed. 
Deployment:
redis version:6.0.9
1. Copy 4 copies of the Redis configuration file
and name them master .conf slave1.conf slave2.conf slave3.conf
2. Simple configuration of 4 configuration files
The configuration file of the Master node generally does not require special settings. The default port is 6379
Slave1 node port Set 6380 and configure another row of replicaof 127.0.0.1 6379
Slave2 node port setting 6381 and configure another row of replicaof 127.0.0.1 6379
Slave3 node port setting 6382 configure another 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 master-slave status of the cluster
The advantages and disadvantages of the master-slave mode:
1. Advantages:
The same Master can synchronize multiple Slaves.
The master can automatically synchronize data to the slave, and can separate reading and writing to share the read pressure of the master.
The synchronization between the master and the slave is performed in a non-blocking manner. During the synchronization period, the client can still submit Query or update request
2. Disadvantages:
does not have automatic fault tolerance and recovery functions. The downtime of the 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. Recovery
The master is down. If the data is not synchronized before the downtime, there will be data inconsistencies after switching IP
It is difficult to support online expansion, and the capacity of Redis is limited by the single-machine configuration
In fact, the master of redis The slave mode is very simple and is rarely used in actual production environments. It is not recommended to use the master-slave mode in actual production environments to provide high availability of the system. The reason why it is not recommended is due to its shortcomings. In data The master-slave mode is also unstable when the volume is very large, or when the high availability requirements of the system are high. Although this model is very simple, this model is the basis of other models, so understanding this model will be very helpful for learning other models.
As the name suggests, Sentinel is here to stand guard for the Redis cluster. Once a problem is discovered, it can respond accordingly. Its functions include
Monitoring whether the master and slave are running normally
When the master fails, it can automatically convert a slave to the master (the elder brother is dead, choose a younger brother to take over)
Multiple sentries can monitor the same Redis and sentinels will also be automatically monitored
After automatically discovering the slave and other sentinel nodes, the sentinel can regularly monitor whether these databases and nodes have stopped services by sending PING commands regularly.
If the database or node being PING times out (configured through sentinel down-after-milliseconds master-name milliseconds) and does not reply, Sentinel considers it to be subjectively offline (sdown, s means Subjectively - subjectively). If the master is offline, the sentinel will send a command to other sentinels to ask them whether they also think that the master is subjectively offline. If a certain number (that is, the quorum in the configuration file) of votes is reached, the sentinel will consider that the master has been objectively offline (odown). , o is Objectively - objectively), and elects the leading sentinel node to initiate failure recovery for the master-slave system. If there are not enough sentinel processes to agree to the master's offline status, the master's objective offline status will be removed. If the master returns a valid reply to the PING command sent to the sentinel process again, the master's subjective offline status will be removed.
Sentinel believes that after the master is objectively offline, the fault recovery operation needs to be performed by the elected leader sentinel.
After the leader is elected, the leader begins to perform fault recovery on the system, starting from the failed master Select one from the database to elect the new master,
After selecting the slave that needs to be succeeded, the leading sentinel sends a command to the database to upgrade it to master, then sends a command to other slaves to accept the new master, and finally updates data. Update the stopped old master to the slave database of the new master, so that it can continue to run as a slave after the service is restored. 
The sentinel mode is based on the previous master-slave replication mode. The sentinel configuration file is sentinel.conf. Add the following configuration in the corresponding directory. Be careful not to conflict with the ports:
port 26379 protected-mode no daemonize yes pidfile "/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 ##指定主机IP地址和端口，并且指定当有2台哨兵认为主机挂了，则对主机进行容灾切换 #sentinel auth-pass mymaster pwdtest@2019 ##当在Redis实例中开启了requirepass，这里就需要提供密码 sentinel down-after-milliseconds mymaster 3000 ##这里设置了主机多少秒无响应，则认为挂了 sentinel failover-timeout mymaster 180000 ##故障转移的超时时间，这里设置为三分钟
The format is as follows:
View the sentinel status ：
The client is directly connected to the redis node. The client does not need to connect to all nodes in the cluster. It can connect to any available node in the cluster.
On each node of Redis, There is a slot (slot), the value range is 0-16383, a total of 16384 slots
When we access the key, Redis will obtain a result based on the CRC16 algorithm, and then calculate the remainder of the result to 16384 , so that each key will correspond to a hash slot numbered between 0-16383. Use this value to find the node corresponding to the corresponding slot, and then automatically jump to the corresponding node for access operations. .
In order to increase the accessibility of the cluster, the officially recommended solution is to configure the node into a master-slave structure, that is, a master node and n slave nodes. At this time, if the master node fails, Redis Cluster will select one of the slave nodes to be promoted to the master node based on the election algorithm, and the entire cluster will continue to provide services to the outside world. Redis Cluster itself provides failover fault tolerance.
According to the cluster election mechanism and the implementation of master-slave backup, redis requires at least three masters and three slaves in total to form a redis cluster. The test environment can start 6 nodes on one physical machine. redis nodes, but at least 2 to 3 physical machines must be prepared for the production environment. (Three virtual machines are used here)
该模式就支持动态扩容，可以在线增加或删除节点，而且客户端可以连接任何一个主节点进行读写，不过此时的从节点仅仅只是备份的作用。至于为何能做到动态扩容，主要是因为Redis集群没有使用一致性hash,而是使用的哈希槽。Redis集群会有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，而集群的每个节点负责一部分hash槽。
那么这样就很容易添加或者删除节点， 比如如果我想新添加个新节点， 我只需要从已有的节点中的部分槽到过来；如果我想移除某个节点，就只需要将该节点的槽移到其它节点上，然后将没有任何槽的A节点从集群中移除即可。由于从一个节点将哈希槽移动到另一个节点并不会停止服务，所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态。
需要注意的是，该模式下不支持同时处理多个key（如MSET/MGET），因为redis需要把key均匀分布在各个节点上，并发量很高的情况下同时创建key-value会降低性能并导致不可预测的行为。
搭建集群
这里就直接搭建较为复杂的Cluster模式集群，也是企业级开发过程中使用最多的。
最终目录结构如下
以 9001 的为例子，其余五个类似。
编辑 /data/redis-cluster/9001/redis.conf
redis.conf修改如下:
port 9001（每个节点的端口号） daemonize yes appendonly yes //开启aof bind 0.0.0.0（绑定当前机器 IP） dir "/data/redis-cluster/9001"（数据文件存放位置,,自己加到最后一行 快捷键 shift+g） pidfile /var/run/redis_9001.pid（pid 9001和port要对应） logfile "/data/redis-cluster/logs/9001.log" cluster-enabled yes（启动集群模式） cluster-config-file nodes9001.conf（9001和port要对应） cluster-node-timeout 15000
/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
现在检查一下是否成功开启，如下图所示，都开启成功。
ps -el | grep redis
此时的节点虽然都启动成功了，但他们还不在一个集群里面，不能互相发现，测试会报错：(error) CLUSTERDOWN Hash slot not served。
如下图所示
redis-cli --cluster create 10.32.176.80:9001 10.32.176.80:9002 10.32.176.80:9003 10.32.176.80:9004 10.32.176.80:9005 10.32.176.80:9006 --cluster-replicas 1
–cluster-replicas 1 这个指的是从机的数量，表示我们希望为集群中的每个主节点创建一个从节点。
红色选框是给三个主节点分配的共16384个槽点。
黄色选框是主从节点的分配情况。
蓝色选框是各个节点的详情。
现在通过客户端命令连接上，通过集群命令看一下状态和节点信息等
/data/redis-cluster/bin/redis-cli -c -h 10.32.176.80 -p 9001 cluster info cluster nodes
效果图如下，集群搭建成功。
现在往9001这个主节点写入一条信息，我们可以在9002这个主节点取到信息，集群间各个节点可以通信。
故障转移机制详解
集群中的节点会向其它节点发送PING消息（该PING消息会带着当前集群和节点的信息），如果在规定时间内，没有收到对应的PONG消息，就把此节点标记为疑似下线。当被分配了slot槽位的主节点中有超过一半的节点都认为此节点疑似下线（就是其它节点以更高的频次，更频繁的与该节点PING-PONG），那么该节点就真的下线。其它节点收到某节点已经下线的广播后，把自己内部的集群维护信息也修改为该节点已事实下线。
节点资格审查：然后对从节点进行资格审查，每个从节点检查最后与主节点的断线时间，如果该值超过配置文件的设置，那么取消该从节点的资格。准备选举时间：这里使用了延迟触发机制，主要是给那些延迟低的更高的优先级，延迟低的让它提前参与被选举，延迟高的让它靠后参与被选举。（延迟的高低是依据之前与主节点的最后断线时间确定的）
Election voting: When the slave node obtains the election qualification, it will initiate an election request to other master nodes with slots, and they will vote. The higher the priority slave node, the more likely it is to become the master node. When 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, then as long as one slave node obtains N/2 1 votes, it is considered the winner), it will be replaced as the master node.
Replace the master node: The elected slave node will execute slaveof no one to change its status from slave to master, then execute the clusterDelSlot operation to cancel the slots responsible for the failed master node, and execute clusterAddSlot to allocate these slots to itself, and then broadcast its own pong message to the cluster to notify all nodes in the cluster that the current slave node has become the master node.
Takeover related operations: The new master node takes over the slot information of the previously failed master node, receives and processes command requests related to its own slot.
Failover test
This is the situation of specific nodes in the previous cluster. I have simplified it as follows. You can look back at the cluster information in the picture.
Close the process of the 9001 port here, which is to simulate that the master node hangs up.
If you log in to a dead redis node, you will be denied service. Enter through a master node that is still running normally, and then check the information in the cluster again
In short, the previous cluster information has become as follows
Now, I restart the master node that just hung up, Recheck the node situation within the cluster. The specific situation is as shown in the figure below
In short, the current node situation in the cluster is as follows
Recommended learning: Redis tutorial
The above is the detailed content of In-depth understanding of redis cluster solutions (master-slave mode, sentinel mode, Redis Cluster mode). For more information, please follow other related articles on the PHP Chinese website!