上篇文章我们讲述了Redis中的主从复制(Redis分布式系统中的主从复制-CSDN博客),本篇文章针对主从复制中的问题引出Redis中的哨兵,希望本篇文章会对你有所帮助。
文章目录
🙋♂️ 作者:@Ggggggtm 🙋♂️
👀 专栏:Redis 👀
💥 标题:Redis中的哨兵💥
❣️ 寄语:与其忙着诉苦,不如低头赶路,奋路前行,终将遇到一番好风景 ❣️
一、引入哨兵机制
Redis中的主从复制最大的问题就是在主节点上。现在我们具体来分析一下其原因。假如现在主从复制当中,有一个从节点因为网络抖动或者其他原因与主节点断开连接,这时候对其他的节点影响大吗?实际上影响并不大的,Redis的客户端可以从其他的从节点正常读取数据,并且也不影响对主节点的读和写操作。等网络稳定,或者该从节点再次主动执行slaveof来接入该主从复制结构,最坏的情况也就是全量复制同步数据。
如果主节点挂了呢?主节点挂了从节点就迷茫了。虽然能够提供读操作,但是从节点不能自动的升级成主节点,也就是不能替换原有主节点对应的角色。此时就需要程序猿/运维手工的恢复主节点。通常情况下,管理员需要手动选择一个从节点作为新的主节点,并更新其他从节点的配置,将其设置为新主节点的从节点(slaveof masterhost masterport)。这个过程可能涉及到修改配置文件、执行命令等操作。 过程繁杂,且有可能出现意外情况。
针对上述的情况,Redis引入了哨兵(Sentinel)机制。Redis Sentinel是一个分布式系统,用于监控Redis集群中各个节点的状态,并在发现故障时自动进行故障转移。它可以自动识别主节点的故障,并将一个从节点晋升为主节点,从而实现故障恢复的自动化。通过Redis Sentinel的监控和自动化故障处理机制,可以大大提高系统的可用性和稳定性,降低故障恢复的时间成本,从而保证系统能够在面对各种故障和异常情况时依然能够正常运行。
下面我们来详细学习Redis Sentinel中的细节。
二、基本概念
由于对 Redis的许多概念都有不同的名词解释,所以在介绍Redis Sentinel之前,先对几个名词概念进行必要的说明,如表所示。
注意:哨兵节点是一个单独的进程,此功能并不是集成在主从复制当中的。哨兵机制就是通过哨兵节点来解决 Redis 主节点挂掉的问题的方法。哨兵节点不负责存储数据,主要是用来监控监控 Redis 主从服务器是否正常运行,并且在主节点挂掉后能够自动完成切换主节点,也就是故障转移工作。
考虑到单个哨兵节点挂掉时,监控与自动切换主节点无法正常完成,因此通常会部署多个哨兵节点构成一个集合。这样即使一个哨兵节点挂掉,其他哨兵节点仍然可以监控 Redis 主节点的状态,并且当主节点出现故障时,其他哨兵节点可以通过投票来选举出一个新的主节点。这种方式确保了 Redis 集群的高可用性和容错性。
Redis Sentinel 是 Redis 提供的高可用实现方案。在实际的生产环境中,它扮演着关键的角色,为系统提供了稳定可靠的服务。在面对可能的故障时,Redis Sentinel能够迅速识别问题并采取必要的措施,确保系统持续运行。
三、主从复制的问题
Redis的主从复制模式可以将主节点的数据改变同步给从节点,这样从节点就可以起到两个作用:
- 第一,作为主节点的一个备份,一旦主节点出了故障不可达的情况,从节点可以作为后备“顶”上来,并且保证数据尽量不丢失(主从复制表现为最终一致性)。
- 第二,从节点可以分担主节点上的读压力,让主节点只承担写请求的处理,将所有的读请求负载均衡到各个从节点上。
但是主从复制模式并不是万能的,它同样遗留下以下几个问题:
- 主节点发生故障时,进行主备切换的过程是复杂的,需要完全的人工参与,导致故障恢复时间无法保障。
- 主节点可以将读压力分散出去,但写压力/存储压力是无法被分担的,还是受到单机的限制。其中第一个问题是高可用问题,即 Redis哨兵主要解决的问题。第二个问题是属于存储分布式的问题,留给Redis集群去解决,本篇文章我们集中讨论第一个问题。
接下来我们来还原以下主从复制模式中的主节点出现问题的场景。
现有如下主从复制结构:
有如下突发情况:大半夜Redis主从复制中的主节点挂掉了,领导打电话让你赶快重新配置一下。此时的你一脸高兴(我上早八)的从床上爬起来,打开电脑连接到公司的电脑。然后你选择先看看主节点还能不能抢救了,好不好抢救。如果主节点这边是啥原因挂的不好定位,或者原因知道但是短时间难以解决,就需要挑一个从节点设置为新的主节点让Redis保持正常工作。然后你开始做了:
- 把选中的从节点通过slaveof no one,与主节点断开主从关系,自己成为一个主节点;
- 把其他的从节点修改slaveof的主节点ip port,连上新的主节点;
- 告知客户端(修改客户端的配置),让客户端能够连接新的主节点,用来完成修改数据的操作。
- 再去产看之前的主节点。当之前的挂了的主节点修好了之后,在修改一下该主节点的配置文件,就可以作为一个新的从节点挂到这组机器中。
上述过程顺利的话你可能一个小时就完成了。但是在顺利的情况下你勉强能接受,不顺利呢?半夜的你的状态、心情等等因素,即使你的状态不错,但凡涉及到人工去修改,就会有概率出错!可能会导致问题更加严重。半夜起来修改不说,结果弄的一团糟~~
其次你在修改的工程中,Redis客户端的写操作怎么办呢?主节点都挂了还要怎么写啊!显然上述的过程不是很靠谱。
四、哨兵自动恢复主节点故障
当主节点出现故障时,Redis Sentinel能自动完成故障发现和故障转移,并通知应用方从而实现真正的高可用。
Redis Sentinel是一个分布式架构,其中包含若干个Sentinel(哨兵)节点和Redis数据节点(主从节点),每个Sentinel节点会对数据节点和其余Sentinel节点进行监控,当它发现节点不可达时,会对节点做下线表示。如果下线的是主节点,它还会和其他的Sentinel节点进行“协商”,当大多数Sentinel节点对主节点不可达这个结论达成共识之后,它们会在内部“选举”出一个领导节点来完成自动故障转移的工作,同时将这个变化实时通知给Redis应用方。整个过程是完全自动的,不需要人工介入。
具体来说,Redis的主从节点负责存储数据和处理客户端请求,Sentinel节点则负责监控和管理Redis数据节点的状态以及执行故障转移等任务。客户端可以连接到任何一个Redis节点,通过Sentinel节点来获取集群的状态信息和执行故障转移等操作,从而实现对Redis集群的管理和监控。
需要注意的是,在这种架构下Redis数据节点和Sentinel节点都是独立部署的,它们之间没有直接的数据交互,而是通过网络进行通信。注意:上图中的监控是指这些进程之间会建立tcp长连接,通过这样的长连接定期发送心跳包。这种分布式架构使得整个系统更具弹性和容错能力,即使某个物理节点出现故障,也不会影响整个系统的正常运行。
上图我们也能看出: Redis Sentinel引入多个Sentinel节点,系统具备了更强的可靠性和容错能力。当有多个Sentinel节点同时监控集群时,即使部分Sentinel节点出现故障或无法正常工作,仍然可以保证集群的监控和管理功能不受影响。为了确保在进行故障检测和故障转移时能够达成多数派的共识,建议使用奇数个Sentinel节点(后续会解释)。
现在Sentinel节点监控现有的redis master 和 slave,如果是slave挂了,并没有任何关系。但是主节点挂了, Redis Sentinel就要进行故障转移了。针对主节点故障转移流程大致如下∶
- 主节点故障,从节点同步连接中断,主从复制停止。
- 哨兵节点通过定期监控发现主节点出现故障。哨兵节点与其他哨兵节点进行协商,达成多数认同主节点故障的共识。这步主要是防止该情况:出故障的不是主节点,而是发现故障的哨兵节点或者是因为网络问题,该情况经常发生于哨兵节点的网络被孤立的场景下。‘
- 哨兵节点之间使用Raft算法选举出一个领导角色,由该节点负责后续的故障转移工作。
- 哨兵领导者开始执行故障转移:从节点中选择一个作为新主节点,让其他从节点同步新主节点。该工作也就是前面我们说到的人工操作恢复故障的工作。
- 哨兵节点会自动的通知客户端程序告知新的主节点是谁,并且后续客户端再进行写操作,就会针对新的主节点进行操作了。
通过上述我们也能分析出redis哨兵核心功能:
- 监控数据节点,主要是主节点;
- 自动的故障转移;
- 通知客户端。
注意redis 哨兵节点只有一个也是可以的。如果哨兵节点只有一个,它自身也是容易出现问题的。万一这个哨兵节点挂了,后续redis主节点也挂了,就无法进行自动的恢复过程了。
出现误判的概率也比较高,毕竟网络传数据是容易出现抖动或者延迟或者丢包的。如果只有一个哨兵节点出现上述因网络问题造成误判之后,影响就比较大。
五、哨兵重新选取主节点的流程(原理)
假定当前环境有三个哨兵(sentenal1, sentenal2, sentenal3),一个主节点(redis-master),两个从节点(redis-slave1, redis-slave2)。当主节点出现故障,就会触发重新一系列过程。
哨兵重新选取主节点的前提是多个哨兵节点确定主节点挂掉了。注意:是多个哨兵节点判断主节点挂掉了。怎么就多个哨兵节点可以都判断该主节点挂掉了呢?因此在 Redis 哨兵(Sentinel)中,sdown 表示主观宕机(Subjectively Down),odown 表示客观宕机(Objectively Down)。
sdown 是指单个哨兵节点认为某个 master 节点宕机了。具体来说,如果一个哨兵节点向 master 发送 ping 命令(心跳机制),在超过指定的毫秒数之后没有收到有效回复,那么这个哨兵就会主观认为 master 宕机,将其标记为 sdown。
odown 则是指多个哨兵节点都认为某个 master 节点宕机了。当一个哨兵将 master 标记为 sdown 后,它会在指定时间内,每秒向其他哨兵发送
i
消息来询问它们是否也认为该 master 是 sdown。如果收到该消息的其他哨兵中,有达到法定票数的数量(可配置的最小数量)的哨兵都认为那个 master 是 sdown,那么就可以认为是 odown,即客观认为 master 宕机。多个哨兵需要判定主节点是否挂了,这样才更加安全。但是有的时候可能因为特殊情况,比如主节点仍然工作正常,但是哨兵节点自己网络出问题了,无法访问到主节点了。此时就可能会使该哨兵节点认为主节点下线而出现误判。使用投票的方式来确定主节点是否真的挂了是更稳妥的做法,需要多个哨兵都认为主节点挂了,即票数>=法定票数之后才会真的认为主节点是挂了。
确定master客观下线后,要让多个哨兵节点选出一个leader节点,由这个leader负责选一个从节点作为新的主节点。怎么选出一个leader呢?
Raft 算法是一种被广泛应用于分布式系统中的共识算法,用于确保系统中的多个节点能够达成一致的决策。在 Redis 哨兵集群中,Raft 算法通常用于选举领导者(leader),以协调故障转移过程。
假设我们有三个哨兵节点:S1、S2 和 S3。在故障转移过程中,哨兵节点之间会相互发起选举,以下是大致的选举流程:
- 拉票请求发起:每个哨兵节点都会向其他所有哨兵节点发起拉票请求,表达自己的候选人意愿。例如,哨兵节点 A(S1)会给哨兵节点 B(S2)和哨兵节点 C(S3)发送拉票请求,哨兵节点 B(S2)会给哨兵节点 A(S1)和哨兵节点 C(S3)发送拉票请求,以此类推。
- 投票响应:收到拉票请求的哨兵节点会根据自身的情况作出投票决定,并回复投票响应。每个哨兵节点只有一票,并且只能投给一个候选人。如果收到的是第一次拉票请求,那么响应方将投票给拉票方。如果已经给其他候选人投过票,那么就不再投票。
- 选举结果确认:在一轮投票结束后,如果有一个候选人收到了超过半数的选票,那么它将自动成为领导者。例如,如果 S1 和 S2 都投给了 S3,那么 S3 将成为领导者。如果没有候选人获得半数以上的选票,则会重新进行选举。
- 领导者选举完成:新选出的领导者负责挑选一个从节点升级为新的主节点。例如,如果 S3 成为了领导者,它将选择一个从节点升级为新的主节点。其他哨兵节点会观察到新的主节点的出现,从而确认选举过程已经结束
通过上述流程我们能够看出Raft 算法的核心理念是“先下手为强”,即率先发起拉票请求的候选人更有可能成为领导者。选举的结果可能受到网络延迟的影响,因此选举过程中会有一定的随机性。
在 Redis 哨兵集群中,确保哨兵节点数量为奇数有助于降低出现平票的可能性,从而减少额外的选举开销。偶数个哨兵节点出现的平票概率相对来说大意是点。这一过程确保了集群在主节点故障时能够快速有效地进行故障转移。
选出leader后,那么由该leader选出一个从节点作为新的主节点,那么这里问题又来了:选哪个从节点呢?这里也是右挑选规则的:
- 比较优先级。优先级高(数值小的)的上位,优先级是配置文件中的配置项(slave-priority或者replica-priority );
- 比较replication offset谁复制的数据多,高的上位。offset 为从节点从主节点这边同步数据的进度。数值越大说明从节点的数据和主节点就越接近;
- 比较run id ,谁的id 小,谁上位。这个run id生成的大小是随机的。(此时选谁都可以了,随便挑一个)。
把新的主节点指定好了之后,leader就会控制这个这个节点执行slave no one,成为master。再控制其他节点,执行slave of ,让这些其他节点,以新的 master作为主节点了。
一些注意事项:
- 哨兵节点数量: 哨兵节点尽量不要只有一个,因为如果唯一的哨兵节点挂了,将会影响系统的可用性。建议至少使用三个哨兵节点,以确保高可用性。
- 奇数个哨兵节点: 最好将哨兵节点配置为奇数个。这样做有利于选举领导者,因为得票超过半数的概率更高,从而降低了出现平票的可能性。
- 哨兵节点的角色: 哨兵节点不负责存储数据,它们的主要作用是监控和管理 Redis 主从节点。实际的数据存储仍然由 Redis 主从节点负责。
- 提高可用性: 哨兵节点和主从复制结合解决了提高系统的可用性的问题,但无法解决数据丢失的问题。在极端情况下(主节点没来得及同步就挂了),可能会发生写入数据丢失的情况,因此需要结合其他机制来确保数据的持久性和一致性。
- 存储容量限制: 哨兵节点和主从复制不能提高数据的存储容量。当需要存储的数据接近或超过服务器的物理内存时,单纯依靠这种结构将难以满足需求。为了扩展存储容量,需要引入集群架构,如 Redis Cluster,以实现数据的分片和分布式存储。