我们说完了简单的Redis集群模式
但是关于主库出现故障的时候,如何进行主从切换,我们还没有细说
即,在主库挂了之后,我们需要运行一个新的主库,比如说把从库切换到主库,将其当成主库
这就是Redis提供的哨兵机制,哨兵机制是主从切换的关键机制,解决了主从复制下的故障转移几个关键问题
Redis提供了哨兵机制,就是一个运行着的Reids进程
主要负责着Reids的监控 选主 和通知
首先是监控的流程,监控流程是指的哨兵进程会周期性的发送Ping命令,检测是否在线,如果规定时间内没有响应PING,就会标记为下线状态,开始进行切换
其次,会进行相关的主库选择,哨兵会在主库挂掉之后,将很多的从库中挑选合适的从库作为新的库
最后,哨兵通知其他的从库,进行执行replicaof命令,让其和新主库建立连接,进行数据复制
如果是集成了Reids的SDK,一般在连接集群之前,都会去哨兵拿对应的主库地址,这样,主库如果发生了改变,哨兵会通知客户端
那么,上面整体流程中,哨兵需要进行的决策有:
监控任务中的,主库状态判断
选主任务中,如何选择合适的主库
我们分别说上面的决策
1.主库状态判断
在哨兵中,自己做的决定叫做主观判断,即哨兵利用PING命令检测主从状态,如果PING超时了,会先标记为主观下线
在其中,如果主库出现了主观下线,那么是否要进行主从切换呢?
如果简单出现了主观下线就进行切换的话,后续的选主和通知操作都会带来额外的计算和通信开销
而主观评价又可能出现网络问题带来的误判情况
故哨兵防止主观判断带来的误判问题,哨兵引入了多实例的集群模式部署,称为哨兵集群,引入多个哨兵进行判断,避免因为单个哨兵网络状态不好,误判主库下线的情况,
这种时候,因为只有多个哨兵实例都判断主库已经下线了,主库才会下线,所以这时候的判断称为客观下线,因为主库已经成为一个客观事实了
而认为客观下线已经存在的判断依据就是大多数的哨兵实例认为下线了
而实际场景中,并不一定是大于半数的哨兵实例确认下线后,方可进行主从切换,具体触发主从切换的时机,可以由Redis管理员自行设定
第二个问题,如何选择新主库
在哨兵中,选择新主库的过程称为 筛选加打分,在多个从库中,按照一定的筛选条件,将不符合的从库去掉,然后按照一定的规则,给剩下的从库挨个打分,获取得分最高的从库作为新的主库
首先根据,从库的网络状态,进行筛选一次,比如断连的次数超过了一定的阈值,或者是ping的延迟
然后进行打分,根据多个维度进行打分,分别是从库的优先级,从库的复制进度和从库ID号
优先级涉及到用户设定,可以考虑给一个优先级高的从库打高分,如果有一个内存空间大的,优先级可以考虑高
然后是复制进度,利用从库的slave_repl_offset来作为打分项
最后是ID号,较小的得分越高
只要从库的得分最高,就是主库
那么,今天,我们说了哨兵机制,其实实现Reids不间断服务的重要保证
发生主库故障的时候,自动的主从切换时不间断服务的关键支撑
Redis的哨兵机制的运行,总共有三个步骤
监控主库的运行状态,判断主库是否下线
在主库下线后,选择新的主库
选出新的主库之后,通知从库和客户端
而且,为了避免在出发主从切换的时候出现误判的情况,哨兵往往采用多实例部署的情况,多个实例通过少数服从多数的原则,判断是否满足客观事实
于是今天的问题也是关于哨兵集群
哨兵集群中有实例挂了怎么办
哨兵集群中,得到主库客观下线后,由那个实例负责切换
切换过程中,客户端能否正常进行操作?如果想要操作,怎么办
1.对于哨兵集群内部的实例出现了宕机问题,其实可以很简单的使用Raft协议进行领导者的替换
2.由哪个实例负责切换,如果有领导者,可以交由哨兵集群的领导者.如果没有领导者,可以交由服务发起者来进行切换.
3.切换过程中,如果哨兵集群已经知道新选举的领导者是谁了,可以让客户端直接访问新的领导者进行读写请求,但是这样,所有的读写请求都压在新领导者身上,会不会导致新领导者性能出现情况
如果哨兵集群还没有选举出新的领导者,那么即使有取巧的方式去让客户端连接,也不建议.这也是一主多从集群的弊端