参考:
https://time.geekbang.org/column/article/275337
引言
一旦多个实例组成了哨兵集群,即使有哨兵实例出现故障挂掉了,其他哨兵还能继续协作完成主从库切换的工作
基于 pub/sub 机制的哨兵集群组成
配置哨兵的信息时,设置了主库的 IP 和端口,并没有配置其他哨兵的连接信息。
那么哨兵间如何彼此发现?
要归功于 Redis 提供的 pub/sub 机制,也就是发布 / 订阅机制。
彼此发现过程过程:
- 哨兵只要和主库建立起了连接,就可以在主库上发布消息了,比如说发布它自己的连接信息(IP 和端口)。
- 同时,它也可以从主库上订阅消息,获得其他哨兵发布的连接信息。
- 当多个哨兵实例都在主库上做了发布和订阅操作后,它们之间就能知道彼此的 IP 地址和端口。
除了哨兵实例,自己编写的应用程序也可以通过 Redis 进行消息的发布和订阅。所以,为了区分不同应用的消息,Redis 会以频道的形式,对这些消息进行分门别类的管理。
在主从集群中,主库上有一个名为“sentinel:hello”的频道,不同哨兵就是通过它来相互发现,实现互相通信的。
哨兵除了彼此之间建立起连接形成集群外,还需要和从库建立连接。
哨兵是如何知道从库的 IP 地址和端口的呢?
这是由哨兵向主库发送 INFO 命令来完成的。
连接从库过程:
- 哨兵给主库发送 INFO 命令
- 主库接受到这个命令后,就会把从库列表返回给哨兵
- 接着,哨兵就可以根据从库列表中的连接信息,和每个从库建立连接,并在这个连接上持续地对从库进行监控。
基于 pub/sub 机制的客户端事件通知(通知)
每个哨兵实例也提供 pub/sub 机制,客户端可以从哨兵订阅消息。
哨兵提供的消息订阅频道有很多,不同频道包含了主从库切换过程中的不同关键事件。
知道了这些频道之后,你就可以让客户端从哨兵这里订阅消息了。
客户端获取时间消息过程:
- 客户端读取哨兵的配置文件后,可以获得哨兵的地址和端口,和哨兵建立网络连接。
- 然后,我们可以在客户端执行订阅命令,来获取不同的事件消息。
- 时间发生后,哨兵会向客户端发送事件消息。
由哪个哨兵执行主从切换?
1.投票主机是否下线
2.投票由哪个哨兵执行
步骤一:
一个哨兵获得了仲裁所需的赞成票数后,就可以标记主库为“客观下线”。这个所需的赞成票数是通过哨兵配置文件中的 quorum 配置项设定的。
满足条件:
- 大于等于哨兵配置文件中的 quorum 值
步骤二:
展示一下 3 个哨兵、quorum 为 2 的选举过程。
此时,这个哨兵就可以再给其他哨兵发送命令,表明希望由自己来执行主从切换,并让所有其他哨兵进行投票。这个投票过程称为“Leader 选举”。
满足条件:
- 第一,拿到半数以上的赞成票;
- 第二,拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值。