Redis哨兵到底怎么管集群，原理和机制简单聊聊

要理解哨兵，得先知道它为啥会出现，Redis本身有一种主从复制的模式，就是一个主节点负责写，多个从节点负责读，并且从节点会从主节点那里同步数据，这样做的好处是读写分离，提高了读的能力，也有一份数据备份，但这里有个大问题：万一那个唯一的主节点宕机了，整个系统就不能写入了，虽然从节点数据还在，但它们自己不会自动选出一个新老大，这就好比一个团队，组长突然不见了，组员们虽然都在，但没人敢站出来主持大局,工作就卡壳了。

Redis哨兵就是为了解决这个“群龙无首”的问题而生的，你可以把哨兵系统想象成一组“监工”或者“选举委员会”，这组监工不干具体的存数据的活儿，它们唯一的任务就是死死地盯着主节点和它的从节点们，确保主节点活着，一旦主节点挂了，这些监工就会自动开会，从剩下的从节点中投票选出一个新的主节点，然后通知其他的从节点和连接的客户端，让它们去跟新主节点打交道，这样，整个系统就在几乎不用人工干预的情况下,自己恢复了正常。

下面我们具体聊聊这群“监工”是怎么工作的,原理和机制可以简单分成这么几步：

第一步：建立监控网络（监工就位） 你得部署至少三个哨兵实例（建议是奇数个，比如3个或5个），为啥要三个？主要是为了“少数服从多数”，防止误判，哨兵们启动后，第一件事就是去监控同一个主节点，它们会通过发送命令，定期检查主节点是否还“活着”（心跳检测），它们也会通过主节点自动发现所有关联的从节点以及其他哨兵实例，这样，哨兵们自己之间也建立了一个监控网络,彼此能通信。

第二步：判定主节点下线（发现老大不行了） 每个哨兵都会每隔一秒向主节点、从节点和其他哨兵发送PING命令，如果主节点在指定时间内（可配置）没有正常回复，比如因为网络问题或者真的宕机了，那么单个哨兵就会先把它标记为“主观下线”，所谓主观下线，就是这个哨兵自己觉得主节点可能挂了，但它说了不算,万一只是这个哨兵和主节点之间的网络出了问题呢？

接下来，这个发现异常的哨兵会去问其他的哨兵：“哎，你们还能联系上主节点吗？”如果超过半数的哨兵（这就是为什么建议用奇数个，方便形成多数派）都报告说联系不上，那么哨兵们就会达成共识，将主节点正式判定为“客观下线”，到了这一步，哨兵们才一致认为，主节点是真的挂了,可以开始下一步行动了。

第三步：选举领头哨兵和故障转移（监工们选主席，然后选新老大） 主节点被客观下线后，不能所有哨兵一窝蜂地都去执行故障转移操作，那样就乱套了，哨兵们要先内部投票，选出一个“领头哨兵”来主持大局，这个选举过程也遵循少数服从多数的原则，每个发现主节点客观下线的哨兵都会要求其他哨兵选自己当领头，哪个哨兵先得到多数票,它就当选。

领头哨兵产生后，故障转移的重任就落在它肩上了，它的工作是从所有健康的从节点中，挑选出一个最合适的来当新的主节点，挑选的标准大致有这几条（来源：Redis官方文档及相关技术解析）：

1. 优先选择网络连接状况好的、数据最新的从节点（复制偏移量最大的）。
2. 如果条件差不多，有优先级配置的优先（slave-priority，可以手动设置）。
3. 如果还一样，就选运行ID（一个随机字符串）最小的那个。

第四步：通知与切换（昭告天下，新皇登基） 选出新主节点后,领头哨兵会干三件大事：

1. 向这个被选中的从节点发送命令，让它升级为主节点（SLAVEOF no one）。
2. 向其他所有从节点发送命令,让它们转而从新的主节点复制数据。
3. 也是非常重要的一步，它会把最新的主节点地址信息更新到自己维护的配置中，并通知所有连接到哨兵系统的客户端应用程序：“主节点换了，现在是这个新地址！”

客户端想要连接Redis集群，就不再是直接写死主节点的地址了，而是连接哨兵，客户端库会从哨兵那里查询当前真正的主节点地址，这样，无论主节点怎么变，客户端只需要认准哨兵这个“服务发现中心”就行了。

总结一下 Redis哨兵管理的核心就是“监控”、“选主”和“通知”，它通过一个独立的、高可用的哨兵集群，解决了原生主从复制模式下的单点故障问题，实现了自动化的故障转移，让Redis集群具备了高可用性，你不需要手动去切换主从，一切都由哨兵自动完成，哨兵模式主要保证的是高可用，它本身并不能横向扩展写能力（写仍然只在主节点进行），如果要扩展写能力，就需要用到更复杂的Redis Cluster模式了。