redis主从架构和redis cluster的选主原理

灰太狼 2023-07-13 10:46 46阅读 0赞

## redis主从架构 ##

1.  判断节点宕机  
    首先哨兵会判断master是否宕机，这里有两个状态，分别是sdown（主观宕机）和odown（客观宕机）。sdown就是一个哨兵认为master宕机，当哨兵ping一个master，并且超过了is-master-down-after-milliseconds参数配置的时间之后没有响应，就认为是sdown，之后如果一个哨兵在指定时间之内，收到了quorum指定数量的其他哨兵也认为master为sdown，那么哨兵就会达成一个共识，就是odown，认为master客观宕机了  
    当哨兵集群认为master的状态为odown，就需要选举出一个哨兵来做切换，这个哨兵还得得到majority哨兵的授权，才能正式执行切换，majority的意思就是大多数，即（哨兵总数/2） + 1  
    如果quorum < majority，比如5个哨兵，majority就是3，quorum设置为2，那么就3个哨兵授权就可以执行切换；但是如果quorum >= majority，那么必须quorum数量的哨兵都授权，比如5个哨兵，quorum是5，那么必须5个哨兵都同意授权，才能执行切换
2.  从节点过滤  
    淘汰掉不合适的节点，如果slave跟master断开连接已经超过了down-after-milliseconds参数的10倍，外加master宕机的时长，那么slave就被认为不适合选举为master，因为断开连接的时间太久，跟master中的数据相差较大
3.  从节点选举  
    按照slave优先级进行排序，slave priority越低，优先级就越高  
    如果slave priority相同，那么就比较replica offset（复制偏移量），哪个slave复制了越多的数据，offset越靠后，优先级就越高  
    如果上面两个条件都相同，那么就比较run id（redis每次启动的时候生成随机的run id作为redis的标识） 选择run id比较小的那个slave作为master

## redis cluster ##

1.  判断节点宕机  
    在cluster-node-timeout内，一个节点ping另外某个节点，但一直没有返回响应，则认为那个节点pfail了，也就是主观宕机，之后会在gossip的ping信息中，将信息与其他节点交换，如果超过半数的节点都认为某一个节点pfail了，那么就认为这个节点fail，也就是客观宕机

这里简单介绍一下gossip，它是redis cluster节点之间的通信协议。所有的节点都持有一份元数据，不同的节点之间出现了元数据的变化的话，都会将元数据发送给其他节点，让其他节点也进行元数据的变更。gossip协议的好处是元数据更新较为分散，这样可以降低单一节点数据更新的压力，坏处是更新会有一定的延时

1.  从节点过滤  
    检查每个slave节点与master节点断开连接的时间，如果超过了cluster-node-timeout \* cluster-slave-validity-factor，那么就判断这个slave节点不适合成为master
2.  从节点选举  
    每个slave节点，都会根据自己对master复制数据的offset，来设置一个选举时间，offset越大的slave节点，选举时间越靠前，因为同步master的数据更多，优先进行选举  
    然后所有的master节点给要进行选举的slave进行投票，如果大部分master节点（N/2 + 1）都投票给了某个slave节点，那么选举完成，当选的slave节点执行主备切换，提升为master节点

总结：redis主从架构和redis cluster的选举流程非常类似，都是由两个状态最终判断某个master节点宕机，然后先把不符合条件的slave节点筛选出去，再对剩下的slave节点按照一定的条件进行选举，最终完成主备切换