redis集群和哨兵选举机制(概述)

Redis的集群分为两种，一种是集群cluster一种是哨兵

1. redis集群选举分析

当salve发现自己的master变为FAIL状态时，尝试进行Failover（故障切换）

当存在多个slave的时候，就需要竞争成为master，过程如下

（1） slave发现自己的master变为FAIL

（2） 将自己记录的集群currentEpock加一，并广播FAILOVER_AUTH_REQUEST信息

（3） 其他小集群的master会相应slave的广播消息，首先判断请求者的合法性，并发送FAILOVER_AUTH_ACK，对每一个epoch只发送一次ack

（4） 尝试failover的slave收集master返回的FAILOVER_AUTH_ACK

（5） Slave受到超过半数的master的ack就成为新的master

（6） Slave广播ping消息通知其他集群节点

Slave节点不是主节点已进入FAIL状态就马上尝试发起选举，而是有一定的延时，一定的延时确保等待FAIL状态在集群中传播。Slave如果立即尝试选举，其它的masters或许尚未意识到FAIL状态，可能会拒绝投票。

延时计算公式：

DELAY = 500ms+random（0~5000ms）+SLAVE_RANK*1000ms

SLAVE_RANK表示此slave已经从master复制数据的总量的rank。Rank越小代表已经复制的数据越新。这种方式下，只有最新数据的slave将会首先发起选举。

Redis集群如果发生脑裂,网络分区导致脑裂后多个主节点对外提供写服务,当网络分区回复,会将其中一个主节点变为从节点,变为从节点之后,回从现有主节点复制数据,那原来的数据就会丢失,redis不像zookeeper有过半机制,是通过配置文件的参数

min-replicas-to-write 3

min-replicas-max-lag 10

第一个参数表示连接到master的最少slave数量

第二个参数表示slave连接到master的最大延迟时间

按照上面的配置，要求至少3个slave节点，且数据复制和同步的延迟不能超过10秒，否则的话master就会拒绝写请求，配置了这两个参数之后，如果发生集群脑裂，原先的master节点接收到客户端的写入请求会拒绝，就可以减少数据同步之后的数据丢失。

2. 哨兵的选举

Redis 的哨兵选举,首先是从sentinel中选出leader,由这个leader去操作redis主从切换.

1. 选出sentinel的leader

当一个master服务器被sentinel认为下线状态后,sentinel会与其余的sentinel协商选出的leader进行故障转移,每个发现master服务器进入下线的sentinel都可以要求其他sentinel选自己为sentinel的leader,选举是先到先得,同是每个sentinel每次选举都会自增配置纪元(选举周期),每个纪元中只有选择一个sentinel的leader.如果所有超过一半的sentinel选举其中一个sentinel作为leader.之后该sentinel作为leader进行故障转移操作,

2. 操作redis服务器

从存活的slave中选举新的master,这个选举过程跟集群的master选举很类似.

关于哨兵可以参考https://www.cnblogs.com/Eugene-Jin/p/10819601.html