Redis large-scale strategy master-slave replication, sentinel mode, cluster mode (theoretical detailed explanation + construction steps)


Preface

Master-slave replication:

  • Master-slave replication is the basis of high-availability Redis. Sentinel and clusters are all based on master-slave replication to achieve high availability.
  • Master-slave replication mainly implements multi-machine backup of data, as well as load balancing for read operations and simple failure recovery
  • The disadvantage is that failure recovery cannot be automated, write operations cannot be load balanced, and storage capacity is limited by a single machine

sentinel:

  • On the basis of master-slave replication, Sentinel realizes automatic failure recovery
  • The disadvantage is that the write operation cannot be load balanced, and the storage capacity is limited by a single machine
  • And the sentinel cannot automatically failover the slave node. In the read-write separation scenario, the failure of the slave node will cause the read service to be unavailable, requiring additional monitoring and switching operations on the slave node

Cluster:

  • Through clustering, Redis solves the problem that write operations cannot be load balanced, and storage capacity is limited by a single machine
  • A relatively complete high-availability solution has been realized

1. Redis master-slave replication

1 Overview

  • Master-slave replication refers to copying the data of one Redis server to other Redis servers, the former is called the master node (Master), and the latter is called the slave node (Slave)
  • Data replication is one-way, only from the master node to the slave node
  • By default, each Redis server is the master node, and a master node can have multiple slave nodes (or no slave nodes), but a slave node can only have one master node

2. Function

Data redundancy:

  • Master-slave replication realizes hot backup of data
  • It is a data redundancy method other than persistence

Recovery:

  • When the master node has a problem, the slave node can provide services to achieve fast failure recovery
  • Is actually a kind of service redundancy

Load balancing:

  • On the basis of master-slave replication, with the separation of read and write, the master node can provide the write service, and the slave node can provide the read service (that is, the application connects to the master node when writing Redis data, and the application connects to the slave node when real Redis data), sharing the server load
  • Especially in the scenario of writing less and reading more, sharing the read load by multiple slave nodes can greatly increase
    the concurrency of the Redis server

The cornerstone of high availability:

  • In addition to the above functions, master-slave replication is also the basis for the implementation of sentinels and clusters
  • Therefore, master-slave replication is the basis of Redis high availability

3. Process

  1. If a slave machine process is started, it will send a "sync command" command to the Master machine to request a synchronous connection
  2. Whether it is the first connection or reconnection, the Master machine will start a background process to save the data snapshot to the data file (execute the RDB operation), and the Master will also record all the commands to modify the data and cache them in the data file
  3. After the background process completes the caching operation, the Master machine will send the data file to the Slave machine, and the Slave machine will save the data file to the hard disk, and then load it into the memory, and then the Master machine will combine all the operations that modify the data. Sent to the slave machine; if the slave fails and it goes down, it will automatically reconnect after returning to normal
  4. After the Master machine receives the connection from the Slave side machine, it sends its complete data file to the Slave side machine. If Mater receives synchronization requests from multiple slaves at the same time, the Master will start a process in the background to save the data file. Then send it to all slave-side machines to ensure that all slave-side machines are normal
    mark

Three, build Redis master-slave replication

Host CPU name operating system IP address Main software
Master CentOS 7-1 CentOS 7 192.168.126.11 squid-3.5.28.tar.gz
Slave1 CentOS 7-2 CentOS 7 192.168.126.12 squid-3.5.28.tar.gz
Slave2 CentOS 7-3 CentOS 7 192.168.126.13 squid-3.5.28.tar.gz

1. Install Redis

  • All three hosts need to install Redis
  • Download the software package portal : redis-5.0.7.tar.gz (extract code: qwer)
systemctl stop firewalld
systemctl disable firewalld
setenforce 0

yum -y install gcc gcc-c++ make

cd /opt
#将软件包传至该目录下
tar zxvf redis-5.0.7.tar.gz -C /opt/

cd redis-5.0.7/
make -j 4 && make PREFIX=/usr/local/redis install

cd /opt/redis-5.0.7/utils/
./install_server.sh
#回车,直到出现以下选项,手动修改为“/usr/local/redis/bin/redis-server”
Please select the redis executable path [/usr/local/bin/redis-server] /usr/local/redis/bin/redis-server

