Redis Sentinel架构解析：高可用实现与故障转移策略

RedisSentinel实现高可用

Sentinel结构

在Redis3.0之前的版本中，为了实现集群，通常使用sentinel工具来监控master节点的状态，如果master节点出现异常，就会进行主从切换，某个slave会被关闭用作主配置。
稍微复杂一点。
性能和高可用性各方面也都一般，尤其是主从切换瞬间访问中断的情况。
而且哨兵模式只有一个主节点对外提供服务，无法支持高并发。
并且单个主节点的内存不宜设置太大，否则持久化文件会过大，影响数据恢复或主从同步的效率。

Sentinel初始化

Sentinel是一种Redis高可用解决方案，一个由一个或多个Sentinel实例（instances）组成的Sentinel系统（system）可以监控一个或多个Redis主服务器以及它何时跟随从服务器。
被监控的主服务器进入离线状态，会自动将当前主服务器的一台从服务器升级为主服务器，然后将离线的主服务器设置为新主服务器的从节点。

Sentinel本身可以理解为一个特殊的Redis服务器，也可以通过redis-serverxxx.conf--sentinel来启动。

下面是我们实验环境中的Sentinel服务器和Redis服务器列表（由于所有实验都是在本机上进行，所以我们使用端口来区分多个服务，服务和端口大致如下）。
：

IP端口cluster127.0.0.16379Master127.0.0.16380Slave127.0.0.16381Slave127.0.0.126379Sentinel127.0.0.126380Sentinel127.0.0.126381Sentinel

首先我们找到Redis配置文件目录，并在redis-sentinel.conf文件中更改如下参数：

#sentinelportinback26381#niestorun后台master服务器，并有一个slave节点sentinelmonitormymaster127.0.0.163792

Sentinel启动命令就像如下：

redis-serverredis-sentinel-26379.conf--sentinelredis-serverredis-sentinel-26380。
conf--sentinelredis-serverredis-sentinel-26381.conf--sentinel

登录Sentinel节点，查询集群状态并使用info命令启动sentinel服务和其他redis服务不同的是，在启动过程中，不会加载RDB或AOF来恢复数据。

Sentinel与Redis服务之间的通信

命令连接，建立链路，接收主从服务器的响应（默认情况下，每10秒发送一次请求信息，获取节点状态，会是1故障转移期间每秒）一次，每秒向服务器节点发送一次PING命令，以查明服务是否在线）

订阅连接，用于订阅哨兵。
:hello到主服务器的通道

我们先在main中确认一下点击查询执行SUBSCRIBE__sentinel__:hello主节点服务的同步信息，我们可以通过查询从节点服务器上的同步信息INFO命令。

Sentinel之间的通信

用于监视同一个master/。
来自服务器的多个Sentinel负责生死，它们会每两秒向被监控服务器的sentinel:hello通道发送一次消息，宣告它们的存在。

Sentinel不会创建订阅连接并通过命令进行通信。
因为未知的Sentinel服务节点已经可以通过主/从服务器到达。

Sentinel检索Redis节点列表

Sentinel默认每10秒向master发送一次信息，并通过发送info命令和响应将信息检索到当前master。

#Serverrun_id:5e4d6e3ee147ff231d540ae2add485e906944f2a

...

复制

角色:masterconnected_slaves:2slave0:ip=127.0.0.1,port=127.0.0.1,port=6ate=在线，偏移=2712947，滞后=0slave1：ip=127.0.0.1，端口=6380，状态=在线，偏移=2712947，滞后=0master_replid：f2163cc41b43c20998a54c140467madc4177ster_replid2：000000000000000000000000000000000000000master_repl_offset：2713213second_repl_offset：-1repl_backlog_active：1repl_backlog_size：repl48576_backlog_first_byte_offset:1664638repl_backlog_histlen:1048576

....

