Redis集群主从复制原理

1.主从模式

 内容来自：Redis的主从复制原理-腾讯云开发者社区-腾讯云

一主一从，一主多从，一般主节点提供读写功能，从节点提供只读功能。

1.1 主节点挂掉

如果主节点挂掉，那么从节点依旧可以提供读的功能，但不能提供写的功能。

需要在从节点上手动执行命令：slaveof no one  ，这样该从节点就可以上升为主节点了。

1.2 从节点挂掉

1.2.1 增量复制

从节点启动之后，会向主节点发出PSYNC命令，支持全量同步和部分同步。

1）主服务器的复制偏移量

在复制过程中，主从服务器都会分别维护一个复制偏移量

主服务器每次向从服务器传播N个字节的数据时，就会将自己的复制偏移量的值加上N；

2）从服务器的复制偏移量

·从服务器每次收到主服务器传播来的N个字节的数据时，就将自己的复制偏移量的值加上N。

3）主服务器的复制积压缓冲区

复制积压缓冲区是由主服务器维护的一个固定长度先进先出队列，默认大小为1MB。当主服务器进行命令传播时，它不仅会将写命令发送给所有从服务器，还会将写命令入队到复制积压缓冲区里。复制缓冲区里保存着一部分最近传播的写命令，并且复制积压缓冲区会为队列中的每个字节记录相应的复制偏移量，大致如下图所示：

当从服务器重新连上主服务器时，从服务器会通过psync命令将自己的复制偏移量发送给主服务器，主服务器会根据这个复制偏移量来决定对从服务器执行何种同步操作： ·如果偏移量之后的数据(也即是偏移量offset+1开始的数据)仍然存在于复制积压缓冲区里面，那么服务器将对从服务器执行部分重同步操作； ·相反，如果偏移量之后的数据已经不存在于复制积压缓冲区，那么主服务器将对从服务器执行完整重同步操作。 所以，复制积压缓冲区的大小似乎相当重要，正确估算和设置复制积压缓冲区的大小非常重要。

4）服务器的运行ID

除了复制偏移量和复制积压缓冲队列，实现重同步还需要服务器运行ID(run ID)。每个redis服务器，不论主服务器还是从服务器都有自己的运行ID，运行ID在服务器启动时自动生成，由40个随机的十六进制字符组成。 当从服务器对主服务器进行初次复制时，主服务器会将自己的运行ID传送给从服务器。当从服务器断线并重新连上一个主服务器时，从服务器将向当前连接的主服务器发送之前保存的运行ID： ·如果从服务器保存的ID和当前连接的主服务器的运行ID相同，那么说明从服务器断线之前复制的就是当前连接的这个主服务器，主服务器可以尝试执行部分重同步操作； ·如果从服务器保存的ID和当前连接的主服务器的运行ID不同，则从服务器断线之前复制的不是当前连接的这个主服务器，主服务器就将对从服务器执行完整重同步操作。

5）PSYNC命令的具体实现

PSYNC命令的调用方法有两种： ·如果从服务器以前没有复制过任何主服务器，或者之前执行过slaveof no one命令，那么从服务器在开始一次新的复制时将向主服务器发送PSYNC ? -1命令，主动请求主服务器进行完整重同步(因为这时不可能执行部分重同步)； ·如果从服务器之前已复制过某个主服务器，那么从服务器在开始一次新的复制时将向主服务器发送PSYNC 命令。runid是上一次复制的主服务器ID，而offset则是从服务器当前的复制偏移量。接收到该命令的主服务器通过这两个参数来判断执行何种同步操作。 根据情况，接收到PSYNC命令的主服务器会向从服务器返回以下三种回复之一： ·主服务器返回：+FULLRESYNC 。那么表示主服务器将与从服务器执行完整重同步操作，runid是这个主服务器的运行ID，从服务器会将这个ID保存下来，在下次发送PSYNC命令时使用；而offset则是主服务器当前的偏移量，从服务器会将这个值作为自己的初始化偏移量。 ·主服务器返回：+CONTINUE。那么表示主服务器将与从服务器执行部分重同步操作，从服务器只要等着主服务器将自己缺少的那部分数据发送过来即可。 ·主服务器返回：-ERR。表示主服务器版本低于2.8，它识别不了PSYNC命令。之后从服务器将发送sync命令，与主服务器执行完整重同步操作。

