Redis集群的主从复制原理-全量复制和增量复制-哨兵机制

Redis集群的主从复制原理-全量复制和增量复制-哨兵机制

作用

• 数据备份

这一点直观,因为现在有很多节点,每个节点都保存了原始数据的备份.

• 读写分离

这一点主要是当发生读写的时候，读数据的操作大部分都会进入到从节点，而写数据的操作都会进入到主节点，之后主节点将数据修改的部分同步到从节点，这样就降低了主节点的压力。

知识

• run id 每一个节点都会有一个id
• offset 偏移量，主节点和从节点通过偏移量确定当前进行了多少数据的复制，以及下一次应该从哪一个位置进行开始。

全量复制

1. 首先从节点发起全量复制，但是从节点不知道主节点的runid，会发送一个？，偏移量使用1进行表示，发送psync指令 runid = ？ offset = 1。
2. 主节点收到请求，发现runid是1，说明这一次是全量复制，后fork一个后台进程，然后执行bgsave命令，将主节点的数据全部生成一个RDB文件。
3. RDB文件完毕之后，发送给从节点，从节点首先将本地数据全部请求，然后将RDB文件加载到内存中。
4. 在主节点生成RDB文件的过程中，如果这时候来了写进程，主节点会将所有数据都写入到缓存中，当从节点加载完成之后，再将这个缓存文件发送给从节点，如此实现了主从一致性。

增量复制

1. 重新建立连接之后，从节点发送psync指令，runid = 1 offset = 600。
2. 主节点收到这个psync指令，如果发现这个runid并不是自己的runid，就会直接进行全量复制。这是因为从节点原来的主节点和现在的主节点是不相同的。
3. 主节点会将新写入的文件放入到一个环形缓冲区，如果发现从节点发送的offset在环形缓冲区中，那么就继续宁增量复制，否则直接进行全量复制。
4. 将offset往后一直到环形队列底部的数据，全部同步给从节点。

主从复制存在的问题

Redis主从复制模式下，一旦主节点宕机不能提供服务，需要人工讲从节点晋升为主节点，同时还需要通知应用方更新主节点地址，对于很多应用场景这种故障的处理方式不可接受。而且，如果客户端发送的都是读操作请求，那还可以由从库继续提供服务，这在纯读的业务场景下还能被接受。但是，一旦有写操作请求了，按照主从库模式下的读写分离要求，需要由主库来完成写操作。此时，也没有实例可以来服务客户端的写操作请求了。 所以就需要一个模式来自动感知主库的状态并可以进行自动化切换，此时哨兵模式就应运而生了。

哨兵机制的流程

哨兵其实就是一个运行在特殊模式下的 Redis 进程，主从库实例运行的同时，它也在运行。哨兵主要负责的就是三个任务：监控、选主（选择主库）和通知。

1. 我们先看监控。监控是指哨兵进程在运行时，周期性地给所有的主从库发送 PING 命令，检测它们是否仍然在线运行。如果从库没有在规定时间内响应哨兵的 PING 命令，哨兵就会把它标记为“下线状态”；同样，如果主库也没有在规定时间内响应哨兵的 PING 命令，哨兵就会判定主库下线，然后开始自动切换主库的流程
2. 这个流程首先是执行哨兵的第二个任务，选主。主库挂了以后，哨兵就需要从很多个从库里，按照一定的规则选择一个从库实例，把它作为新的主库。这一步完成后，现在的集群里就有了新主库。
3. 然后，哨兵会执行最后一个任务：通知。在执行通知任务时，哨兵会把新主库的连接信息发给其他从库，让它们执行 replicaof 命令，和新主库建立连接，并进行数据复制。同时，哨兵会把新主库的连接信息通知给客户端，让它们把请求操作发到新主库上。

问题： 哨兵如何判断主库下线？
主观下线：哨兵进程会使用 PING 命令检测它自己和主、从库的网络连接情况，用来判断实例的状态。如果哨兵发现主库或从库对 PING 命令的响应超时了，那么，哨兵就会先把它标记为“主观下线”。
客观下线：由于哨兵都是集群部署，所以只有当大部分哨兵都判断为“主观下线”的情况才会将其标记为“客观下线”
简单来说，“客观下线”的标准就是，当有 N 个哨兵实例时，最好要有 N/2 + 1 个实例判断主库为“主观下线”，才能最终判定主库为“客观下线”。这样一来，就可以减少误判的概率，也能避免误判带来的无谓的主从库切换。（当然，有多少个实例做出“主观下线”的判断才可以，可以由 Redis 管理员自行设定）。

问题： 如何选择新主库？
第一轮：优先级最高的从库得分高。
用户可以通过 slave-priority 配置项，给不同的从库设置不同优先级。比如，你有两个从库，它们的内存大小不一样，你可以手动给内存大的实例设置一个高优先级。在选主时，哨兵会给优先级高的从库打高分，如果有一个从库优先级最高，那么它就是新主库了。如果从库的优先级都一样，那么哨兵开始第二轮打分。

第二轮：和旧主库同步程度最接近的从库得分高。
就是说为去判断从库的偏移量offset。主库会用 master_repl_offset 记录当前的最新写操作在 repl_backlog_buffer 中的位置，而从库会用 slave_repl_offset 这个值记录当前的复制进度，slave_repl_offset越接近master_repl_offset的数据也就越新，就会被选择成为主库。

第三轮：ID 号小的从库得分高。
每个实例都会有一个 ID，这个 ID 就类似于这里的从库的编号。目前，Redis 在选主库时，有一个默认的规定：在优先级和复制进度都相同的情况下，ID 号最小的从库得分最高，会被选为新主库。这个也比较好理解，ID越小代表着从库加入的时间越早，在同分的情况下代表着运行时间越久，也就说在一定程度上更加稳定。