上节课,我们学习了哨兵机制,它可以实现主从库的自动切换。通过部署多个实例,就形成了一个哨兵集群。哨兵集群中的多个实例共同判断,可以降低对主库下线的误判率。
但是,我们还是要考虑一个问题:如果有哨兵实例在运行时发生了故障,主从库还能正常切换吗?
实际上,一旦多个实例组成了哨兵集群,即使有哨兵实例出现故障挂掉了,其他哨兵还能继续协作完成主从库切换的工作,包括判定主库是不是处于下线状态,选择新主库,以及通知从库和客户端。
如果你部署过哨兵集群的话就会知道,在配置哨兵的信息时,我们只需要用到下面的这个配置项,设置主库的IP和端口,并没有配置其他哨兵的连接信息。
sentinel monitor <master-name> <ip> <redis-port> <quorum>
这些哨兵实例既然都不知道彼此的地址,又是怎么组成集群的呢?要弄明白这个问题,我们就需要学习一下哨兵集群的组成和运行机制了。
基于pub/sub机制的哨兵集群组成
哨兵实例之间可以相互发现,要归功于Redis提供的pub/sub机制,也就是发布/订阅机制。
哨兵只要和主库建立起了连接,就可以在主库上发布消息了,比如说发布它自己的连接信息(IP和端口)。同时,它也可以从主库上订阅消息,获得其他哨兵发布的连接信息。当多个哨兵实例都在主库上做了发布和订阅操作后,它们之间就能知道彼此的IP地址和端口。
除了哨兵实例,我们自己编写的应用程序也可以通过Redis进行消息的发布和订阅。所以,
本文介绍了Redis哨兵集群的工作原理,即使哨兵实例出现故障,集群仍能维持主从库的正常切换。哨兵通过pub/sub机制互相发现并建立连接,监控主从库状态,并通过INFO命令获取从库信息。哨兵通过频道向客户端发送事件通知,客户端订阅相关事件以了解切换进度。当主库下线,哨兵集群通过投票仲裁选出 Leader 执行主从切换。确保所有哨兵配置一致,特别是down-after-milliseconds,以避免影响集群稳定性。
订阅专栏 解锁全文
1330

被折叠的 条评论
为什么被折叠?



