redis集群——哨兵机制（sentinel）

redis集群——哨兵机制（sentinel）

redis集群——哨兵机制（sentinel）

上一篇文章有讲到redis的主从复制《https://blog.csdn.net/weixin_40413961/article/details/123463661?spm=1001.2014.3001.5501》，读写分离的集群架构方式. 我们也聊到了一些缺点，主节点挂了怎么办呢？

接下来我们就详细聊一下

什么是哨兵机制？

既然解决的问题是主节点挂掉了该怎么办，服务该给那个节点写呢？不写就数据不一致了，服务就会有问题了。

1. 可不可以给从节点写数据?
   可以写，但是从节点不会给其他节点同步数据了，那其他读的节点也会不一致。

2. 怎么解决这个不一致？
   将变为主节点的这个从节点变更为真正的主节点，那就可以履行主节点的能力向其它从节点写数据了。

3. 但是从节点有很多选那个成为主节点呢？
   这个我们就得定一个排名规则了，手动指定排名的，最好不要那种机器网络有问题的，数据也是比较全的，都好的话就挑排在第一个的呗。
   总结如下：（以下三轮筛选得到一个主库）

   • 优先级最高的从库得分高。（slave-priority）
   • 和旧主库同步程度最接近的从库得分高。
   • ID 号小的从库得分高。

从以上三点我们知道哨兵该做什么事情了，

1. 监督主从节点是否正常干活。
2. 将不干活的都替换掉
3. 选一个最优的主节点。
   其实我感觉他不像是哨兵，而更像是一个team leader。是在监工，分工，还能识人。

但是还是有一个问题，就是如果这个哨兵挂了该怎么办呢？灵鸡一动，OK，搞多个哨兵，就算有挂一个的，还有其他的 。总不能说全都挂掉了吧。说到这里突然有一点感悟：“冗余是可靠性保证的最有效的方式之一”

哨兵集群

基于 pub/sub 机制的哨兵集群组成

• 哨兵首先是监听主库 ：通过这个配置：sentinel monitor
• 哨兵实例之间可以相互发现，要归功于 Redis 提供的 pub/sub 机制，也就是发布 / 订阅机制。
• 哨兵只要和主库建立起了连接，就可以在主库上发布消息了，比如说发布它自己的连接信息（IP 和端口）。
• 主库上有一个名为“sentinel:hello”的频道，不同哨兵就是通过它来相互发现，实现互相通信的。这个频道的意思也可以理解为我们所说的topic

总结：哨兵集群通过redis 的pubsub功能将自己的IP和端口通知其他订阅消息的哨兵服务。然后互相建立起链接。

• 还有一个问题是哨兵是如何监听从库的呢，因为从库也有坏掉的时候通过哨兵的主关判断就能下线更换。 哨兵通过info命令请求主库主库就会把从库列表返回给主库。其他的哨兵也一样。

• 现在哨兵已经可以监听所有的主库和从库了他们挂掉就会可以监听到，并且可以选出主节点了。哨兵挂掉也没问题因为是集群，但是还有一个点我们没有考虑，那就是如果主库呗切换了，那客户端怎么知道被切换了呢？ 如何切换节点呢？

基于 pub/sub 机制的客户端事件通知

我们得首先确定一个点，就是哨兵自己本身也是一个redis实例，他自身也具有redis的功能。

那既然带消息功能那我们就能通过消息通知客户端。将切换过程中每一步都定为一个topic 也就是channel ，发送给客户端。大概事件分为 一下几类。

告诉客户端都进行到哪一步了。然后，我们可以在客户端执行订阅命令，来获取不同的事件消息。（具体命令就不细聊了，可以搜索看看）

好了，有了 pub/sub 机制，哨兵和哨兵之间、哨兵和从库之间、哨兵和客户端之间就都能建立起连接了，再加上我们上节课介绍主库下线判断和选主依据，哨兵集群的监控、选主和通知三个任务就基本可以正常工作了。不过，我们还需要考虑一个问题：主库故障以后，哨兵集群有多个实例，那怎么确定由哪个哨兵来进行实际的主从切换呢？

哨兵如何执行主从切换

这里因为是哨兵集群，所以说牵扯到两次的投票选举，第一次选举：刚也说到过主观下线，主观下线就是哨兵自己判断主节点要下线。当有一个或者多个哨兵发现要主观下线的时候会通知其他的哨兵告诉他们是不是要下线。其他哨兵会给一个Yes 或者NO结果，当赞成票达到我们想要的票数的时候就会判断为客观下线。这个赞成票数是可以在哨兵的配置文件中进行配置。 字段为：quorum

判定主节点为客观下线，这个哨兵就可以再给其他哨兵发送命令，表明希望由自己来执行主从切换，并让所有其他哨兵进行投票。这个投票过程称为“Leader 选举”。因为最终执行主从切换的哨兵称为 Leader，投票过程就是确定 Leader。也就是结合上文就是选总监了。

在投票过程中，任何一个想成为 Leader 的哨兵，要满足两个条件：第一，拿到半数以上的赞成票；第二，拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值。以 3 个哨兵为例，假设此时的 quorum 设置为 2，那么，任何一个想成为 Leader 的哨兵只要拿到 2 张赞成票，就可以了。投票过程中是有规则投过的就不能再投了。

总结

• 基于 pub/sub 机制的哨兵集群组成过程；
• 基于 INFO 命令的从库列表，这可以帮助哨兵和从库建立连接；
• 基于哨兵自身的 pub/sub 功能，这实现了客户端和哨兵之间的事件通知。
• 对于主从切换，当然不是哪个哨兵想执行就可以执行的，否则就乱套了。所以，这就需要哨兵集群在判断了主库“客观下线”后，经过投票仲裁，选举一个 Leader 出来，由它负责实际的主从切换，即由它来完成新主库的选择以及通知从库与客户端。

参考

• https://time.geekbang.org/column/article/275337
• https://blog.csdn.net/ydonghao2/article/details/97639095