Redis 哨兵问题

前言

什么是哨兵？

哨兵是用于为主从同步提供自动化故障转移功能的组件。在主从同步主节点已宕机的情况下，想要令从节点代替主节点对外提供服务需要执行“修改从节点配置文件/重启从节点/重新建立主从关秀/修改客户端配置文件/重启客户端”等操作。这些操作在人为执行时是相当繁复/易错/耗时的，因此为了快速/准确的完成故障转移Redis便设计了哨兵以实现对上述行为的全自动化执行…哨兵的相关功能具体如下：

节点监控：监测主/从节点是否正常工作；
消息通知：在某节点宕机时向管理员发送通知；
故障转移：在主节点宕机时自动选择其从节点以作为新主节点；
配置中心：为客户端提供访问地址，从而避免在主节点宕机时人为修改客户端配置文件中的访问地址。

哨兵推荐以什么形式工作？为什么？

哨兵被推荐以奇数集群的方式工作，因为单个哨兵对节点的监测结果可能并不准确，而多哨兵的综合监测将大幅提升节点状态判定的准确性。那为什么是奇数集群呢？这是因为在判断主节点已宕机的情况下哨兵集群协同投票选举出监测数据最新的哨兵成为领导哨兵，目的是由其根据从节点的优先级/主机数据的同步进度/运行ID的大小等因素选择出可用性最高的从节点以作为新的主节点。而由于奇数数量的哨兵有助于避免因为平票/少票而导致的重复选举，因此哨兵被推荐以奇数集群的方式进行工作。

集群中的哨兵是如何通讯的？

集群中的哨兵有两种通讯方式：一是基于主机的发布/订阅功能进行的间接通讯；二是基于哨兵间的TCP连接进行的直接通讯。

监测相同主机的哨兵会自动归属于一个集群，因此间接通讯是先天就存在的。哨兵启动后会自动订阅主机上一个名为__sentinel__:hello的频道用于进行信息交互，并会在后续通过间接通讯持续向其它哨兵共享数据。这些共享数据包含的内容主要有二：一是哨兵自身的元数据，例如IP/端口等，以便其它哨兵能对自身进行定位；二是哨兵监测到的主/从机运行数据，以便其它哨兵能对自身的检测结果进行综合性判定。

直接通讯是在间接通讯的基础上后天建立起来的，因为哨兵会根据其它哨兵共享的地址信息而与之建立TCP连接。哨兵通过直接通讯进行的信息交互主要有两类：一是对其它发送{PING}指令以检测哨兵的运行状态；二则是在主机宕机时进行故障转移的信息交互。直接通讯是哨兵集群在执行故障转移时的通讯功能承担方，这一方面是因为主机宕机会使得间接通讯失去作用，另一方面也是因为其同步交互的特性可及时返回回应。

哨兵集群执行故障转移的流程是什么样的？

哨兵每秒向主机发送{PING}指令已检测器运行状态，并在超过指定时间未收到回应的情况下判定其已主观下线；
为了确定主机是否真的已经下线，哨兵会其集群中的其它哨兵发送指令以询问其各自的检测结果；
其它哨兵收到指令并返回自身的监测结果，这其间可能会触发其它哨兵对主机的心跳检测；
哨兵在统计询过结果时如果发现判定主机已（主观/客观）下线的其它哨兵数量已达指定数量，那么就会将主机判定为客观下线；
将主机判定为客观下线的主机会向其它哨兵发送指令以发起投票，目的是将自身选举为领导哨兵以进行故障转移，即挑选从机作为新主机；
其它哨兵接受到指令后会整体遵循“先到先得”的准测进行投票，即先请求投票（集群中判定主机客观下线的哨兵可能有多个）的会得到票，而后续的请求就都无效了；
哨兵在统计票数时如果发现票数已达指定数量（一般是总数/2+1），那么就意味着自身已成为领导哨兵。在通知完其它哨兵这个消息后，领导哨兵会根据从机的优先级/主机数据的同步进度/运行ID的大小等因素挑选出可用性最高的从机作为新主机，并修改其它从机的配置以令之向新主机同步，最后再将新主机告知其它哨兵；
领导哨兵会通知客户端新主机的地址以进行连接；
领导哨兵会持续监测旧主机，并在其恢复运行时将之设置为新主机的从机。