Redis主从架构：主从同步和哨兵机制

矫情吗；* 2024-03-25 03:20 40阅读 0赞

#### Redis主从架构：主从同步和哨兵机制 ####

*  一. Redis主从架构
 *  二. 主从同步
 *   *  2.1 引入
     *  2.2 原理
     *   *  (1) 全量同步
         *  (2) 增量同步
         *  (3) 优化Redis主从集群
     *  2.3 总结
 *  三. 哨兵机制
 *   *  3.1 引入
     *  3.2 作用
     *  3.3 原理
     *   *  (1) 状态监控
         *  (2) 选举机制
         *  (3) 故障转移

## 一. Redis主从架构 ##

**引入**：

1.  单个Redis性能有限；
2.  使用主从架构，让读写分离，效率高。

## 二. 主从同步 ##

### 2.1 引入 ###

Redis主从集群采用一个Master负责写，多个Slave负责读的方式（读多写少），那么如何保证集群中多个节点数据的一致性？  
\-------- 将Master数据同步到每个Slave，即主从同步；

**定义**：  
主从同步，是指将一台Redis服务器的数据，复制到其他的Redis服务器。  
数据的复制是单向的，只能由主节点到从节点。  
默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。（redis有主从同步，从从同步）。

### 2.2 原理 ###

#### (1) 全量同步 ####

**触发时间**：①第一次建立连接 ②增量同步失败

**流程**：

1.  当slave和master建立连接后，slave发起psync同步请求，带上`replid`和`offset`；  
    master会根据slave的replid来判断slave是不是第一次同步，ID和自己不一样则是第一次，则将master的replid发给slave，slave记录replid作为自己新的replid；
2.  ①master执行 **`bgsave`**，将内存数据写入RDB文件，并将RDB发送给slave；  
    slave会清空本地数据，加载RDB文件到【内存】中；  
    ②当master异步写RDB文件期间，会记录主进程的操作到repl\_baklog**缓冲区**中；  
    （此时RDB文件+缓冲区的命令即=master上的完整数据）
3.  master将**缓冲区**的新命令发送给slave，slave拿到命令后会执行命令，保证slave和master的数据一致；  
    后序新的命令都写到缓冲区，再发送到slave，以次实现主从同步；  
    ![在这里插入图片描述][2859d9afce604dfdae332369df41f46f.png]

**Replication ID**：  
简称replid，是数据集的标记，id一致则说明是同一数据集。每个master都有唯一一个replid，slave则会继承master节点的replid；

**offset偏移量**：  
随着master记录在【repl\_baklog缓冲区】中的数据增多而逐渐增大。 slave完成同步时也会记录当前的offset；  
如果slave的offset小于master的offset，说明slave落后于master，需要更新；（slave的offset<=master的offset）

所以slave做同步时，必须向master声明自己的Replication ID和offset，master就可以通过ID来判断slave是不是从当前master同步的；以及从offset判断数据同步的进度；

**如何判断slave是不是第一次做数据同步？**  
Replication ID不一样则是slave第一次请求同步！  
而后slave的Replication ID就变成了当前master的Replication ID；master根据slave的 offset ?大小来做增量同步；

#### (2) 增量同步 ####

**触发时间**：在【**slave重启过程中**】，master会持续接收数据，则slave数据会落后，此时就是做增量同步；

**流程**：

1.  slave重启，重启完后向master发起给psync请求同步并带上`replid`和`offset`，  
    由于不是第一次发起请求，此时slave的replid和master一致，master不用再给slave发送id，而是回复`continue`；
2.  master不再bgsave写RDB，因为slave已经拷贝过了，slave宕机期间丢失的部分记录在repl\_baklog**缓冲区**，而slave的offest就是之前读取到的位置，所以将缓存中slave的offset往后的命令发往slave；
3.  slave执行master传过来的命令，就可以补上错过的命令，此时数据保持了一致；  
    ![在这里插入图片描述][7079037e1c3a431f9c686fe4b5942e9a.png]

**repl\_baklog缓冲区**：  
本质是一个成环的数组，当数组满了（slave落后master的数据超过了缓冲区容量），则会用master新命令覆盖旧的命令；  
只要slave和master的数据差距在一个环内，就可以将slave落后于master的部分找到并发给slave；  
当slave和master差距超过了数组容量，则无法做增量同步了，只能做全量同步；  
![在这里插入图片描述][8b5916f1c7964afeb2d3385de14f8d6e.png]

**什么时候增量同步失败？**  
缓冲区是一个数组，大小有限，当slave断开时间太长，和master的差距超过了缓冲区，导致尚未备份的数据被新命令覆盖，则此时无法基于缓冲区做增量同步，只能做**全量同步**了；

