字节一面:Redis主节点宕机,如何处理?

2,575

今天跟大家聊下,如果Redis某个节点宕机了,要怎么处理?

我们知道,Redis集群一般采用主从模式,主节点负责写,从节点负责读。

从节点故障

从节点主要提供读服务,为了分摊主服务器压力,一般会有多个从节点。

如果是从节点故障,不算什么大问题,客户端把该故障节点屏蔽即可,仍可访问其他的主、从节点满足正常的业务功能。

主节点故障

如果是主节点宕机了,那就有点麻烦了,毕竟写操作是在主节点上,无法替代。

这时候,我们要干一件事,从所有的从库节点中挑选一台做为主节点。这里要介绍下Sentienl 哨兵机制了。

哨兵机制分为三个阶段:

1、监控。哨兵进程会周期给所有的主库、从库发送 PING 命令,检测机器是否处于服务状态。如果没有在设置时间内收到回复,则判定为下线。

2、选主。主要是看各个节点的打分情况,打分规则分为 从库优先级、从库复制进度、从库ID号。只要有一轮,某个从库得分最高,则选举它为主库。

从库优先级,主要是考虑到不同的机器可能配置不一样,配置高的机器,优先级高一些,通过slave-priority 来配置

从库复制进度,主要是看slave_repl_offset 的值大小,值越大表示已经同步的数据越多,得分越高。

从库ID号,每个Redis 实例启动时,都会生成一个 ID,在优先级和复制进度相同的条件下,ID号最小的从库分数最高,会被选为新主库。

3、通知。把选举后的新主库发送给所有节点,让所有的从库执行 replicaof 命令,和新 master建立主从关系、数据同步复制。另外,也会把最新的主库信息同步给客户端。这样后续的写请求会打到新的 主节点上。

我们知道网络存在不稳定性,所以会不会有什么特殊问题?我们继续往下看

网络抖动,引发误判

问题描述:

哨兵节点监控到主节点超时未响应,主节点不一定是真的宕机。可能是之间的网络拥堵,或者主库自身压力过大,导致响应超时。

如何避免这种情况?

引入哨兵集群,多个哨兵实例一起判断,降低误判率。判断标准就是,假如 n 个哨兵实例,至少有 n/2+1 个判定一致,才可以定论。

注意:

上面的误判只会用在主库,从库只是负责读,如果监测到未响应,直接标记为 ”下线“,并不需要集群投票验证其真实性。

如果是主库超时未响应,则不能这么草率决定,毕竟后面的选主和通知都是一笔不小的开销,所以,标记主库”下线“,一定要慎之又慎。

那么,哨兵集群集如何投票,确认主节点是否真的下线呢?在深入这个问题之前,我们先来了解下哨兵集群

哨兵集群如何构建?

首先,在redis-sentinel 的conf文件里添加两个配置项:

sentinel monitor
master-name:对某个master+slave 组合的一个区分标识(一套sentinel是可以监听多套master+slave这样的组合)

ip 和 port:就是master节点的 ip 和 端口号。

quorum:进行客观下线的一个依据,意思是至少有 quorum 个sentinel主观的认为这个master有故障,才会对这个master下线或故障转移。

sentinel down-after-milliseconds
timeout:毫秒值,如果这台sentinel超过timeout时间无法连通master或slave(slave不需要客观下线,因为不需要故障转移),就会主观认为该master已经下线(实际下线需要客观下线的判断通过才会真正下线)

借助发布/订阅组建哨兵集群

我们知道Redis 有pub/sub 机制,当一个哨兵与主库建立连接,可以在主库上发布自己的消息(ip、port),当然也可以在主库上订阅其他哨兵发布的消息。

有点类似MQ的topic味道,大家基于同一个topic完成数据交换。

当所有的哨兵都完成上述动作,哨兵集群也就组建完成。

为什么要组建哨兵集群呢?因为后面的选主需要有一个leader带头操作。

哨兵如何知道所有从库地址呢?

我们知道每个哨兵实例的配置参数里有配置主库的ip和port,而每个主库要同步数据给从库,自然有挂载的所有从库信息。

所以,哨兵实例只需向主库发送INFO命令即可获取到所需要的信息,然后哨兵实例在依次与从库建立连接。

至此,一个哨兵实例便可以收集到整个Redis 集群的数据,包含三块:

所有的哨兵节点ip、port
主节点ip、port
主节点挂载的所有从节点的 ip、port
其他哨兵实例也是一样道理,这里就不在赘述了。

哨兵是个集群,选主需要有个带头大哥

当一个哨兵实例监控到主库”主观下线“后,给其他实例发送 is-master-down-by-addr 命令,其他哨兵实例根据自己与主库的连接情况,做出 Y 或 N的回复。

当这个哨兵收集到了超过 quorum 配置项的 Y 回复后,就会标记主库”客观下线“。

下面,就要进入选主阶段了。正所谓”一山不容二虎“,那么由哪个哨兵实例来执行选主操作呢?

还是公平点,采用民主投票。先在 哨兵集群中选出一个带头大哥,由它代表大家执行后续操作。

如何选哨兵Leader?

上图画了个流程实例,三个哨兵节点在 t1~t6 不同时刻点的投票情况。

当一个哨兵实例收到超过 设置的quorum 票Y后,它会成为新的Leader。然后由它(哨兵S3)负责后面的从库选主,通知从库与新主库建立关系并同步数据,通知客户端访问新主库。

如果本轮没有选出Leader节点,等哨兵故障转移超时时间的 2 倍时间后,重新发起新一轮选举。

为了保证哨兵Leader选举的顺利进行,除了对网络质量有要求外,最好配置奇数个哨兵节点且最好三个以上。

哨兵也是实例,如果挂了怎么办?

哨兵主要是用来监控Redis集群的健康状况,本身并不提供服务。

当一个哨兵实例挂掉后,会影响到集群的监测。为了降低影响,我们引入哨兵集群,降低单点风险,由哨兵集群保障Redis主从集群的健康。

举个例子:

哨兵集群配置了三个实例,quorum 配置值为2。当一个哨兵实例宕机后,其余两个哨兵实例依然可以完成选举,只是可能存在一定风险而已。

哨兵集群完成了主从切换,客户端如何感知?

我们知道Redis有pub/sub机制,为了便于外部知道当前的切换进度,哨兵提供了多个订阅频道。

其中就有一个新主库切换频道,(switch-master)

SUBSCRIBE +switch-master
订阅对应频道,可以获得切换后的新主库ip、port,并与之建立连接,继续享受Redis服务。