Redis核心技术05-哨兵机制
# Redis核心技术05-哨兵机制
相关文章：
Redis深入-数据同步 (opens new window)
在主从模式下，如果从库发生故障，客户端还可以继续向主库或其他从库发送请求，但是如果主库发生故障，那么就会影响到从库的同步。
如果此刻的请求都是读操作请求，从库还能够继续提供服务。但是一旦有写操作，按照读写分离的要求，写操作是由主库来完成的，而此刻主库已经不提供任何服务了。
对于这种群龙无首的情况，会造成写服务中断，同时从库也无法进行数据同步，因此我们需要推荐一个新队长（把一个从库提升为主库）。
# 哨兵机制
在选择某一从库升级为主库的时候存在三个问题：
- 主库是否真的故障
- 选择哪个从库作为主库
- 如何把新主库的相关信息通知给从库和客户端
在Redis主从集群中，哨兵机制是实现主从库自动切换的关键机制。
# 基本流程
哨兵是一个运行在特殊模式下的Redis进程，主从库实例运行的同时，它也在运行。
哨兵的三个任务：监控、选主、通知。
# 监控
监控是指哨兵机制在运行时，周期性地给所有的主从库发送PING命令，如果对应的主从库没有在规定的时间响应哨兵的PING命令，哨兵就会把它认为“下限状态”。特别的，如果主库没有及时响应哨兵的PING命令，那么哨兵就要开始第二个流程自动切换主库的流程。
# 选主
主库挂了以后，哨兵就需要从很多从库里，按照一定的规则，选择一个从库实例把它升级为主库实例。
# 通知
哨兵会把新主库的连接信息发送给其他从库，让他们执行replicaof命令，和新主库建立连接，并进行数据复制。同时哨兵会把新主库的连接信息通知给客户端，让它们把请求操作发到新主库上。
通知流程较为简单，并不涉及到决策问题，而监控和选主则需要涉及到决策问题：
- 监控任务中，哨兵需要判断主库是否处于下线状态。
- 选择任务中，哨兵需要抉择哪个从库实例作为主库。
# 主观下线和客观下线
# 主观下线
哨兵进程会使用PING命令检测主库、从库的网络连接情况，用来判断实例的状态。
- 如果检测的是从库，发现该从库没有在规定时间进行回应，那么哨兵就会简单标记为“主观下线”，因为从库下线影响不会太多，Redis的服务也不会中断。
- 如果检测的是主库，由于主从切换涉及到选择新主和新主库同步，如果发生误判（主库并没有故障，但是哨兵认为其故障了） 这样会消耗大量的资源，所以不能简单主观下线，而需要客观下线。
误判一般发生在集群网络压力较大、网络拥塞或者是主库本身压力较大的情况下。
# 客观下线
主从切换这种重大事情，如果一个哨兵去判断，难免发生误判。哨兵机制通常会采用多实例组成的集群模式进行部署，这也被成为哨兵集群。引入多个哨兵实例一起来判断，就可以避免单个哨兵因为自身网络状况不好，而误判主库下线的情况。同时，多个哨兵的网络同时不稳定的概率较小，由它们一起做决策，误判率也能降低。
在判断主库是否下线时，不能由一个哨兵说了算，只有大多数的哨兵实例，都判断主库已经“主观下线”了，主库才会被标记为“客观下线”，这个叫法也是表明主库下线成为一个客观事实了。这个判断原则就是：少数服从多数。同时，这会进一步触发哨兵开始主从切换流程。
这里就相当于成立了一个评审小组，小组共同对主库进行判断，采用少数服从多数的原则。
# 如何选新主
选新主流程：在多个从库中，按照一定的筛选条件，把不符合条件的从库去掉。然后，我们再按照一定的规则， 给剩下的从库逐个打分，将得分最高的从库选为新主库。
# 初筛流程
一般情况下，我们肯定要先保证所选的从库仍然在线运行。不过，在选主时从库正常在线，这只能表示从库的现状良好，并不代表它就是最适合做主库的。
在选主时，除了要检查从库的当前在线状态，还要判断它之前的网络连接状态。如果从库总是和主库断连，而且断连次数超出了一定的阈值，我们就有理由相信，这个从库的网络状况并不是太好，就可以把这个从库筛掉了。
具体怎么判断呢？你使用配置项 down-after-milliseconds * 10。其中，down-aftermilliseconds 是我们认定主从库断连的最大连接超时时间。如果在 down-aftermilliseconds 毫秒内，主从节点都没有通过网络联系上，我们就可以认为主从节点断连了。如果发生断连的次数超过了 10 次，就说明这个从库的网络状况不好，不适合作为新主库。
# 打分流程
接下来就需要对初筛得到的从库进行打分。可以分别按照三个规则依次进行三轮打分，这三个规则分别是从库优先级、从库复制进度以及从库 ID 号。只要在某一轮中，有从库得分最高，那么它就是主库了，选主过程到此结束。如果没有出现得分最高的从库，那么就继续进行下一轮。
第一轮：从库优先级
用户可以通过 slave-priority 配置项，给不同的从库设置不同优先级。比如，你有两个从 库，它们的内存大小不一样，你可以手动给内存大的实例设置一个高优先级。在选主时， 哨兵会给优先级高的从库打高分，如果有一个从库优先级最高，那么它就是新主库了。如果从库的优先级都一样，那么哨兵开始第二轮打分。
第二轮：从库复制进度
这个规则的依据是，选择和旧主库同步最接近的那个从库作为主库。
在主从同步中过程中，主库会用 master_repl_offset 记录当前的最新写操作在 repl_backlog_buffer 中的位置，而从库会 用 slave_repl_offset 这个值记录当前的复制进度。
此时，我们想要找的从库，它的 slave_repl_offset 需要最接近 master_repl_offset。如果在所有从库中，有从库的 slave_repl_offset 最接近 master_repl_offset，那么它的得分就最高，可以作为新主库。
在上图中，如果旧主库的master_repl_offset为1000，那么最接近1000的就是从库2的990，所以从库2作为新主库。
第三轮：从库ID号
每个实例都会有一个 ID，这个 ID 就类似于这里的从库的编号。目前，Redis 在选主库时，有一个默认的规定：在优先级和复制进度都相同的情况下，ID 号最小的从库得分最高，会被选为新主库。
# 选主小结
首先，哨兵会按照在线状态、网络状态，筛选过滤掉一部分不符合要求的从库，然后，依次按照优先级、复制进度、ID 号大小再对剩余的从库进行打分， 只要有得分最高的从库出现，就把它选为新主库。