Redis集群模式之哨兵模式（2）

        上篇文章我们讲解了哨兵模式是干什么的以及怎么干的。这篇文章我们通过几个问题来深入理解一下哨兵模式。

Redis哨兵模式是如何工作的？

        （1）每个哨兵节点以每秒钟一次的频率向它所知的主节点服务器、从节点服务器和其他哨兵节点实例发送一个Ping命令。

        （2）如果一个实例距离最后一次有效回复Ping命令的时间超过down-after-milliseconds选项所指定的值，则这个实例会被当前的哨兵节点标记为主观下线。

        （3）如果一个主节点服务器被标记为主观下线，则正在监视这个主节点服务器的所有哨兵节点要以每秒一次的频率确认主节点服务器是否进入主观下线状态。

        （4）当有足够数量的哨兵节点（大于配置文件中quorum的值）在指定时间范围内指定主节点服务器的确进入主观下线状态，则主节点服务器会被标记为客观下线。

        （5）当主节点服务器被哨兵节点标记为客观下线时，哨兵节点向下线的主节点服务器的所有从节点服务器发送INFO命令的频率会从10秒一次改为1秒一次（在一般情况下，每个哨兵节点会以每10秒一次的频率向它已知的所有主节点服务器和从节点服务器发送INFO命令）。

        （6）如果没有足够数量的哨兵节点同意主节点服务器下线，主节点服务器的客观下线状态就会变成主观下线状态。如果主节点服务器重新向哨兵节点的Ping命令返回有效回复，主节点服务器的主观下线状态就会被移除。

        （7）哨兵节点会与其他哨兵节点进行投票选举，选举出一个主哨兵节点进行故障处理，在从节点中按一定的规则选取一个新的主节点，其他从节点挂载到新的主节点上自动复制新主节点的数据。

故障转移时选举新主节点的标准是什么？

        如果一个主节点服务器被认为客观下线了，那么某个哨兵节点就会执行主从切换，此时首先要选举一个从节点出来，在选举时要考虑从节点的这些信息：

        （1）从节点跟主节点断开连接的时长。如果一个从节点跟主节点断开连接的时间已经超过了down-after-milliseconds的10倍，外加上主节点服务器的故障时间，那么可以认为这个从节点的数据已经严重缺失了，不适合作为新的主节点。

        （2）从节点的优先级。按照从节点的优先级进行排序，选取优先级最高的作为新的主节点（优先级的值越小代表的优先级越高）。

        （3）从节点的offset值（复制偏移量）。如果两个从节点的优先级相同，那么看replication offset的值，那个从节点复制了旧主节点越多的数据，offset就越靠后，优先级就越高。

        （4）从节点的run id。如果有两个从节点上面两个条件相同，那么选择一个run id比较小的从节点作为新的主节点。

同步配置的时候其他哨兵根据什么更新自己的配置？

        执行切换的哨兵节点，会从要切换到的新主节点那里得到一个configuration epoch，这是一个版本号，每次切换的版本号必须是唯一的。

        如果第一个选举出的主哨兵节点切换失败，那么其他的哨兵，会等待failover-timeout时间，然后接替继续执行切换，此时会重新获取一个新的configuration epoch作为新的版本号。

        版本号非常的重要，因为各种消息都是通过一个channel去发布和监听的，所以一个哨兵完成一次新的切换之后，新的主节点配置是跟着新的版本号的，其他的哨兵都是根据版本号的大小来更新自己的主节点的配置。

为什么Redis哨兵集群只有两个哨兵节点无法正常工作？

        哨兵集群必须部署2个以上的哨兵节点。如果只有两个哨兵节点，即两个Redis实例，采用一主一从的模式。那么Redis配置文件中的quorum的值为1，表示只要有一个哨兵认为主节点服务器宕机，就可以认为住节点服务器宕机了。

        如果此时服务器1宕机了，那么哨兵节点1和主节点都宕机了，虽然哨兵节点2知道主节点服务器宕机了，但是这个时候，需要满足majority约束，也就是一半以上的哨兵节点处于运行状态，majority的计算是哨兵节点总数量除以2加上1,2个哨兵节点的majority的值是2，也就意味着只有2个哨兵节点都运行时才能进行故障转移。现在只剩下哨兵节点2在运行，那么此时的故障转移就不能够执行，那么哨兵模式也就无法正常工作。

        本文我们通过几个问题来深入讲解了一下哨兵模式的工作流程和需要注意的点。大家有什么问题或者勘误可以在评论区留言，笔者看到都会回复的。