网站开发新型技术,辽宁省建设银行网站,网站注册qq,wordpress 黑白 主题概述 Redis的高可用机制有持久化、复制、哨兵和集群。其主要的作用和解决的问题分别是#xff1a; 持久化#xff1a;持久化是最简单的高可用方法(有时甚至不被归为高可用的手段)#xff0c;主要作用是数据备份#xff0c;即将数据存储在硬盘#xff0c;保证数据不会因进程…概述 Redis的高可用机制有持久化、复制、哨兵和集群。其主要的作用和解决的问题分别是 持久化持久化是最简单的高可用方法(有时甚至不被归为高可用的手段)主要作用是数据备份即将数据存储在硬盘保证数据不会因进程退出而丢失。 复制复制是高可用Redis的基础哨兵和集群都是在复制基础上实现高可用的。复制主要实现了数据的多机备份以及对于读操作的负载均衡和简单的故障恢复。缺陷故障恢复无法自动化写操作无法负载均衡存储能力受到单机的限制。 哨兵哨兵实现了主从复制中故障的自动化恢复。缺陷写操作无法负载均衡存储能力受到单机的限制。 集群通过集群解决了写操作无法负载均衡以及存储能力受到单机限制的问题实现了较为完善的高可用方案。 本文这里将介绍Redis的哨兵机制。 为什么要有哨兵 Redis的主从模式重点在于解决整体的承压能力利用从节点分担读取操作的压力。但是其在容错恢复等可靠性层面欠缺明显不具备自动的故障转移与恢复能力 如果slave从节点宕机整个redis依旧可以正常提供服务待slave节点重新启动后可以恢复从master节点的数据同步、然后继续提供服务。 如果master主节点宕机则redis功能受损无法继续提供写服务直到手动修复master节点方可恢复。 当然master节点故障后也可以手动将其中一个从节点切换为新的master节点来恢复故障。而原先的master节点恢复后需要手动将其降级为slave节点对外提供只读服务。 实际使用的时候手动故障恢复的时效无法得到保证为了支持自动的故障转移与恢复能力Redis在主从模式的基础上进行优化增强提供了哨兵Sentinel架构模式。 那么就需要有一个机制能够监测主节点是否存活如果发现主节点挂了就选举一个从节点切换为主节点并且把新主节点的相关信息通知给从节点和客户端。 那么就有以下三个问题需要解决 主库真的挂了吗 选择哪个从库作为主库 如何把新主库相关信息通知给从库和客户端 哨兵机制流程 Redis的哨兵模式就是在主从模式的基础上额外部署若干独立的哨兵进程通过哨兵进程去监视者Redis主从节点的状态一旦发现主节点宕机则哨兵可以重新从剩余slave节点中推选一个新的节点并将其升级为master节点以此保证整个系统功能可以正常使用。 哨兵负责三个任务监控选主选择主库和通知。 监控监控是指哨兵进程运行时周期性默认1秒给所有主从节点发送 PING 命令当主从节点收到 PING 命令后会发送一个响应命令给哨兵这样就可以检测他们是否仍然在线运行。从库没有在规定时间内响应哨兵的PING命令哨兵就会把它标记为下线状态主库没有在规定时间呢响应哨兵的PING命令哨兵就会判定主库下线启动选主流程。 选主哨兵在主库挂了以后按照一定规则从从库中选出作为新的主库。 通知哨兵将选出的新主库连接信息发给其他从库从库和新主库建立连接执行replicaof命令复制数据。同时哨兵会把新主库的连接信息通知给客户端让它们将操作请求发送给新主库上。 监控如何判断主库是否真的挂了 哨兵进程会使用PING命令检测主和从库的连接情况用来判断实例状态 如果哨兵发现主库或者从库对PING命令响应超时那么哨兵就会把它标记为主观下线。 对于从库哨兵可以简单标记为主观下线因为从库下线影响不大集群对外服务不会中断。 对于主库哨兵不能简单标记为主观下线开启主从切换。因为可能存在一种情况哨兵误判主库没有故障可是一旦启动选主和通知操作后续的选主和通知操作都会带来额外的计算和通信开销。还可能产生脑裂。 确认主库下线了主库才能被标记为客观下线。需要注意的是客观下线是主节点才有的概念如果从节点和哨兵节点发生故障被哨兵主观下线后不会再有后续的客观下线和故障转移操作。 什么是误判主库实际没有下线但是哨兵以为它下线了。误判产生原因比如集群网络压力较大出现网络拥塞或者主库本身压力较大导致主节点没有在规定时间内响应哨兵的 PING 命令。 因此这里有两个问题 需要尽量避免误判 - 少数服从多数 有两个哨兵都判断主库是客观下线了那么由哪个哨兵进行主从故障转移 少数服从多数机制 哨兵集群哨兵以多实例组成的集群模式进行部署最少需要三台机器来部署哨兵集群。通过多个哨兵节点一起判断就可以就可以避免单个哨兵因为自身网络状况不好而误判主节点下线的情况。同时多个哨兵网络同时不稳定的概率较小让它们一起决策让误判率降低。 当一个哨兵判断主库为主观下线后就会向其它哨兵发起协商其它哨兵就会根据自身与主库的网络状况做出赞成或拒绝投票的响应。 而只有大多数哨兵实例判断主库都已经主观下线主库才会被标记客观下线——— 即少数服从多数机制 当这个哨兵的赞同票数达到哨兵配置文件中的 quorum 配置项设定的值后这时主节点就会被该哨兵标记为客观下线。 客观下线N个哨兵实例最好要有N/21个实例判断主库为主观下线才能判断为客观下线。 由哪个哨兵进行主从故障转移 为了减少误判概率所以哨兵是以哨兵集群的方式存在的以少数服从多数的机制来判断主库是否真的挂了。 那么既然是集群由哨兵集群中的哪个节点进行主从故障转移呢 所以这时候还需要在哨兵集群中选出一个 leader让 leader 来执行主从切换。 leader是从候选者中产生的哪个哨兵节点判断主节点为 客观下线 这个哨兵节点就是leader的候选者。
假设有三个哨兵。当哨兵 B 先判断到主节点主观下线后就会给其他实例发送 is-master-down-by-addr 命令。接着其他哨兵会根据自己和主节点的网络连接情况做出赞成投票或者拒绝投票的响应。当哨兵 B 收到赞成票数达到哨兵配置文件中的 quorum 配置项设定的值后就会将主节点标记为 客观下线此时的哨兵 B 就是一个Leader 的候选者。 判断主库客观下线后只是Leader 的候选者还不是Leader由于quorum 配置问题有可能判断主库客观下线的哨兵有多个。比如有3个哨兵quorum为2AB都认为主库主观下线C认为主库还在线因此此时哨兵A收到主观下线的值为2另一个哨兵B收到的主观下线值也为2由于这两个值都大于等于quorum因此哨兵A和哨兵B都会将主库标记为客观下线。但不能让哨兵A和哨兵B同时执行主从切换。因此需要从哨兵A和哨兵B中选出一个Leader来执行主从切换 此时Leader候选者会向其他哨兵发送命令表明希望成为 Leader 来执行主从切换并让所有其他哨兵对它进行投票。 每个哨兵只有一次投票机会如果用完后就不能参与投票了可以投给自己或投给别人但是只有Leader候选者才能把票投给自己。 那么只要 Leader候选者 同时满足以下两个条件就可以成为Leader 拿到半数以上的赞成票 拿到的票数还要大于等于哨兵配置文件中的 quorum 值。 也就是说选举的票数大于等于num(sentinel)/21时Leader候选者 将成为 Leader如果没有超过继续选举 所以quorum 的值建议设置为哨兵个数的二分之一加1例如 3 个哨兵就设置 25 个哨兵设置为 3而且哨兵节点的数量应该是奇数 哨兵判断主节点客观下线后哨兵就要开始在从节点中选出一个从节点来做新主节点 这里大家是不是和我一样有个疑惑如果三个哨兵同时判断为主观下线那么就有可能同时判断为客观下线那么就都是leader候选者了那么在投票时也都投给了自己那么leader不就永远选不出来了吗首先哨兵对主从库进行的在线状态检查的操作是属于一种时间事件用一个定时器来完成一般来说每100ms执行一次这些事件。实际上每个哨兵的定时器执行周期都会加上一个小小的随机时间偏移目的是让每个哨兵执行上述操作的时间能稍微错开些也是为了避免它们都同时判定主库主观下线。其次实际上不同哨兵的网络情况、系统的压力一般不完全一样接收到主观下线协商消息的时间也就可能不同所以它们同时做出主库客观下线判定的概率较小一般也就有个先后关系。最后即使出现了都投给自己一票的情况导致无法选出Leader哨兵会停一段时间一般是故障转移超时时间failover_timeout的2倍然后再可以进行下一轮投票。 选定新主库 选定新主库是 筛选 ➕ 打分的过程 筛选条件 首先要把网络状态不好的从节点给过滤掉。首先把已经下线的从节点过滤掉然后把以往网络连接状态不好的从节点也给过滤掉。 检查从库的当前在线状态判断他之前的网络连接状态 如果从库总是和主库断连断连次数超过一定阈值该从库网络状态不好。 判断方式使用配置项down-after-milliseconds*10。down-after-milliseconds是主从节点断连的最大连接超时时间。如果在 down-after-milliseconds 毫秒内主从节点都没有通过网络联系上我们就可以认为主从节点断连了。如果这个断连次数超过10次说明从库网络状态不好不适合作为新主库。 打分 优先级、复制进度、ID 号 1、第一轮优先级最高的从节点胜出 通过配置slave-priority配置项给不同从库设置不同优先级。比如两个从库内存大小不一样可以手动设置内存大的实例设置为一个高优先级。选主时候哨兵会选出优先级最高的打高分作为新主库如果得分一样那就开始第二轮打分。 2、第二轮和旧主库同步程度最接近的从库得分高 如果选择与旧主库同步最接近的从库作为主库那么新主库上就有最新的数据。如果两个从库的slave_repl_offset值大小一样那么就需要进入第三轮打分了 如何判断从库和旧主库间的同步进度从库的slave_repl_offset最接近旧主库的master_repl_offset那么它的得分最高可以作为新主库。 3、第三轮ID 号小的从节点胜出 每个从节点都有一个编号这个编号就是 ID 号是用来唯一标识从节点的。 通知 将选举出的从节点解除从节点身份升级为主节点 在选举出从节点为新主节点后后哨兵 leader 向被选中的从节点发送 SLAVEOF no one 命令让这个从节点解除从节点的身份将其变为新主节点。 将从节点指向新的主节点 哨兵 leader 下一步要做的就是让已下线主节点属下的所有从节点指向新主节点这一动作可以通过向从节点发送 SLAVEOF 命令来实现。 通知客户端主节点已经更换 这主要通过 Redis 的发布者/订阅者机制来实现的。每个哨兵节点提供发布者/订阅者机制客户端可以从哨兵订阅消息。 哨兵提供的消息订阅频道有很多不同频道包含了主从节点切换过程中的不同关键事件几个常见的事件如下 客户端和哨兵建立连接后客户端会订阅哨兵提供的频道。主从切换完成后哨兵就会向 switch-master 频道发布新主节点的 IP 地址和端口的消息这个时候客户端就可以收到这条信息然后用这里面的新主节点的 IP 地址和端口进行通信了。 将原主节点变为从节点指向新的主节点 继续监视旧主节点当旧主节点重新上线时哨兵集群就会向它发送 SLAVEOF 命令让它成为新主节点的从节点 频繁主从切换 由于redis是单线程运行的如果有命令超过3秒哨兵心跳检查就会失败最终导致频繁切换主从和脑裂情况 总结 本文首先介绍了哨兵的作用监控、选主、通知主要是实现主从节点故障转移。哨兵集群会监测主节点是否存活如果发现主节点挂了它就会选举一个从节点切换为主节点并且把新主节点的相关信息通知给从节点和客户端。 哨兵机制具体步骤如下 第一轮投票判断主节点客观下线 第二轮投票选出哨兵leader决定由哪个哨兵执行主从切换 由哨兵 leader 进行选主 由哨兵 leader 进行通知实现主从故障转移 在主从复制的基础上哨兵引入了主节点的自动故障转移进一步提高了Redis的高可用性但是哨兵的缺陷同样很明显哨兵无法对从节点进行自动故障转移在读写分离场景下从节点故障会导致读服务不可用这就需要对从节点做额外的监控、切换操作。 此外哨兵仍然没有解决写操作无法负载均衡、存储能力受到单机限制的问题这些问题的解决需要使用集群有时间再学习集群方面的知识~ 文章转载自seven97_top 原文链接https://www.cnblogs.com/seven97-top/p/18583160 体验地址引迈 - JNPF快速开发平台_低代码开发平台_零代码开发平台_流程设计器_表单引擎_工作流引擎_软件架构
