Redis中sentinel故障转移的示例分析

这篇文章主要为大家展示了“Redis中sentinel故障转移的示例分析”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让小编带领大家一起研究并学习一下“Redis中sentinel故障转移的示例分析”这篇文章吧。当两台以上的Redis实例形成了主备关系，它们组成的集群就具备了一定的高可用性：当master发生故障的时候，slave可以成为新的master对外提供读写服务，这种运营机制成为failover。那么谁来发现master的故障做failover决策？一种方式是，保持一个daemo进程，监控着所有的master-slave节点，如下图所示：一个Redis集群里面有一个master和两个slave，这个daemon进程监控着这三个节点。但daemon为单节点，本身可用性无法保证。需要引入多daemon，如下图所示：多个daemon解决了可用性问题，但又出现了一致性问题，如何就某个master是否可用达成一致？例如上图两个daemon1和和master网络不通，daemon和master连接畅通，那此时mater节点是否需要failover那？Redis的sentinel提供了一套多daemon间的交互机制，多个daemon间组成一个集群，成为sentinel集群，daemon节点也称为sentinel节点。如下图所示：这些节点相互间通信、选举、协商，在master节点的故障发现、failover决策上表现出一致性。sentinel集群监视任意多个master以及master下的slave，自动将下线的master从其下的某个slave升级为新的master代替继续处理命令请求。启动一个Sentinel可以使用命令：或者命令：当一个Sentinel启动时，它需要执行以下步骤：初始化服务器Sentinel本质上是运行在特殊模式下的Redis服务器，它和普通的Redis服务器执行的工作不同，初始化过程也不完全相同。如普通的Redis服务器初始化会载入RDB或者AOF文件来恢复数据，而Sentinel启动时不会载入，因为Sentinel并不使用数据库。将普通Redis服务器使用的代码替换成Sentinel专用代码将一部分普通Redis服务器使用的代码替换成Sentinel专用代码。如普通Redis服务器使用server.c/redisCommandTable作为服务器的命令表：Sentinel使用sentinel.c/sentinelcmds作为服务器列表，如下所示：初始化Sentinel状态服务器会初始化一个sentinel.c/sentinelState结构（保存服务器中所有和Sentinel功能有关的状态）。根据给定的配置文件，初始化Sentinel的监视主服务器列表对Sentinel状态的初始化将引发对masters字典的初始化，而master字典的初始化是根据被载入的Sentinel配置文件来进行的。字典的key是监视主服务器的名字，字典的值则是被监控主服务器对应的sentinel.c/sentinelRedisInstance结构。sentinelRedisInstance结构部分属性如下：例如启动Sentinel时，配置了如下的配置文件：则Sentinel则会为主服务器master1创建如下图所示的实例结构：Sentinel状态以及masters字典的机构如下：创建连向主服务器的网络连接创建连向被监视主服务器的网络连接，Sentinel将成为主服务器的客户端，向主服务器发送命令并从命令回复获取信息。Sentinel会创建两个连向主服务器的异步网络连接：命令连接，用于向主服务器发送命令并接收命令回复订阅连接，订阅主服务器的_sentinel_:hello频道Sentinel默认会以每十秒一次的频率，通过命令连接向被监视的master和slave发送INFO命令。通过master的回复可获取master本身信息，包括run_id域记录的服务器运行ID，以及role域记录的服务器角色。另外还会获取到master下的所有的从服务器信息，包括slave的ip地址和port端口号。Sentinel无需用户提供从服务器的地址信息，由master返回的slave的ip地址和port端口号，可以自动发现slave。当Sentinel发现master有新的slave出现时，Sentinel会为这个新的slave创建相应的实例外，Sentinel还会创建到slave的命令连接和订阅连接。根据slave的INFO命令的回复，Sentinel会提取如下信息：1.slave的运行ID run_id2.slave的角色role3.master的ip地址和port端口4.master和slave的连接状态master_link_status5.slave的优先级slave_priority6.slave的复制偏移量slave_repl_offsetSentinel在默认情况下会以每两秒一次的频率，通过命令连接向所有被监视的master和slave的_sentinel_:hello频道发送一条信息发送以下格式的命令：以上命令相关参数意义：Sentinel与master或者slave建立订阅连接之后，Sentinel就会通过订阅连接发送对_sentinel_:hello频道的订阅,订阅会持续到Sentinel与服务器的连接断开为止命令如下所示：SUBSCRIBE sentinel:hello如上图所示，对于每个与Sentinel连接的服务器 ，Sentinel既可以通过命令连接向服务器频道_sentinel_:hello频道发送信息，又通过订阅连接从服务器的_sentinel_:hello频道接收信息。sentinel间会相互感知，新加入的sentinel会向master的_sentinel_:hello频道发布一条消息，包括自己的消息，其它该频道订阅者sentinel会发现新的sentinel。随后新的sentinel和其它sentinel会创建长连接。相互连接的各个Sentinel可以进行信息交换。Sentinel为master创建的实例结构中的sentinels字典保存了除Sentinel本身之外，所有同样监视这个主服务器的其它Sentinel信息。前面也讲到sentinel会为slave创建实例（在master实例的slaves字典中）。现在我们也知道通过sentinel相互信息交换，也创建了其它sentinel的实例（在master实例的sentinels字典中）。我们将一个sentinel中保存的实例结构大概情况理一下，如下图所示：从上图可以看到slave和sentinel字典的键由其ip地址和port端口组成，格式为ip:port,其字典的值为其对应的sentinelRedisInstance实例。主观不可用默认情况下Sentinel会以每秒一次的频率向所有与它创建了命令连接的master（包括master、slave、其它Sentinel）发送PING命令，并通过实例返回的PING命令回复来判断实例是否在线。PING命令回复分为下面两种情况：有效回复：实例返回 +PONG、-LOADING、-MASTERDOWN三种回复的一种无效回复：除上面有效回复外的其它回复或者在指定时限内没有任何返回Sentinel配置文件中的设置down-after-milliseconds毫秒时效内(各个sentinel可能配置的不相同)，连续向Sentinel返回无效回复，那么sentinel将此实例置为主观下线状态，在sentinel中维护的该实例flags属性中打开SRI_S_DOWN标识，例如master如下所示：客观不可用在sentinel发现主观不可用状态后，它会将“主观不可用状态”发给其它sentinel进行确认，当确认的sentinel节点数>=quorum，则判定该master为客观不可用，随后进入failover流程。上面说到将主观不可用状态发给其它se免费云主机域名ntinel使用如下命令：各个参数的意义如下：ip：被sentinel判断为主观下线的主服务器的ip地址port: 被sentinel判断为主观下线的主服务器的port地址current_epoch:sentinel的配置纪元，用于选举领头Sentinelrunid：可以为*号或者Sentinel的运行ID，*号代表检测主服务器客观下线状态。Sentinel的运行ID用于选举领头Sentinel接受到以上命令的sentinel会反回一条包含三个参数的Multi Bulk回复：1）down_state> 目标sentinel对该master检查结果，1:master已下线 2:master未下线2）leader_runid> 两种情况，*表示仅用于检测master下线状态 ，否则表示局部领头Sentinel的运行ID（选举领头Sentinel）3）leader_epoch> 当leader_runid为时，leader_epoch始终为0。不为时则表示目标Sentinel的局部领头Sentinel的配置纪元（用于选举领头Sentinel）其中节点数量限制quorum为sentinel配置文件中配置的quorum选项，不同的sentinel配置的可能不相同。当sentinel认为master为客观下线状态，则会将master属性中的flags的SRI_O_DOWN标识打开，例如master如下图所示：当一台master宕机时，可能多个sentinel节点同时发现并通过交互确认相互的“主观不可用状态”，同时达到“客观不可用状态”，同时打算发起failover。但最终只能有一个sentinel节点作为failover发起者，那么就需要选举出Sentinel Leader，需要开始一个Sentinel Leader选举过程。Redis的Sentinel机制采用类似于Raft协议实现这个选举算法：1.sentinelState的epoch变量类似于raft协议中的term（选举回合）。2.每一个确认了master“客观不可用”的sentinel节点都会向周围广播自己的参选请求(SENTINEL is-master-down-by-addr ,current_epoch为自己的配置纪元，run_id为自己的运行ID)3.每一个接收到参选请求的sentinel节点如果还没接收到其它参选请求，它就将本回合的意向置为首个参选sentinel并回复它（先到先得）；如果已经在本回合表过意向了，则拒绝其它参选，并将已有意向回复（如上所介绍的三个参数的Multi Bulk回复，down_state为1，leader_runid为首次接收到的发起参选请求的源sentinel的运行ID，leader_epoch为首次接收到的发起参选请求的源sentinel的配置纪元）4.每个发起参选请求的sentinel节点如果收到超过一半的意向同意某个参选sentinel（可能是自己），则确定该sentinel为leader。如果本回合持续了足够长时间未选出leader，则开启下一个回合leader sentinel 确定之后，leader sentinel从master所有的slave中依据一定规则选取一个作为新的master。在选举出Sentinel Leader之后，sentinel leader对已下线master执行故障转移：sentinel leader对已下线的master的所有slave中，选出一个状态良好、数据完整的slave，然后向这个slave发送:SLAVEOF no one 命令，将这个slave转换为master。我们来看下新的master是怎么挑选出来的？Sentinel leader会将已下线的所有slave保存到一个列表，然后按照以下规则过滤筛选：优先级最高的slave，redis.conf配置中replica-priority选项来标识，默认为100，replica-priority较低的优先级越高。0为特殊优先级，标志为不能升级为master。如果存在多个优先级相等的slave，则会选择复制偏移量(offset)最大的slave(数据更加完整)如果存在多个优先级相等，最大复制偏移量最大的slave，则选择运行ID最小的slave选出需要升级为新的master的slave后，Sentinel Leader会向这个slave发送SLAVEOF no one 命令。之后Sentinel会以每秒一次频率(平时是十秒一次)向被升级slave发送INFO，当回复的role由slave变为master时Sentinel Leader就会知道已升级为master。sentinel leader 向已下线的master属下的slave发送SLAVEOF命令(SLAVEOF )，去复制新的master。将旧的master设置为新的master的slave，并继续对其监视，当其重新上线时Sentinel会执行命令让其成为新的master的slave。以上是“Redis中sentinel故障转移的示例分析”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注百云行业资讯频道！

相关推荐: mongodb 中有哪些备份恢复命令

这篇文章给大家介绍mongodb 中有哪些备份恢复命令，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。备份：mongodump -uroot -ppassword –port=27017 –authenticationDatabase=…