Redis主从架构:主从同步和哨兵机制
一. Redis主从架构
引入:
- 单个Redis性能有限;
- 使用主从架构,让读写分离,效率高。
二. 主从同步
2.1 引入
Redis主从集群采用一个Master负责写,多个Slave负责读的方式(读多写少),那么如何保证集群中多个节点数据的一致性?
-------- 将Master数据同步到每个Slave,即主从同步;
定义:
主从同步,是指将一台Redis服务器的数据,复制到其他的Redis服务器。
数据的复制是单向的,只能由主节点到从节点。
默认情况下,每台Redis服务器都是主节点;且一个主节点可以有多个从节点(或没有从节点),但一个从节点只能有一个主节点。(redis有主从同步,从从同步)。
2.2 原理
(1) 全量同步
触发时间:①第一次建立连接 ②增量同步失败
流程:
- 当slave和master建立连接后,slave发起psync同步请求,带上
replid
和offset
;
master会根据slave的replid来判断slave是不是第一次同步,ID和自己不一样则是第一次,则将master的replid发给slave,slave记录replid作为自己新的replid; - ①master执行
bgsave
,将内存数据写入RDB文件,并将RDB发送给slave;
slave会清空本地数据,加载RDB文件到【内存】中;
②当master异步写RDB文件期间,会记录主进程的操作到repl_baklog缓冲区中;
(此时RDB文件+缓冲区的命令即=master上的完整数据) - 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数据会落后,此时就是做增量同步;
流程:
- slave重启,重启完后向master发起给psync请求同步并带上
replid
和offset
,
由于不是第一次发起请求,此时slave的replid和master一致,master不用再给slave发送id,而是回复continue
; - master不再bgsave写RDB,因为slave已经拷贝过了,slave宕机期间丢失的部分记录在repl_baklog缓冲区,而slave的offest就是之前读取到的位置,所以将缓存中slave的offset往后的命令发往slave;
- 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 作用
- 状态监控:用心跳监控集群中每个节点的健康状态;
- 故障恢复:如果由master出现故障,则将slave提升为master。故障节点回复以后也以新的master为主;
slave故障会将其重启; - 通知客户端:当【主从发生变换】,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) 故障转移
- Sentinel给备选的slave节点 发送
slave of no one
的命令,让该节点成为新的master; - Sentinel会向其他slave发送slaveof 新master命令,让其他slave成为新的master的从节点,从新的master同步数据;
- Sentinel将故障节点标记为slave,故障节点恢复后会自动成为master的从节点;