Redis高可用之哨兵架构实战

最新推荐文章于 2024-06-24 00:15:38 发布

JavaDevOps技术栈

最新推荐文章于 2024-06-24 00:15:38 发布

阅读量596

点赞数

分类专栏： Redis

本文链接：https://blog.csdn.net/xiaolinzi176/article/details/123166788

版权

Redis 专栏收录该内容

7 篇文章 3 订阅

订阅专栏

系列文章目录

真正说透Redis五种数据结构
 Redis持久化之RDB+AOF+混合持久化实战演练
 Redis高可用之主从架构

前言

Redis在主从虽然可以在一定程度上通过读写分离提高Redis的性能，包括数据的拷贝备份，但是如果主节点宕机，需要人工去处理，这一过程会导致业务可能长时间不可用，所有在主从架构的基础上，使用哨兵架构就可以完成故障自动切换，本文主要介绍哨兵架构的原理以及实战过程中存在的问题。有关哨兵的搭建请查看Redis安装哨兵架构，包括主从安装和主从同步原理请查看系列文章

一、实战过程中存在的问题

1、从节点无法加入哨兵集群（已解决）

由于一台哨兵集群可以监控多个Redis主从架构，所有在配置中，每套监控的mastername需要一致，如下，一套哨兵监控两个主节点

# 第一个主节点
sentinel monitor master001 121.36.172.25 6379 2
sentinel auth-pass master001 qwer123456
sentinel down-after-milliseconds master001 10000
sentinel parallel-syncs master001 1
sentinel failover-timeout master001 180000
# 第二个主节点
sentinel monitor master002 122.112.237.126 6379 2
sentinel auth-pass master002 qwer123456
sentinel down-after-milliseconds master002 10000
sentinel parallel-syncs master002 1
sentinel failover-timeout master002 180000

在这里插入图片描述

2、主从切换后，旧主重启后无法加入（已解决）

主从故障切换，旧的主节点重启后无法加入新的主节点下从连接，显示认证失败，所以在旧主节点redis.conf下配置新主的密码（主从下密码应该一致）
在这里插入图片描述

3、哨兵之间无法通信（已解决）

由于安装使用的是容器，在启动哨兵后发现暴露的是容器内的ip.
在这里插入图片描述
官方文档上也有说明，需要在每个sentinel节点的配置文件中暴露当前通信ip+port

4、主从切换后没有修改配置文件（未解决）

在进行测试主从故障切换，都能正常切换，但是哨兵并没有修改主从的配置文件，网上也查了相关资料，说法不一（sentinel deny-scripts-reconfig ），但是都测试，还是没有成功，不知道是不是容器的原因，redis版本是6.X的。若大家知道，还请告知。。。。

二、哨兵架构

1、介绍

一般在搭建哨兵架构时，规格建议三个哨兵节点、一个主节点、2个从节点，官方文档中给出了不同节点规格部署的优缺点，最终得出示例2比较经典，具体可以参考文档进行阅读。
如下图可知，整个哨兵架构中各个节点的通信，从节点注册到master节点，哨兵节点通过master节点可以获取主从节点信息，并且通过master节点的订阅发布频道可以获取哨兵节点信息，从而整个哨兵架构就可以完成通信。
在这里插入图片描述

三、哨兵介绍

1、哨兵职责

监控：主要是sentinel通过PING命令监控主从以及哨兵节点的监控状态
选举：若master节点发生故障，则sentinel需要进行选举，
故障转移：当master故障后，通过选出的leader哨兵进行故障转移，进而进行主从切换
通知：当发生主从切换成功后，需要通知给客户端和其他从节点

2、哨兵集群嗅探

由哨兵进行搭建的配置文件可知，我们只在从节点配置了主节点信息，在哨兵中也只配置了主节点信息，那么哨兵是怎么监控所有节点信息呢，由上面的哨兵架构介绍可知，其实在sentinel节点中有三个定时任务来完成整个架构的节点发现

