首先回答老师的问题：调整 server.hz 的目的是什么？ 答：为了使每个哨兵与其他哨兵不同步，通过这种方式避免由于几个哨兵同时启动，导致无法投出leader的情况，类似脑裂，因为每个独立的哨兵都在启动同一时刻开始发起投票，然后一轮一轮下去都没法投出leader。 总结： 本篇文章老师主要介绍了，redis在Raft协议上的实现，Redis本身不是完全按照Raft协议实现的，其中最主要的原因就是每个哨兵节点都是对等的，而Raft协议逻辑主要如下： 1、在稳定系统中只有 Leader 和 Follower 两种节点，并且 Leader 会向 Follower 发送心跳消息。 2、如果某个Follower 在一定时间没收到Leader的心跳，那么他会变成Candidate 并且可以发起选举。 3、Candidate 会先投自己一票，然后等待其他follower的投票。 4、如果投票结果能选出Leader则新的Leader上位，否则再进行一轮选举。 而Redis是哨兵是对等的，所以每个哨兵都会监听当前Redis的Leader的心跳，当前Redis的Leader如果发生异常，哨兵会开始发起选举直到第一个Leader被选举出来并通知每个哨兵。 TILT模式： 由于哨兵模式是对等的，那么必然会出现一情况导致哨兵节点不可信任，比如：当前系统时间被修改，当前哨兵节点硬件资源繁忙，当前网络稳定状态差等等。当这些情况发生的时候哨兵就有可能进入TILT模式，在这种模式下哨兵是正常运行工作，但是它的投票是不被信任的。 拓展： 其实本篇文章主要的核心就是分布式共识问题，针对分布式共识有一个很经典的问题就是【拜占庭将军问题】 ，而大多数分布式共识最终目的都是处理这个问题的场景，由此衍生出了各种共识算法如：Raft算法，Paxos算法，ZAB算法，PBFT算法等等。 而ZAB算法就是Zookeeper核心指导算法，ZAB与Raft不同的是，ZAB是通过竞争手里资源，比如leader底下有几个ack，最多ack的那个竞选成功，所以相比Raft可以改造为平等模型的互相投票再出leader，ZAB中leader的概念稍微重要一点（我个人理解ZAB应该比较容易脑裂，不知道理解是否到位）。