#### (3) 优化Redis主从集群 ####

提高全量同步的性能：  
1.在master中配置`无磁盘复制`，避免全量同步时的磁盘IO；不使用RDB文件，即内存数据的IO流直接写到网络中，而不是先写到RDB磁盘文件，减少了一次拷贝到磁盘的过程，提高性能；（网络比较快时）  
2.控制Redis单节点内存上限，这样就能控制RDB文件的大小，从而减少磁盘IO；

减少全量同步：  
3.提高repl\_baklog缓冲区的大小，这样slave落后于master的数据就多一点，一定程度避免由于由于增量同步失效导致的全量同步；

其他：  
4.主从链式结构，限制一个master上的slave节点数量，减轻master的压力；  
![在这里插入图片描述][750e093fdfa0410f8228fde6426dd77c.png]

### 2.3 总结 ###

**1.全量同步与增量同步的区别？**  
全量同步master需要将内存数据写入 **`RDB`** 文件，再将RDB文件传给slave，后序命令记录在缓冲区；  
增量同步时master不需要写RDB文件，只需要将缓冲区中slave的offset之后的命令传给slave；

**2.什么时候执行全量同步？**  
①slave第一次连接master时；  
②slave宕机时间太长，导致salve的offset在缓冲区被新的命令覆盖；

**3.什么时候执行增量同步？**  
slave重启时；

## 三. 哨兵机制 ##

### 3.1 引入 ###

slave宕机后可以找master节点同步数据，但master宕机怎么办？  
master宕机到重启恢复的过程中，master无法进行写操作；

**解决**：  
由哨兵sentinel监控Redis节点，当master宕机，立即让slave充当master；  
宕机的master恢复后则作为slave；

### 3.2 作用 ###

1.  **状态监控**：用心跳监控集群中每个节点的健康状态；
2.  **故障恢复**：如果由master出现故障，则将slave提升为master。故障节点回复以后也以新的master为主；  
    slave故障会将其重启；
3.  **通知客户端**：当【主从发生变换】，Sentinel会将最新消息发送给Redis客户端；  
    ![在这里插入图片描述][c79ef4649eed4320b9dd80fa4371891b.png]

### 3.3 原理 ###

#### (1) 状态监控 ####

Sentinel基于`心跳机制`来检测，每隔1秒向集群的每个实例发送ping命令；

**主观下线**：如果某个sentinel发现某个Redis节点没有在规定时间内响应，则任务该节点主观下线；  
由于是超时未响应，则有可能是因为网络阻塞引起的，所以叫主观下线；

**客观下线**：如果超过指定数量quorum的sentinel都发现该Redis节点主观下线，则该节点是客观下线。  
quorum最好超过sentinel数量的一半；  
![在这里插入图片描述][0c082e3fe5bc4d6593b10fce11b06b9e.png]

#### (2) 选举机制 ####

master客观下线后，需sentinel会在slave中选取一个充当新的master；  
**选举的依据**：  
 判断slave和master节点断开时间的长短，如果超过指定值，则排除slave节点；  
 判断slave节点的slave-priority值（默认一样），越小则级别越高，0则永不参加选举；  
 判断slave的`offset`偏移量，越大越新，优先级越高；  
 如果offset一样，则判断Redis运行id大小，越小优先级越高（id不重要）；

#### (3) 故障转移 ####

1.  Sentinel给**备选的slave节点** 发送 `slave of no one`的命令，让该节点成为新的**master**；
2.  Sentinel会向其他slave发送slaveof 新master命令，让其他slave成为新的master的从节点，从新的master同步数据；
3.  Sentinel将故障节点标记为slave，故障节点恢复后会自动成为master的从节点；  
    ![在这里插入图片描述][131da12a17004ccaa00e34c24aa7e968.png]

[2859d9afce604dfdae332369df41f46f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/d51d9b56498148c8a3fedf9fc411e5d8.png
[7079037e1c3a431f9c686fe4b5942e9a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/0bf81a31e5864b2da106437aeadf52ce.png
[8b5916f1c7964afeb2d3385de14f8d6e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/710ba9e390834f6eaac854531b53c20c.png
[750e093fdfa0410f8228fde6426dd77c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/5bb31d714b1d488b897ad6774ee38231.png
[c79ef4649eed4320b9dd80fa4371891b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/619d4eaf3bdd4a2f88b885861aea8add.png
[0c082e3fe5bc4d6593b10fce11b06b9e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/6cdc55b905404ec0864f0047bfe8d349.png
[131da12a17004ccaa00e34c24aa7e968.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/176919551baa4f14b46ac2575cf27c02.png