字节一面：Redis主节点宕机，如何处理？

今天跟大家聊下，如果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> <ip> <redis-port> <quorum> 

• master-name：对某个master+slave 组合的一个区分标识（一套sentinel是可以监听多套master+slave这样的组合）
• ip 和 port：就是master节点的 ip 和 端口号。
• quorum：进行客观下线的一个依据，意思是至少有 quorum 个sentinel主观的认为这个master有故障，才会对这个master下线或故障转移。

sentinel down-after-milliseconds <master-name>  <timeout>

• 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服务。