Redis哨兵模式故障自动转换机制小记
Redis哨兵模式故障自动转换机制小记
写在前面：今天和同事讨论的过程中发现这方面的知识有些疑惑，就去查阅了下资料，在这里记录下
- 首先，Redis分为哨兵模式、单机模式、集群模式，其中哨兵模式是一个主节点多个从节点，主节点负责写，从节点负责读，然后哨兵组有多个（也可以为一个，但是为了高可用，一般都是多个，而且是奇数个，以免选举的时候出现票数相同的情况）
- 在出现故障的时候，首先由感知故障的那一个或者多个哨兵向哨兵组内使用“流言协议（gossip）”传播主观判断，然后哨兵组内通过半数选举来进行客观判断（也可能不是半数，可以在Redis配置文件中自己设置这个值-->相关参数是“quorum”，一般设置为半数+1-->因为是奇数个节点，所以得半数之后+1）
- 一旦客观判断坐实，哨兵组就会决定处理故障，这个时候需要选举出一个哨兵节点来做这个事情，使用的是类Raft协议（其实是针对Raft协议做了更改，成功并不会通知相关结点），基本原理是每个哨兵节点都向其他哨兵节点发送信息，询问对方能不能投自己一票为leader节点，然后每一个节点都只有一次接受的权利，如果接受之后，身份就会变为follower，这个时候再有其他节点的请求过来，该节点会直接拒绝，当然，因为身份变成了follower，也不会再接受之前的询问反馈（这个节点一开始也会向其他节点发送选自己的请求）-->然后整体是一个先到先得的原则，就是哪个请求先到，就接受哪个，然后不再接受其它的
- 当一个节点的票数超过活着等于majority（也可以自己设置，但是要遵循一个原则，就是majority的值得大于等于上面半数选举的quorum的值），就会自动开始设定自己为leader（注意这里并不会告诉其它结点它成为了leader），然后去处理故障切换
- 那么哨兵组如何判断故障已经被解决了呢，因为leader生成之后不会告诉其他节点，所以哨兵组除了处理的那个结点，都处于等待状态
- 方法：哨兵组在执行选举的同时，也在监控各个节点，当某个节点变为master之后，它们会感知到，也就知道故障被处理，就自动会退出选举状态
- 但是如果等待了两个故障时间之后，还是没有新的master节点生成，就说明选举失败，将重新进行选举
- 检测到Master结点恢复正常，整个故障修复流程结束
以上就是redis哨兵模式故障自动转换机制的所有内容
希望对后来人有所帮助
reference
Redis 哨兵模式(Sentinel) 原理
深入学习Redis 4
Redis哨兵机制原理详解
Raft算法详解
Redis中哨兵选举算法
Redis集群：Sentinel哨兵模式（详细图解）