ln -s /usr/local/redis/bin/* /usr/local/bin/

netstat -natp | grep "redis"
#当 install_server.sh 脚本运行完毕,Redis 服务就已经启动,默认侦听端口为 6379

2. Modify the Redis configuration file

Master:

vim /etc/redis/6379.conf
bind 0.0.0.0                        #70行,注释掉 bind 项,默认监听所有网卡
daemonize yes                       #137行,开启守护进程
logfile /var/1og/redis_ 6379.1og    #172行,指定日志文件目录
dir /var/lib/redis/6379             #264行,指定工作目录
appendonly yes                      #700行,开启 AOF 持久化功能

Slave:

vim /etc/redis/6379. conf
bind 0.0.0.0                        #70行,修改监听地址为 0.0.0.0
daemonize yes                       #137行,开启守护进程
logfile /var/log/redis_ 6379. log   #172行,指定日志文件目录
dir /var/lib/redis/6379             #264行,指定工作目录
replicaof 192.168.126.11 6379       #288行,指定要同步的 Master 节点 IP 和端口
appendonly yes                      #700行,开启 AOF 持久化功能


/etc/init.d/redis_6379 restart
#重启服务使配置生效

3. Verify the master-slave effect

Look at the log on the Master:

tail -f /var/log/redis_6379.log

mark

Verify the slave node on the Master:

redis-cli info replication

mark

  • And at this time, only in the Master

Three, Redis sentinel mode

The core function of Sentinel is based on master-slave replication, Sentinel introduces automatic failover of the master node

1. Principle and function

The principle of sentinel mode:

  • Sentinel is a distributed system used to monitor each server in the master-slave structure. When a failure occurs, a new Master is selected through a voting mechanism and all slaves are connected to the new Master.
  • The number of the entire cluster running sentinels must not be less than 3 nodes

The role of sentinel mode:

  • Monitoring: The sentinel will constantly check whether the master node and slave node are operating normally
  • Automatic failover: When the master node fails to work normally, the sentinel will start an automatic failover operation. It will upgrade one of the slave nodes of the failed master node to the new master node, and make other slave nodes copy the new master node
  • Notification (reminder): The sentinel can send the result of the failover to the client

2. Structure composition

The sentinel structure consists of two parts, sentinel node and data node:

  • Sentinel node: The sentinel system consists of one or more sentinel nodes. The sentinel node is a special redis node and does not store data
  • Data node: both the master node and the slave node are data nodes
    mark

3. Work process

  • The startup of the sentinel depends on the master-slave mode, so you must install the master-slave mode before going to the sentinel mode. All nodes need to deploy the sentinel mode. The sentinel mode will monitor whether all Redis working nodes are normal.
  • When there is a problem with the Master, because other nodes lose contact with the master node, they will vote. More than half of the vote is considered that the Master does have a problem, and then the sentry will be notified that a sentry will be selected to perform the failover work (by the sentry) Specify which slave to be the new master), and then select one from the slaves as the new master
  • The screening method is that sentinels send messages to each other and participate in voting, and the one with more votes is elected
    mark
  • It is important to note that objective offline is a concept that only the master node has. That is, if the slave node and the sentinel node fail, after the sentinel is subjectively offline, there will be no subsequent objective offline and failover operations (and Sentinel mode is only responsible for the aspects of the Master, regardless of Slaves)
    • When a sentinel finds that the master server is down, it will change the master in SentinelRedistance in the master to SRI_S_DOWN (subjectively offline), and notify other sentinels to tell them that the master is down
    • After receiving the information sent by the sentry, other sentries will also try to connect to the master. If more than half (set in the configuration file) confirm that the master is down, the master in the SentinelRedistance in the master will be changed to SRI_O_DOWN (objectively) line)
      mark

4. Build Redis sentry mode

4.1 Modify the configuration file of Redis sentry mode

vim /opt/redis-5.0.7/sentinel.conf

protected- mode no                              #17行,关闭保护模式
port 26379                                      #21行,Redis哨兵默认的监听端口
daemonize yes                                   #26行,指定sentinel为后台启动
logfile "/var/log/sentinel.log"                 #36行,指定日志存放路径
dir "/var/lib/redis/6379"                       #65行,指定数据库存放路径

sentinel monitor mymaster 192.168.126.11 6379 2
#84行,修改,指定该哨兵节点监控 192.168.126.11:6379 这个主节点,该主节点的名称是 mymaster
#最后的 2 的含义与主节点的故障判定有关:至少需要 2 个哨兵节点同意,才能判定主节点故障并进行故障转移

sentinel down-after -milliseconds mymaster 30000#113行,判定服务器 down 掉的时间周期,默认 30000毫秒 (30秒)
sentinel failover-timeout mymaster 180000       #146行,故障节点的最大超时时间为 180000 (180秒)

4.2 Start Sentry Mode

Start the Master first, then start the Slave

cd /opt/redis-5.0.7/
redis-sentinel sentinel.conf &

mark
mark
mark

4.3 View sentinel information

redis-cli -p 26379 info Sentinel

mark
mark
mark

4.4 Simulate failure

ps -ef | grep "redis"
#查看 redis-server 的进程号

kill -9 [进程号]
#杀死 Master 节点上的 redis-server 的进程号

mark

4.5 Verification result

tail /var/log/sentinel.log

mark

redis-cli -p 26379 info Sentinel

mark
mark
mark


Four, Redis cluster mode

1 Overview

  • Cluster, namely Redis Cluster, is a distributed storage solution introduced by Redis 3.0
  • The cluster is composed of multiple nodes (Node), and Redis data is distributed among these nodes.
  • The nodes in the cluster are divided into master nodes and slave nodes: only the master node is responsible for the maintenance of read and write requests and cluster information, and the slave nodes only replicate the data and status information of the master node.

2. Function

2.1 Data partition

  • Data partitioning (or data sharding) is the core function of the cluster
  • The cluster disperses data to multiple nodes. On the one hand, it breaks through the limitation of Redis single machine memory size and greatly increases the storage capacity. On the other hand, each master node can provide external read and write services, which greatly improves the responsiveness of the cluster.
  • Redis stand-alone memory size limitation problem, mentioned in the introduction of persistence and master-slave replication
  • For example, if the memory of a single machine is too large, the fork operation of bgsave and bgrewriteaof may cause the master process to be blocked, and the slave node may not be able to provide services for a long time when the master is switched in the master-slave environment, and the replication buffer of the master node may overflow during the full replication phase

2.2 High availability

  • The cluster supports master-slave replication and automatic failover of the master node (similar to sentinel). When any node fails, the cluster can still provide external services

2.2.1 Data Sharding of Redis Cluster

  • The Redis cluster introduces the concept of hash slots, with 16384 hash slots (numbered 0~16383)
  • Each node in the cluster is responsible for a part of the hash slot. After each Key is checked by CRC16, the remainder is 16384 to determine which hash slot to place, and this value is used to find the node corresponding to the corresponding slot, and then directly jump automatically Go to the corresponding node for access operations
  • Take a cluster composed of 3 nodes as an example:
    • Node A contains hash slots 0~5469
    • Node B contains hash slots 5461~10922
    • Node C contains hash slots 10923-16383

mark

2.2.2 Master-slave replication model of Redis cluster

  • The cluster has three nodes A, B, and C. If node B fails, the entire cluster will be unavailable due to lack of slots in the range of 5461~10922
  • Add a slave node (a, b, c) for each node, that is, the entire cluster has three Master nodes and three slave nodes. After node B fails, the cluster elects b to continue serving as the master node. When B and b After all failures, the entire cluster will be unavailable

Five, build Redis cluster mode

1. Prepare

  • A redis cluster generally requires 6 nodes (3 masters and 3 slaves)
  • For convenience, all nodes here are simulated on the same server, distinguished by port numbers: the port numbers of the three master nodes are 6001/6002/6003, and the corresponding slave node port numbers are 6004/6005/6006
cd /etc/redis/
mkdir -P redis-cluster/redis600{
    
    1..6)
#

for i in {
    
    1..6}
do
cp /opt/redis-5.0.7/redis.conf /etc/redis/redis-cluster/redis600$i
cp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis600$i
done

ls -R

2 Turn on the cluster function

#其他五个文件夹的配置文件以此类推修改,注意六个端口都不一样

cd /etc/redis/redis-cluster/redis6001

vim redis. conf
#bind 127.0.0.1                             #69行,注释掉 bind 项,默认监听所有网卡
protected-mode no                           #88行,修改,关闭保护模式
port 6001                                   #92行,修改,redis 监听端口,
daemonize yes                               #136行,开启守护进程,以独立进程启动
appendonly yes                              #699行,修改,开启 AOF 持久化
cluster-enabled yes                         #832行,取消注释,开启群集功能
cluster-config-file nodes-6001.conf         #840行,取消注释,群集名称文件设置
cluster-node-t imeout 15000                 #846行,取消注释群集超时时间设置

3. Start the redis node

#分别进入那六个文件夹,执行命令"redis-server redis.conf"来启动 redis 节点

cd /etc/redis/redis-cluster/redis6001
redis-server redis.conf

for i in {
    
    1..6}
do
cd /etc/redis/redis-cluster/redis600$i
redis-server redis.conf
done

ps -ef | grep "redis"

mark

4. Start the cluster

redis-cli --cluster create 127.0.0.1:6001 127.0.0.1:6002 127.0.0.1:6003 127.0.0.1:6004 127.0.0.1:6005 127.0.0.1:6006 --cluster-replicas 1

#六个实例分为三组,每组一主一从,前面的做主节点,后面的做从节点
#下面交互的时候需要输入 yes 才可以创建
#-replicas 1 表示每个主节点有一个从节点

5. Test the cluster

redis-cli -p 6001 -c
#加 -c 参数,节点之间就可以互相跳转

127.0.0.1:6001> CLUSTER SLOTS
#查看节点的哈希槽编号范围

mark

127.0.0.1:6001> set name wanger
-> Redirected to slot [5798] located at 127.0.0.1:6002
OK
#新建一个键的值

127.0.0.1:6002> CLUSTER KEYSLOT name
(integer) 5798
#查看 name 键的槽编号

ctrl+c 
#退出

redis-cli -p 6001 -c
127.0.0.1:6001> KEYS *
(empty list or set)
127.0.0.1:6001> 

ctrl+c

redis-cli -p 6005 -c
127.0.0.1:6005> KEYS *
1) "name"

#可以发现,对应的 slave 节点也有这条数据,但是别的节点没有

Guess you like

Origin blog.csdn.net/weixin_51486343/article/details/114094038