在redis中,根据不同架构方式可以有不同的故障转移方案。主要有通过sentinel和集群两种方式。

Sentinel架构模式

Sentinel是Redis高可用性的解决方案。在Redis主从架构中,当主服务器发生故障时,不能进行主备切换。而Sentinel产生就是为了完整redis的故障转移工作。

sentinel系统工作图如下:
【Redis】sentinel故障转移
在启动sentinel系统以后,sentinel系统会为其所监视的主从服务器创建命令连接和订阅连接。

  • 命令连接:用于向服务器发送命令,并接收命令回复。
  • 订阅连接:用于订阅服务器的_sentinel_:hello频道。为了发现未知的新sentinel

Sentinel实例直接则相互创建命令连接,通过命令连接可以向其他Sentinel实例进行信息交换。

通信

建立连接后,Sentinel会以每10s的频率通过命令连接向被监视的主服务器发送INFO命令,通过分析INFO命令的回复来获取主服务器当前信息(主服务本身信息以及从服务器的信息)。

主观下线和客观下线

在默认情况下,Sentinel会以每秒一次的频率向所有与它创建了命令连接的实例发送PING命令,并通过PIING命令的回复来判断实例是否在线。在down-after-millseconds选项指定的时间内若得不到有效回复,Sentinel会将当前实例进入主观下线状态。

当Sentinel将一个主服务器判定为主观下线状态时,为了确认这个服务器是否真的下线了,他会向同样监视这个服务器的其他Sentinel进行询问,看他们是否也认为该主服务器进入下线状态。当从其他Sentinel那里接收到足够数量已下线判断后,sentinel会将该主服务器判定为客观下线状态。

选举领头Sentinel

当一个主服务器被判定为客观下线以后,监视这个服务器的各个Sentinel会进行协商,选举出一个领头的Sentinel,并由领头Sentinel对下线主服务器进行故障转移。

每经过一次选举,无论选举成功还是失败,每隔sentinel实例的配置纪元都会自增1,每个新的纪元中,任何一个sentinel都有可能成为领头Sentinel。

选举过程:

1、当一个源Sentinel向另一个Sentinel发送SENTINEL is-master-down-by-addr<ip,port,epoch,runid>命令,命令中的runid可以为*,用于检测客观下线状态,为源sentinel的id时,则用于选举领头sentinel。

2、设置局部领头的Sentinel的规则是先到先得:最先向目标Sentinel发送设置要求的源Sentinel将称为目标Sentinel的局部领头Sentinel,而之后收到的所有设置要求都会被拒绝。

3、当收到目标sentinel的回复后,会检查回复中leader_epoch纪元是否和自己纪元配置相同,如果相同,则取出runid,如果和自己的runid相同,则说明源sentinel已经被目标sentinel选举为局部领头sentinel。

4、如果有某个Sentinel被半数以上的sentinel设置成局部领头sentinel,那么这个sentinel将成为领头sentinel。

5、如果在给定的时限内,没有一个sentinel被选举为领头sentinel,那么将再次进行选举,配置纪元+1,直到选举出领头sentinel。

故障转移

【Redis】sentinel故障转移
1、领头sentinel将从下线的主服务器的所有从服务器中根据一定规则挑选出一个从服务器,将其转换为主服务器。
向这个从服务器server2发送slave no one命令,将这个从服务器转换为主服务器。在发送完slaveof on one命令之后,领头sentinel会以每秒一次的频率向被升级的从服务器发送INFO命令,并观察回复后的role信息,当从slave变成master后,说明该server2从服务器已经顺利升级为主服务器了。

2、修改从服务器的复制目标
向其他两个从服务器发送slaveof<server2.ip,server2.port>命令,使得server2称为server3和server4的主服务器。让他们复制server2的数据。

3、当server1重新启动后,将旧的主服务器成为新的主服务器的从服务器
领头sentinel会向server1发送slaveof命令,使server2成为server1的主服务器。

以上便是sentinel进行故障转移的整个流程。sentinel在整个架构中起到了很好的监控和故障转移的作用。是redis实现高可用的方案之一。

分类:

技术点:

相关文章: