Redis中的Sentinel机制

Posted 2023-05-02

参考技术A Redis的Sentinel文档

概述：Redis的Sentinel系统用于管理多个Redis服务器，该系统执行以下三个任务：

如何使用？

启动Sentinel

    对于 redis-sentinel 程序，你可以用一下命令来启动Sentinel系统：

    对于 redis-server 程序，你可以用下面的命令来启动一个运行在Sentinel模式下的Redis服务器

    两种方式都可以启动一个sentinel实例，启动sentinel实例必须指定相应的配置文件，系统会使用配置文件来保存sentinel的当前状态，并在Sentinel重启时通过载入配置文件来进行状态还原。

    注意：如果启动Sentinel时没有指定相应的配置文件，或者指定的配置文件不可用（not writabel），那么Sentinel会拒绝启动。

    如何配置Sentinel？

    Redis 源码中包含了一个名为 sentinel.conf 的文件， 这个文件是一个带有详细注释的 Sentinel 配置文件示例。

运行一个 Sentinel 所需的最少配置如下所示：

    解读一下第一条指令的意思：

    其他选项的基本格式如下

学到这里我们进行实操一下，感受一下哨兵的威力！

    我们先在test目录下，新建三个配置文件：26379.conf、26380.conf、26381.conf（Sentinel服务器端口号默认是在redis服务器前拼个2），用 vi 命令创建这三个配置文件，然后我们在配置文件中写入一些简单的配置：

端口号：26379，哨兵名称：mymaster，主机地址：127.0.0.1，监控的redis端口号：6379，必须要2台从Sentinel服务器同意才会切换master，并进行故障迁移。（注意，这三个配置文件监控的redis服务器端口都是6379）

用相同的方法，创建了另外两个sentinel配置文件

我们先启动一个6379作为master

再启动6380、6381，作为两个slave

接下来正菜上场了！启动Sentinel！

可以发现，有两个slave正在跟随master，我们只要拿哨兵监控master，就可以看到有几个slave

我们继续启动，再接着启动两个Sentinel服务器

现在我们做一个小实验：如果我们将master服务器（6379）关闭，两个slave之间会发生什么？

当把master关闭之后，两个slave直接会有一段时间提示主服务器拒绝访问：

而哨兵开始也没有立马进行选举投票，选出新master，因为redis选举默认配的时间是有些长的，要过一点时间才开始选举投票，经过重新选举之后，sentinel选择了6381作为新的master。

那既然6381作为新秀，它应该有了很大的指导权，我们现在看看：

我们可以看到，在6381中设置的数据，确实在6380中可以查的到！说明6380在跟随6381，说明哨兵自动帮我们实现了故障转移。

我们再查看一下配置文件，看看有何变化？

可以发现，和原来我们写进去的2句配置完全不一样了，也就是说哨兵会自己改动配置文件。现在的master是6381。

接下来探讨一个问题：哨兵是如何发现其他哨兵的？

答案是：发布订阅机制。活着的master会去查看slave是谁，然后会去订阅其他的slave

我们可以用 psubscribe 去查看相关的发布订阅情况

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