redis 哨兵
3.1 哨兵简介
3.1.1 哨兵概念
首先我们来看一个业务场景:如果redis的master宕机了,此时应该怎么办?
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-C1L7ZbSw-1630566614350)(./img/16.png)]
那此时我们可能需要从一堆的slave中重新选举出一个新的master,那这个操作过程是什么样的呢?这里面会有什么问题出现呢?
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qTrjaQtg-1630566614351)(./img/17.png)]
要实现这些功能,我们就需要redis的哨兵,那哨兵是什么呢?
哨兵
哨兵(sentinel) 是一个分布式系统,用于对主从结构中的每台服务器进行监控,当出现故障时通过投票机制选择新的master并将所有slave连接到新的master。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MdyVHhI1-1630566614353)(./img/18.png)]
3.1.2 哨兵作用
哨兵的作用:
-
监控:监控master和slave
不断的检查master和slave是否正常运行
master存活检测、master与slave运行情况检测
-
通知(提醒):当被监控的服务器出现问题时,向其他(哨兵间,客户端)发送通知
-
自动故障转移:断开master与slave连接,选取一个slave作为master,将其他slave连接新的master,并告知客户端新的服务器地址
注意:哨兵也是一台redis服务器,只是不提供数据相关服务,通常哨兵的数量配置为单数
3.2 启用哨兵
配置哨兵
-
配置一拖二的主从结构(利用之前的方式启动即可)
-
配置三个哨兵(配置相同,端口不同),参看sentinel.conf
1:设置哨兵监听的主服务器信息, sentinel_number表示参与投票的哨兵数量
sentinel monitor master_name master_host master_port sentinel_number
2:设置判定服务器宕机时长,该设置控制是否进行主从切换
sentinel down-after-milliseconds master_name million_seconds
3:设置故障切换的最大超时时
sentinel failover-timeout master_name million_seconds
4:设置主从切换后,同时进行数据同步的slave数量,数值越大,要求网络资源越高,数值越小,同步时间越长
sentinel parallel-syncs master_name sync_slave_number
- 启动哨兵
redis-sentinel filename
3.3 哨兵工作原理
哨兵在进行主从切换过程中经历三个阶段
- 监控
- 通知
- 故障转移
3.3.1 监控
用于同步各个节点的状态信息
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cgDqfJQG-1630566614355)(./img/19.png)]
-
获取各个sentinel的状态(是否在线)
-
获取master的状态
master属性
prunid
prole:master
各个slave的详细信息
- 获取所有slave的状态(根据master中的slave信息)
slave属性
prunid
prole:slave
pmaster_host、master_port
poffset
其内部的工作原理具体如下:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nDjQ1rtc-1630566614356)(./img/20.png)]
3.3.2 通知
sentinel在通知阶段要不断的去获取master/slave的信息,然后在各个sentinel之间进行共享,具体的流程如下:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YcpfLkDA-1630566614357)(./img/21.png)]
3.3.3 故障转移
当master宕机后sentinel是如何知晓并判断出master是真的宕机了呢?我们来看具体的操作流程
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uqjU5P2K-1630566614357)(./img/22.png)]
当sentinel认定master下线之后,此时需要决定更换master,那这件事由哪个sentinel来做呢?这时候sentinel之间要进行选举,如下图所示:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mmNoQaR4-1630566614357)(./img/23.png)]
在选举的时候每一个人手里都有一票,而每一个人的又都想当这个处理事故的人,那怎么办?大家就开始抢,于是每个人都会发出一个指令,在内网里边告诉大家我要当选举人,比如说现在的sentinel1和sentinel4发出这个选举指令了,那么sentinel2既能接到sentinel1的也能接到sentinel4的,接到了他们的申请以后呢,sentinel2他就会把他的一票投给其中一方,投给谁呢?谁先过来我投给谁,假设sentinel1先过来,所以这个票就给到了sentinel1。那么给过去以后呢,现在sentinel1就拿到了一票,按照这样的一种形式,最终会有一个选举结果。对应的选举最终得票多的,那自然就成为了处理事故的人。需要注意在这个过程中有可能会存在失败的现象,就是一轮选举完没有选取,那就会接着进行第二轮第三轮直到完成选举。
接下来就是由选举胜出的sentinel去从slave中选一个新的master出来的工作,这个流程是什么样的呢?
首先它有一个在服务器列表中挑选备选master的原则
-
不在线的OUT
-
响应慢的OUT
-
与原master断开时间久的OUT
-
优先原则
优先级
offset
runid
选出新的master之后,发送指令( sentinel )给其他的slave:
-
向新的master发送slaveof no one
-
向其他slave发送slaveof 新masterIP端口
总结:故障转移阶段
- 发现问题,主观下线与客观下线
- 竞选负责人
- 优选新master
- 新master上任,其他slave切换master,原master作为slave故障恢复后连接