商城网站怎样做,wordpress 被挂马,研究生做家教什么网站,国内最大的域名交易平台上篇文章我们讲述了Redis中的主从复制#xff08;Redis分布式系统中的主从复制-CSDN博客#xff09;#xff0c;本篇文章针对主从复制中的问题引出Redis中的哨兵#xff0c;希望本篇文章会对你有所帮助。 文章目录 一、引入哨兵机制 二、基本概念 三、主从复制的问题 四、哨… 上篇文章我们讲述了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 Downodown 表示客观宕机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。在故障转移过程中哨兵节点之间会相互发起选举以下是大致的选举流程 拉票请求发起每个哨兵节点都会向其他所有哨兵节点发起拉票请求表达自己的候选人意愿。例如哨兵节点 AS1会给哨兵节点 BS2和哨兵节点 CS3发送拉票请求哨兵节点 BS2会给哨兵节点 AS1和哨兵节点 CS3发送拉票请求以此类推。投票响应收到拉票请求的哨兵节点会根据自身的情况作出投票决定并回复投票响应。每个哨兵节点只有一票并且只能投给一个候选人。如果收到的是第一次拉票请求那么响应方将投票给拉票方。如果已经给其他候选人投过票那么就不再投票。选举结果确认在一轮投票结束后如果有一个候选人收到了超过半数的选票那么它将自动成为领导者。例如如果 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以实现数据的分片和分布式存储。