注意：如果是从库宕机了，那么恢复后直接就是完全同步；如果仅是主从掉线，从库还在线，那么则视情况而定。

1.2.2 全量复制

如果偏移量之后的数据已经不存在于复制积压缓冲区，那么主服务器将对从服务器执行完整重同步操作。

主从复制的基本步骤如下：

1）从服务器连接到主服务器，发送PSYNC命令。2.8之前的版本发送SYNC，之后的版本发送PSYNC

2）主服务器接收到PSYNC命令后，开始执行BGSAVE命令生成RDB文件。

3）主服务器BGSAVE执行完毕后，将RDB文件发送给从服务器。

4）从服务器收到RDB文件后，载入数据。

5）主服务器在生成RDB期间的命令会保存在缓冲区中，同时也会将新的写操作也发送给从服务器。

2.哨兵模式

Redis Sentinel 原理

2.1.选择主sentinel过程（基于Raft算法选举领头sentinel）
1）判断客观下线的sentinel节点向其他sentinel节点发送 SENTINEL is-master-down-by-addr ip port current_epoch runid
2）目标sentinel回复是否同意master下线并选举领头sentinel，选择领头sentinel的过程符合先到先得的原则。
3）当sentinel发现选自己的节点个数超过majority的个数的时候，自己就是领头节点
4）如果没有一个sentinel达到了majority的数量，等一段时间，重新选举

2.2 判断master下线
1）每个 Sentinel 哨兵节点每隔1s向所有的master、slave以及其他 Sentinel 节点发送一个PING命令，作用是通过心跳检测，检测主从服务器的网络连接状态
2）如果 master 节点回复 PING 命令的时间超过 down-after-milliseconds 设定的阈值（默认30s），则这个master会被sentinel标记为主观下线，修改其flags状态为SRI_S_DOWN
3）当sentinel 哨兵节点将master标记为主观下线后，会向其余所有的sentinel发送sentinel is-master-down-by-addr消息，询问其他sentinel是否同意该master下线
4）每个sentinel收到命令之后，会根据发送过来的ip和port检查自己判断的结果，回复自己是否认为该master节点已经下线了
5）sentinel收到回复之后，如果同意master节点进入主观下线的sentinel数量大于等于quorum，则master会被标记为客观下线，即认为该节点已经不可用。quorum：哨兵集群中多少个sentinel认为master失效才下判定为客观下线，一般配置节点数/2+1，也就是说大于半数。

2.3.选择master过程
1）选择优先级最高的节点，通过sentinel配置文件中的replica-priority配置项，这个参数越小，表示优先级越高
2）如果第一步中的优先级相同，选择offset最大的，offset表示主节点向从节点同步数据的偏移量，越大表示同步的数据越多
3）如果第二部offset也相同，选择runid较小的，runid越小说明启动时间越早
4）领头sentinel会对选出来的从节点执行slaveof no one 命令让其成为主节点
5）领头sentinel 向别的slaveof发送命令，告诉他们新的master是哪个，让这些节点向这个master复制数据
6）如果之前的master重新上线时，领头sentinel同样会发起slaveof命令，将其变成从节点

3.Redis Cluster模式

3.1.master故障发现
1）采用 Gossip 协议来广播自己的状态以及自己对整个集群认知的改变

2）集群中每个节点都会定期向其他节点发送ping消息，接收节点回复pong消息作为响应

3）如果在cluster-node-timeout时间内通信一直失败，则发送节点会认为接收节点存在故障，把接收节点标记为主观下线(PFail)状态

4）当半数以上持有槽的主节点都标记某个节点是主观下线时，触发客观下线流程

5.向集群广播一条fail消息，通知所有的节点将故障节点标记为客观下线

6）通知故障节点的从节点触发故障转移流程，从节点切换成主节点  slaveof no one

7）执行clusterDelSlot操作撤销故障主节点负责的槽，并执行clusterAddSlot把这些槽委派给自

8）向集群广播自己的pong消息，通知集群内所有的节点当前从节点变为主节点并接管了故障主节点的槽信息。

3.2.判断集群挂了
    如果集群一个master挂了，并且该节点没有备点，或者备节点也挂了，则集群就挂。不过 Redis 也提供了一个参数cluster-require-full-coverage(默认yes) 可以允许部分节点故障，其它节点还可以继续提供对外访问。