哨兵模式(sentinel)
当我们使用主从复制时,从库宕机依然可以将请求发送给主库或者其他从库,但是 Master 宕机,只能响应读操作,写请求无法再执行。所以主从复制架构面临一个严峻问题,主库挂了,无法执行「写操作」,无法自动选择一个 Slave 切换为 Master,也就是无法故障自动切换。
哨兵是Redis的高可用性解决方案:由一个或多个Sentinel实例组成的Sentinel系统,可以监视任意多个主服务器,以及这些主服务器属下的所有从服务器,并在被监视的主服务器进入下线状态时,自动将下线主服务器属下的某个从服务器升级为新的主服务器,然后由新的主服务器代替 已下线的主服务器继续处理命令请求。
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uXujSl5j-1660639930830)(E:/Blog/lansg/source/img/image-20220509104348083.png)]](https://i-blog.csdnimg.cn/blog_migrate/685f1fcbea01af38d453b5ca226a043e.png)
哨兵功能主要有以下几点:
- 监控:哨兵会不断地检查主节点和从节点是否运作正常。
- 自动故障转移(核心功能):当主节点不能正常工作时,哨兵会开始自动故障转移操作,它会将失效主节点的其中一个从节点升级为新的主节点,并让其他从节点改为复制新的主节点。
- 配置提供者:客户端(从节点)在初始化时,可以通过连接哨兵来获得当前Redis服务的主节点地址。
- 通知:哨兵可以将故障转移的结果发送给客户端。
哨兵也是一个 Redis 进程,只是不对外提供读写服务,通常哨兵要配置成单数。
一、哨兵集群的组建
哨兵实例之间可以相互发现,要归功于 Redis 提供的 pub/sub 机制,也就是发布 / 订阅机制。
在主从集群中,主库上有一个名为__sentinel__:hello的频道,不同哨兵就是通过它来相互发现并互相通信的。在下图中,哨兵 1 把自己的 IP(172.16.19.3)和端口(26579)发布到__sentinel__:hello频道上,哨兵 2 和 3 订阅了该频道。那么此时,哨兵 2 和 3 就可以从这个频道直接获取哨兵 1 的 IP 地址和端口号。然后,哨兵 2、3 可以和哨兵 1 建立网络连接。同理哨兵2.3也可以建立连接,从而形成哨兵集群。
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6eLDs4lB-1660639930832)(E:/Blog/lansg/source/img/image-20220509105128468.png)]](https://i-blog.csdnimg.cn/blog_migrate/8855ee9472c24adf6b7d9cbb7c154bb2.png)
二、哨兵监控redis库
哨兵对主从库的监控,是通过哨兵向主库发送
INFO命令来完成的。
哨兵给主库发送INFO命令,主库接受到这个命令后,就会把从库列表返回给哨兵。接着,哨兵就可以根据从库列表中的连接信息,和每个从库建立连接,并在这个连接上持续地对从库进行监控。
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XAvDEEuV-1660639930832)(E:/Blog/lansg/source/img/image-20220509105641440.png)]](https://i-blog.csdnimg.cn/blog_migrate/6e21e7d1b16ee5dab5497da4d2c7851c.png)
三、主库下线的判定
哨兵如何判断主库是否下线了呢?首先要明白主观下线和客观下线两个概念。
- 主观下线:任何一个哨兵都是可以监控探测,并作出Redis节点下线的判断;
- 客观下线:有哨兵集群共同决定Redis节点是否下线;
也就是说,每一个哨兵会自己做出判断(主观下线),最后共同决定主库是否已经下线(客观下线)。
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tkg0SlDg-1660639930833)(E:/Blog/lansg/source/img/image-20220509110213524.png)]](https://i-blog.csdnimg.cn/blog_migrate/acad96af2c16f3d8cf8cdc5c6bad1a69.png)
哨兵通过ping命令来检测master和slave的状态,如果收到的是无效回复,则标记当前节点为**「主观下线」**。
当哨兵2判断主库**「主观下线」后,就会给其他哨兵发送 is-master-down-by-addr 命令。接着,其他哨兵会根据自己和主库的连接情况,做出 Y 或 N 的响应,Y 相当于赞成票,N 相当于反对票。赞成票数(这里是2)是大于等于哨兵配置文件中的 quorum 配置项**(比如quorum=2), 则可以判定**主库「客观下线」了。其实就是判定「主观下线」的票数要过半,就认为「客观下线」**了。
只有 master 被判定为**「客观下线」**,才会进一步触发哨兵开始主从切换流程。
四、新主库的选出
主库下线之后,如何从剩余从库中选取一个作为新主库呢?
- 过滤掉不健康的(下线或断线),没有回复过哨兵ping响应的从节点。
- 选择
salve-priority从节点优先级最高(redis.conf中)的。 - 选择复制偏移量最大,也就是复制之前主节点数据最完整的从节点。
选出新主库之后,哨兵要将新主库的信息发送给其他从节点以及客户端,也就是将读写请求转移到新的master。这个操作称为主从切换,需要从哨兵集群中选出一个哨兵来执行此操作。
五、哨兵集群的选举
主库下线后,需要有一个节点(leader)执行主从切换,这个执行操作的节点是由集群选举产生的。
- 选举机制:通过Raft选举算法实现。 选举的票数大于等于num(sentinels)/2+1且大于等于哨兵配置文件中的 quorum 值时(两个条件缺一不可),将成为领导者,否则继续选举。
一个栗子:Redis 1主4从,5个哨兵,哨兵配置quorum为2,如果3个哨兵故障,当主库宕机时,哨兵能否判断主库“客观下线”?能否主从切换?
**(1)可以判定主库“客观下线“。**两个哨兵都判定”主观下线“,达到了quorum的值。
**(2)不可以主从切换。**要进行切换,得到选举的票数必须大于等于5/2+1=3。
六、故障的转移
假设sentinel3为leader:
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KqeQKIml-1660639930833)(E:/Blog/lansg/source/img/image-20220509112932998.png)]](https://i-blog.csdnimg.cn/blog_migrate/e2b33b9c18f133c812ed0028d18ea405.png)
(1)将slave-1脱离原从节点,升级主节点。
(2)将从节点slave-2指向新的主节点(slave-1)。
(3)通知客户端主节点已更换。
(4)将原主节点(master)变成从节点,指向新的主节点(slave-1)。
转移后:
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MV0tHVqN-1660639930833)(E:/Blog/lansg/source/img/image-20220509113138508.png)]](https://i-blog.csdnimg.cn/blog_migrate/188327d48c1c46d3378a064868c3e114.png)
通过 pub/sub 机制发布不同事件,客户端可以订阅哨兵的消息。哨兵提供的消息订阅频道有很多,不同频道包含了主从库切换过程中的不同关键事件。
Redis哨兵是其高可用性解决方案,负责监控、故障转移、配置提供和通知。哨兵通过监控主从节点的INFO命令来判断运行状况,当主观下线和客观下线达成一致时,会执行主从切换。切换过程包括选择健康从节点作为新主,更新其他从节点和客户端配置,并通过发布/订阅机制通知。选举过程采用Raft算法,确保领导者安全。
6330

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