通过分析主服务器的info命令，可以得到以下两方面的信息：1.服务器本身的信息，包括run_id记录服务器操作ID、服务器角色等1、第二个方面就是获取主服务器下的所有从服务器信息，如：`slave0:ip=127.0.0.1,port=6381,state=online,offset=2712947,lag=0`这样我们不需要在conf文件中配置从服务器信息，Sentinel可以自动检测到。
Sentinel从主服务器获取从服务器信息后，也会在10秒内向从服务器发送INFO命令，获取从服务器信息。
我们可以执行命令`redis-cli-h127.0.0.1-p6380info。
`获取以下信息```shell#Serverrun_id:7ef635af0d3e0b1d60d2776eba0a15883db06245...#Replicationrole:slavemaster_host:127.0.0.1master_port:6379master_link_status：upmaster_last_io_seconds_ago：0master_sync_in_progress：0slave_repl_offset：2779874slave_priority：100slave_read_only：1connected_slaves：0master_replid：f2163cc41b43c20998a54c14647ba5b106dc4677master_replid2：0000000000000000000000000000000000000000000master_repl_offset:2779874second_repl_offset:-1repl_backlog_active:1repl_backlog_size:1048576repl_backlog_first_byte_offset:1731299repl_backlog_histlen:1048576...

我们可以得到从结果中得到以下信息：

服务器运行Id?run_id

Servant角色

Master服务器信息master_host,master_port

Master-从服务器连接状态master_link_status

从服务器优先级slave_priority

从服务器的复制偏移量slave_repl_offset

服务下线

主观下线：a哨兵法官离线。
目标下线：主观下线后，会询问其他哨兵节点考虑是否应该下线。
主节点离线。

如何判断下线

sentinel配置文件中的down-by-millseconds选项指定了sentinel实例进入主观下线所需的时间，如果实例down-by-millseconds毫秒，则会继续如果Sentinel返回无效响应，Sentinel会修改该实例对应的实例结构体，并打开该结构体的flags属性中的SIR_S_DOWN标志，以表明该实例是主观的离线。
当超过半数的sentinel节点检测到某个redis节点离线时，判断集群中的节点真正离线，也称为目标离线

选择leader哨兵

当master节点目标发生后离线时，将进行哨兵选举，选出一个领导哨兵来执行redisentinel集群的故障转移。
前哨哨兵选择规则：

所有网守都可以选择。

每次选举后，无论选举是否成功，哨兵配置纪元（configurationepoch）都会递增一次

在每个配置纪元中，都会设置某个哨兵作为sentinel的本地管理器机会，并且本地管理器一旦设置，当前配置epoch就无法更改

任何检测到主服务器客观离线的sentinel都会请求其他sentinel注册本身作为本地LeadSentinel

该哨兵是本地LeadSentinel规则是先来，先发送到目的地的el发送的sentinel设置请求会先设置成功，后面的所有请求都会被拒绝

如果某个哨兵被超过半数的哨兵设置为本地主哨兵，则该哨兵将成为主哨兵

因为领先哨兵发电需要一半哨兵的支持，而领先哨兵在每个配置epoch智能设置一次，所以只会出现一个领先哨兵

如果没有在指定时间内生成主卫岗位后，将再次进行选拔，直至选出主卫为止。

故障转移

故障转移分为三步：

在离线主服务器下的所有服务器中，选择一个从服务器作为主服务器。

让断开连接的master下面的所有从服务器复制新的master。

将离线的主服务器设置为新主服务器的从服务器当旧主服务器重新上线时，它就成为新主服务器的从服务器。

选择新的主服务器

过滤从服务器

删除掉线的从服务器并确保它们都正常连接

删除所有5秒未连接列表中已响应sentileleader的info命令的服务器可以保证列表中剩余的从服务器正常通信

确保从服务器的数据是新的，主要是删除那些已连接的服务器是与主服务器断开连接的时间超过毫秒*10毫秒。
确保不会过早断开

最后，按照上面的过滤后，排序并选择优先级最高的。

-如果有多个优先级相同的从服务器，则考虑偏移量最大的从服务器，因为最大的偏移量表明存储的数据是最新的-如果仍然存在具有相同偏移服务器的从服务器，选择运行ID最小的从服务器更改从服务器的复制目标

当新的主服务器出现时，领先的Sentinel将允许其他服务器节点将数据复制到新的主节点通过发送？向从服务器发送saveof命令来完成此操作。

将旧的主服务器转换为从服务器

故障转移的最后一个操作是将断开连接的主服务器设置为新主服务的从服务器。

原文：https://juejin.cn/post/7098530049686503438

redis高可用实践之FAILOVER

服务可用性不仅增加了服务健康运行的时间，还提高了故障后恢复的速度。
要保证服务的高可用性，可以从软件质量、防错和容灾三个方面入手。
对于redis来说，软件的质量是有高度保证的，所以对于在线大规模的redis集群运维管理，我们基本上可以重点关注两个方面：防错和容灾。
虽然冗余集群本身具备自动主从容灾的能力，但有些情况仍然无法通过集群来很好的处理。
本文详细介绍了如何结合CLUSTERFAILOVER集群管理命令进一步提高Redis集群的可用性。

首先介绍一下CLUSTERFAILOVER命令：

该操作用于正常的主从切换，但如果主节点宕机，无法响应成功的请求，就会出现失败的结果。
您可以添加FORCE选项将故障转移连接到主断点。

集群failoverforce：当启用FORCE选项时，故障转移过程直接从上面的步骤4开始，这意味着跳过与旧master协商数据复制的过程。
可以快速进行主从切换。
不过这个过程仍然需要半领主们一致同意才能被选举为新的领主。
当一半主节点异常时，进程无法进行主从切换。

CLUSTERFAILOVERTAKEOVER：可以添加****TAKEOVER选项来处理一半主节点宕机的情况。
通过TAKEOVER选项，您可以直接更新状态并将最新配置更新发送到所有可达节点，而无需确认半主节点。
****

接下来介绍如何基于场景优化集群可用性。
发生故障，需要在本机上部署迁移过程包括以下内容。

如果旧机器在master上有实例，需要先将其角色更改为slave，然后进行迁移。
此时，可以向slave节点发送集群故障转移，将节点更改为奴隶。
然后删除它。

最理想的情况是在问题发生之前解决它，但这也仅此而已后期比较理想。
当某个节点宕机或者负载过高无法响应时，这种情况下可以通过强制FORCE选项添加主从切换，引入健康的从节点来快速恢复服务。

即使在线环境中部署时Redis主节点尽可能分布，但在某些情况下，一半的主节点仍然可能会失败：

即使rediscluster本身提供最大限度。
-可用性能力，在某些情况下仍然需要人工干预才能运行。