| title |
|---|
Redis主节点宕机，要如何处理？ |
作者：Tom哥
公众号：微观技术
博客：https://offercome.cn
人生理念：知道的越多，不知道的越多，努力去学
今天跟大家聊下，如果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 回复后，就会标记主库”客观下线“。
下面，就要进入选主阶段了。正所谓”一山不容二虎“，那么由哪个哨兵实例来执行选主操作呢？
还是公平点，采用民主投票。先在 哨兵集群中选出一个带头大哥，由它代表大家执行后续操作。
上图画了个流程实例，三个哨兵节点在 t1~t6 不同时刻点的投票情况。
当一个哨兵实例收到超过 设置的quorum 票Y后，它会成为新的Leader。然后由它（哨兵S3）负责后面的从库选主，通知从库与新主库建立关系并同步数据，通知客户端访问新主库。
如果本轮没有选出Leader节点，等哨兵故障转移超时时间的 2 倍时间后，重新发起新一轮选举。
为了保证哨兵Leader选举的顺利进行，除了对网络质量有要求外，最好配置奇数个哨兵节点且最好三个以上。
哨兵主要是用来监控Redis集群的健康状况，本身并不提供服务。
当一个哨兵实例挂掉后，会影响到集群的监测。为了降低影响，我们引入哨兵集群，降低单点风险，由哨兵集群保障Redis主从集群的健康。
举个例子：
哨兵集群配置了三个实例，quorum 配置值为2。当一个哨兵实例宕机后，其余两个哨兵实例依然可以完成选举，只是可能存在一定风险而已。
我们知道Redis有pub/sub机制，为了便于外部知道当前的切换进度，哨兵提供了多个订阅频道。
其中就有一个新主库切换频道，（switch-master）
SUBSCRIBE +switch-master
订阅对应频道，可以获得切换后的新主库ip、port，并与之建立连接，继续享受Redis服务。