一、在配置哨兵的信息时,我们只需要用到下面的这个配置项,设置主库的 IP 和端口,并没有配置其他哨兵的连接信息
sentinel monitor <master-name> <ip> <redis-port> <quorum>
二、基于 pub/sub 机制的哨兵集群组成(哨兵间通信)
1、哨兵实例之间可以相互发现,要归功于 Redis 提供的 pub/sub 机制,也就是发布 / 订阅机制。
A、哨兵只要和主库建立起了连接,就可以在主库上发布消息了,比如说发布它自己的连接信息(IP 和端口)。
B、同时,它也可以从主库上订阅消息,获得其他哨兵发布的连接信息。当
C、多个哨兵实例都在主库上做了发布和订阅操作后,它们之间就能知道彼此的 IP 地址和端口。
2、为了区分不同应用的消息,Redis 会以频道的形式,对这些消息进行分门别类的管理。
A、所谓的频道,实际上就是消息的类别。
B、当消息类别相同时,它们就属于同一个频道。反之,就属于不同的频道。
C、只有订阅了同一个频道的应用,才能通过发布的消息进行信息交换。
D、在主从集群中,主库上有一个名为“__sentinel__:hello”的频道,不同哨兵就是通过它来相互发现,实现互相通信的
a、哨兵 1 把自己的 IP(172.16.19.3)和端口(26579)发布到“__sentinel__:hello”频道上,哨兵 2 和 3 订阅了该频道。
b、那么此时,哨兵 2 和 3 就可以从这个频道直接获取哨兵 1 的 IP 地址和端口号。
c、然后,哨兵 2、3 可以和哨兵 1 建立网络连接。
d、通过这个方式,哨兵 2 和 3 也可以建立网络连接
e 、这样一来,哨兵集群就形成了。
f、它们相互间可以通过网络连接进行通信,比如说对主库有没有下线这件事儿进行判断和协商。
三、哨兵是如何知道从库的 IP 地址和端口的呢?(哨兵与从库)
1、哨兵除了彼此之间建立起连接形成集群外,还需要和从库建立连接。
A、这是因为,在哨兵的监控任务中,它需要对主从库都进行心跳判断,
B、而且在主从库切换完成后,它还需要通知从库,让它们和新主库进行同步。
2、哨兵获得从库的 IP 地址和端口,是由哨兵向主库发送 INFO命令来完成的
A、哨兵 2 给主库发送 INFO 命令,主库接受到这个命令后,就会把从库列表返回给哨兵。
B、接着,哨兵就可以根据从库列表中的连接信息,和每个从库建立连接,并在这个连接上持续地对从库进行监控。
四、基于 pub/sub 机制的客户端事件通知(哨兵和客户端间的信息同步)
1、每个哨兵实例也提供 pub/sub 机制,客户端可以从哨兵订阅消息。
A、哨兵提供的消息订阅频道有很多,不同频道包含了主从库切换过程中的不同关键事件。(包括主库下线判断、新主库选定、从库重新配置。)
a、客户端读取哨兵的配置文件后,可以获得哨兵的地址和端口,和哨兵建立网络连接。
b、然后,我们可以在客户端执行订阅命令,来获取不同的事件消息。
c、举个例子,你可以执行如下命令,来订阅“所有实例进入客观下线状态的事件”:
SUBSCRIBE +odown
当然,你也可以执行如下命令,订阅所有的事件:
PSUBSCRIBE *
当哨兵把新主库选择出来后,客户端就会看到下面的 switch-master 事件(表示主库已经切换了,新主库的 IP 地址和端口信息已经有了。)这个时候,客户端就可以用这里面的新主库地址和端口进行通信了。
switch-master <master name> <oldip> <oldport> <newip> <newport>
五、由哪个哨兵执行主从切换(类似”仲裁投票“)
哨兵集群要判定主库“客观下线”,需要有一定数量的实例都认为该主库已经“主观下线”了。
任何一个实例只要自身判断主库“主观下线”后,就会给其他实例发送 is-master-down-by-addr 命令。接着,其他实例会根据自己和主库的连接情况,做出 Y 或 N 的响应,Y 相当于赞成票,N 相当于反对票。
一个哨兵获得了仲裁所需的赞成票数后,就可以标记主库为“客观下线”。
这个所需的赞成票数是通过哨兵配置文件中的 quorum 配置项设定的。
例如,现在有 5 个哨兵,quorum 配置的是 3,那么,一个哨兵需要 3 张赞成票,就可以标记主库为“客观下线”了。这 3 张赞成票包括哨兵自己的一张赞成票和另外两个哨兵的赞成票。
在投票过程中,任何一个想成为 Leader 的哨兵,要满足两个条件:第一,拿到半数以上的赞成票;第二,拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值。以 3 个哨兵为例,假设此时的 quorum 设置为 2,那么,任何一个想成为 Leader 的哨兵只要拿到 2 张赞成票,就可以了。
如果这轮投票不会产生 Leader,哨兵集群会等待一段时间(也就是哨兵故障转移超时时间的 2 倍),再重新选举。这是因为,哨兵集群能够进行成功投票,很大程度上依赖于选举命令的正常网络传播。
需要注意的是,如果哨兵集群只有 2 个实例,此时,一个哨兵要想成为 Leader,必须获得 2 票,而不是 1 票。所以,如果有个哨兵挂掉了,那么,此时的集群是无法进行主从库切换的。因此,通常我们至少会配置 3 个哨兵实例。这一点很重要,你在实际应用时可不能忽略了。
六、小结
为了实现主从切换,我们引入了哨兵;为了避免单个哨兵故障后无法进行主从切换,以及为了减少误判率,又引入了哨兵集群;哨兵集群又需要有一些机制来支撑它的正常运行。
支持哨兵集群的这些关键机制,包括:
基于 pub/sub 机制的哨兵集群组成过程;
基于 INFO 命令的从库列表,这可以帮助哨兵和从库建立连接;
基于哨兵自身的 pub/sub 功能,这实现了客户端和哨兵之间的事件通知。
对于主从切换,当然不是哪个哨兵想执行就可以执行的,否则就乱套了。所以,这就需要哨兵集群在判断了主库“客观下线”后,经过投票仲裁,选举一个 Leader 出来,由它负责实际的主从切换,即由它来完成新主库的选择以及通知从库与客户端。
要保证所有哨兵实例的配置是一致的,尤其是主观下线的判断值 down-after-milliseconds。