哨兵每10s向主从（第一次只有主节点）发生INFO，获取各个节点的主从关系
哨兵每个1s向所有节点（主从、哨兵）发生ping命令，监控节点的健康信息
哨兵每个2s向主节点的SUB/PUB（__sentinel __:hello）通道发送哨兵节点信息

3、故障判断

主观下线（个人同意即可）

哨兵节点已每秒的频率向各个节点发生ping来监控，如果某个节点在30s内都没收到有效的恢复

sentinel down-after-milliseconds 30000

则判断改节点为主观下线（sdown），如果下线的是sentinle节点和slave节点，哨兵集群不会发生改变，只会记录对应的节点已经下线。如果是master节点，则会进行下面的客观下线的判断

客观下线（大家都同意）

在实际场景中，由于存在很多复杂的情况，最常见的就可能是网络抖动，那么master节点和其中一个sentinel节点发生网络中断，而 Master 节点本身没有任何问题，此时就认为 Master 故障是不正确的。所以在这种场景下，就需要多个sentinel来判断主节点是否故障了。这要保证了减少误判的情况

4、哨兵选举

所有进行客观判断master下线的sentinel都可能成为failover leader，为了减少同一时刻所有sentinel同时发起选举请求而导致选举失败的可能，所有redis的每个sentinel节点都会有一个随机超时时间发生选举的算法
每次发生选举后，sentinel的纪元（epoch）都会增1
在一个纪元内，所有的sentinel都有一次为其他sentinel选举成leader的机会（首先自己为自己投的一票并不算）
主观下线的sentinel会发生is-master-down-by-addr命令给其他sentinel节点，如果其他sentinel收到命令后，判断当前没有给他去sentinel投过票，并且也判断了master主观下线，就会回复同一发生请求的sentinel成为leader
当发生请求的sentinel收到其他sentinel的回复后，判断是否拿到半数以上的赞成票并且要大于等于配置的quorum数量，如果达到怎leader选出
如果在规定的时间内没有选出合适的leader,则表示选举失败，那么在一定的时间后会进行第二次选举

5、故障转移

在多个slave节点如何选出一个合适的节点来做新的master主要有以下几点优先级判断：

与master断开连接的时间：slave与master断开连接的时间超过了10次（down-after-milliseconds）,则认为该slave不可靠
副本优先级：根据redis.conf中配置的replica-priority优先级判断，较小的代表优先级高，这种场景一般在明确某个slave节点配置较好的情况下可设置优先级高点
数据完整性：当前面条件都达到的slave节点，需要进行判断从节点的slave的数据复制偏移量（offset）来判断，更接近主节点的slave优先级更高
runid判断：当前面都一样时，runid小的就选出新的master节点

6、通知

一旦 Sentinel 能够成功地对 master 进行故障转移，它将开始广播新配置，以便其他 Sentinel 将更新其有关给定 master 的信息。为了使故障转移被认为是成功的，首先 Sentinel 能够将REPLICAOF NO ONE命令发送到选定的slave，将其成功的选为master。

每个 Sentinel 都使用 Redis Pub/Sub 消息在主服务器和所有副本中持续广播其主服务器配置版本。同时，所有的 Sentinel 都在等待消息，以查看其他 Sentinel 发布的配置是什么。配置在__sentinel__:helloPub/Sub 频道中广播。
因为每个配置都有不同的版本号，所以大版本总是胜过小版本。
因此，例如，master 的配置mymaster从所有相信 master 的 Sentinel 开始在 192.168.1.50:6379。此配置具有版本 1。一段时间后，Sentinel 被授权使用版本 2 进行故障转移。如果故障转移成功，它将开始广播新配置，例如 192.168.1.50:9000，版本 2。所有其他实例将看到此配置并相应地更新其配置，因为新配置具有更高版本。

四、哨兵集群操作

1、脑裂现象

在这里插入图片描述

当第一台机器与其他机器网络发生中断时，此时sentinel1和sentinel2发生了故障转移，将slave1选出新的master节点，那么此时客户端还是任务旧的master节点可用，并且持续进行写命令，当网络恢复后，旧的master节点会变成新的master的从节点，这样在这个期间所有的数据就会丢失的情况
我们可以在redis.conf进行如下配置