哨兵机制：当主库挂了，redis 是否能继续服务

type

status

date

slug

summary

问题回顾

如上图，很清晰的看到问题的所在。如果主库挂了那么客户端不能在向该 redis 集合写入任何数据并且从 redis 在无法同步主 redis数据。这样虽然可以读取到从 redis 的数据，但是读到的数据大概率不是最新的数据这样就会导致数据的一致性问题。（这是个很严重的问题哦，可能会让客户无法看到最新的数据。）

哨兵是什么

Redis Sentinel 是 Redis 的高可用性解决方案。它是一个分布式系统，可以监控所有的 Redis 主从服务器，并在主服务器出现故障时自动执行故障转移。Redis Sentinel 的主要任务包括：

监控（Monitoring）：Sentinel 会不断地检查你的主服务器和从服务器是否按照预期运行。

通知（Notification）：如果某个 Redis 实例出现故障，Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。

自动故障转移（Automatic failover）：如果一个主服务器无法正常工作，Sentinel 可以开始一个故障转移过程，选举一个从服务器作为新的主服务器，然后其他的从服务器会自动连接到新的主服务器。

配置提供者（Configuration provider）：客户端可以询问 Sentinel 获取当前的主服务器地址，如果发生了故障转移，客户端可以得到新的主服务器地址。通过这些功能，Redis Sentinel 提供了一种方式，使得 Redis 在主服务器出现故障时可以继续提供服务。

哨兵机制的基本流程

哨兵主要工作机制就是：监控->选主->通知

监控：周期性的给所有主从库发送 PING 命令，判断他们是否在线。如果在规定时间内未回复。那么哨兵将会将它标记为"下线状态"，如果主库被标记为"下线状态"那么接下来就会进行选主流程。

选主：到达选主流程之后，哨兵就会根据一定的规则从所有从库中选取新的主库。通知：选主成功后，哨兵就会将新的主库信息发送从库然后让从库执行 SLAVEOF 寄建立主从关系并同步数据。此外，哨兵还会通知客户端新主库信息，让客户端接下来的请求新主库。在了解完哨兵的监控流程的过程中，我们会发现两个比较重要的概念：在监控的过程中哨兵会将失去连接的 redis 标记为 "下线状态" 其实他是存在两种状态的，那就是主观下线和客观下线。

在选主的过程中我们是根据一定规则选取主库的那么这个规则是什么呢？

接下来我们在详细的说明下这两个概念。

主观下线和客观下线

首先，我们来阐述下主观和客观的概念。什么是主观的？主观是出自个人的的观点具有鲜明的个人色彩，如果我们在采取意见的时候主观意见我们通常只能作为参考。什么是客观？有一话说的非常好，那就是客观事实。很清晰的就解释的客观这个词。了解了这个词之后你就应该之后什么是主观下线和客观下线了吧。

当哨兵1发送 PING 命令后在规定时间内未收到主库的回复，哨兵1只能将主库标记为主观线下，这时候是不能进入选主流程的。因为当前只是哨兵1的主观意见不能代表客观事实。之后会继续判断其他哨兵的状态，例如：上图哨兵3也将主库标记为主观下线。这时大部分哨兵都判断出主库已下线那么就会标记主库为客观下线（少数服从多数），之后就会进行选主流程。判断客观下线的条件是：N/2+1 为什么不能哨兵1判断主观下线就进行选主流程呢？因为只有哨兵1判断为下线有可能是因为网络等其他一些问题导致主库在规定时间没有回复 PING 命令。这就可能存在误判的问题，这样就可能导致数据的丢失以及一段时间内不可用的情况。

选主的条件

优先级高的从库得分高

和旧主库同步程度最接近的从库得分高

ID 号小的从库得分高

如果到了选主的阶段，哨兵首先会根据从库的优先级来进行选择。从库的优先级可以在创建主从的连接的时候配置 slave-priority，优先级高的自然就容易被选择成主库。如果优先级都想同（未配置 slave-priority）之后会判断从库的同步的程度，那是依靠什么来判断同步的程度呢。不知道你是否看了上一篇文章或者是已经忘记了，在主从同步过程中会记录同步的进度 slave_repl_offset, 哨兵只需要比对 slave_repl_offset 即可。如果还是无法选出主库最后将会使用 ID 号来进行选择。

总结

到这里我们完美的解答了文章开始问的问题。本篇文章主要讲述了什么是哨兵，哨兵主要的作用，哨兵机制的操作流程以及操作过程中一些重要的流程。希望这知识能对你有帮助，让我们共同进步成为一个合格的搬砖侠。^_^

问题回顾

哨兵是什么

哨兵机制的基本流程

主观下线和客观下线

选主的条件

总结

iLikeBug