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，以次实现主从同步；
   

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传过来的命令，就可以补上错过的命令，此时数据保持了一致；
   

repl_baklog缓冲区：
本质是一个成环的数组，当数组满了（slave落后master的数据超过了缓冲区容量），则会用master新命令覆盖旧的命令；
只要slave和master的数据差距在一个环内，就可以将slave落后于master的部分找到并发给slave；
当slave和master差距超过了数组容量，则无法做增量同步了，只能做全量同步；

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

(3) 优化Redis主从集群

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

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

其他：
4.主从链式结构，限制一个master上的slave节点数量，减轻master的压力；

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客户端；
   

3.3 原理

(1) 状态监控

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

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

客观下线：如果超过指定数量quorum的sentinel都发现该Redis节点主观下线，则该节点是客观下线。
quorum最好超过sentinel数量的一半；

(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的从节点；