此前，我们非常依赖主服务器，因为所有的写命令都首先会给主服务器，那如果主服务器死掉，其它从服务器该怎么办？顶替！选择一个从服务器来担任主服务器的职责。
Redis 提供哨兵机制（哨兵其实是一个运行在特殊模式下的 Redis 进程，所以它也是一个节点），它会检测主节点是否存活，如果发现主节点挂掉，就会选举一个从节点切换为主节点，并且把新主节点的相关信息通知给从节点和客户端。总结就是主要负责三件事情：监控、选主、通知。
如何判断主节点真的故障了？
哨兵会每隔 1 秒给所有主从节点发送 PING 命令，当主从节点收到 PING 命令后，会发送一个响应命令给哨兵，这样就可以判断它们是否在正常运行。如果主或从节点没有回应，那就视为主或从节点为 主观下线。
之所以视为主观下线，可能因为网络问题会导致误判，即可能只是因为主节点的系统压力比较大或者网络发送了拥塞，导致主节点没有在规定时间内响应哨兵的 PING 命令。
那如何判断是 客观下线 呢？
通过多个哨兵节点（哨兵集群，至少 3 台）一起判断，多个哨兵的网络同时不稳定的概率较小，由它们一起做决策，误判率也能降低。
当一个哨兵判断主节点为主观下线后，就会向其他哨兵发起命令，其他哨兵收到这个命令后，就会根据自身和主节点的网络状况，做出赞成投票或者拒绝投票的响应。哨兵判断完主节点客观下线后，哨兵就要开始在多个「从节点」中，选出一个从节点来做新主节点。
由哪个哨兵进行主从故障转移？
哨兵集群进行投票选择，在此之前，得有一个候选者。哪个哨兵节点判断主节点为客观下线，它就是候选者，所谓的候选者就是想当主服务器的哨兵。
候选者会向其他哨兵发送命令，表明希望成为 Leader 来执行主从切换，并让所有其他哨兵对它进行投票。每个哨兵只有一次投票机会，如果用完后就不能参与投票了，可以投给自己或投给别人，但是只有候选者才能把票投给自己（候选者都会把那一票投给自己）。
那么候选者要满足两个条件：
- 票数过半。
- 拿到的票数同时还需要大于等于哨兵配置文件中设置的 quorum 值。
注：quorum 建议设置为哨兵个数的一半并加 1。
主从故障转移到过程是怎样的？
选举出了哨兵 leader 后，就可以进行主从故障转移的过程了：
主从故障转移操作包含以下四个步骤：
- 从 从节点 中挑选出一个作为新主节点。
- 让其他从节点修改为 复制 新主节点。
- 将新主节点的 IP 地址和信息，通过 【发布者/订阅者机制】通知给客户端。
- 继续监视旧主节点，当这个旧主节点重新上线时，将它设置为新主节点的从节点。
步骤一：选出新主节点
这么多【从节点】，到底选择哪个？
首先要把网络状态不好的从节点给过滤掉。即已经下线的从节点过滤掉，然后把以往网络连接状态不好的从节点也给过滤掉。
接下来要对所有从节点进行三轮考察：优先级、复制进度、ID号。
- 第一轮考察：哨兵首先会根据从节点的优先级来进行排序，优先级越小排名越靠前。
- 第二轮考察：如果优先级相同，则查看复制的下标，哪个从主节点接收到复制数据多，哪个就靠前。
- 第三轮考察：如果优先级和下标都相同，就选择从节点 ID 较小的那个。
步骤二：将从节点指向新主节点
当新主节点出现之后，哨兵 leader 下一步要做的就是，让已下线主节点属下的所有「从节点」指向「新主节点」，这一动作可以通过向「从节点」发送 SLAVEOF 命令来实现。
从节点根据收到的命令和提供的网络地址和端口信息，就知道要更换复制的新主节点。
步骤三：通知客户的主节点已更换
通过发布者/订阅者机制，有了这些事件通知，客户端不仅可以在主从切换后得到新主节点的连接信息，还可以监控到主从节点切换过程中发生的各个重要事件。这样，客户端就可以知道主从切换进行到哪一步了，有助于了解切换进度。
步骤四：将旧主节点变为从节点
故障转移操作最后要做的是，继续监视旧主节点，当旧主节点重新上线时，哨兵集群就会向它发送 SLAVEOF 命令，让它成为新主节点的从节点。
⭐️内容取自《小林Coding》，仅从中取出个人以为需要纪录的内容。不追求内容的完整性，却也不会丢失所记内容的逻辑性。如果需要了解细致，建议访问官方网站。
