网站不被收录了如何查询网站注册信息

当前位置： 首页 > news >正文

网站不被收录了,如何查询网站注册信息,wordpress导航菜单栏,瑞安做网站的公司一、引言 Redis 概述 在当今的数据存储领域#xff0c;Redis 占据着十分重要的地位。它是一个内存中的数据存储#xff0c;凭借其出色的性能和丰富的功能#xff0c;被数百万开发人员广泛应用于诸多场景之中#xff0c;已然成为构建高性能、可扩展应用程序的得力工具。 从…一、引言 Redis 概述 在当今的数据存储领域Redis 占据着十分重要的地位。它是一个内存中的数据存储凭借其出色的性能和丰富的功能被数百万开发人员广泛应用于诸多场景之中已然成为构建高性能、可扩展应用程序的得力工具。 从存储特点来看Redis 的数据库完全在内存中运作不过它也会利用磁盘来实现数据的持久性以此避免数据的意外丢失。与众多键值数据存储相比Redis 所支持的数据类型更为多样且复杂涵盖了字符串、散列、列表、集合、排序集以及 JSON 等。这些丰富的数据类型为开发人员在处理不同业务逻辑时提供了极大的便利能够轻松应对各种各样的数据存储与操作需求。 同时Redis 具备内置的复制功能通过该功能可以将数据复制到任意数量的从服务器上。这不仅有助于实现数据的冗余备份增强了数据的安全性而且在一定程度上还能进行负载均衡将读请求合理分配到多个从服务器减轻主服务器的压力。 另外Redis 还提供了不同级别的磁盘持久性方案确保在一些突发情况下如服务器意外断电、故障等内存中的数据能够尽可能完整地保存下来以便后续恢复使用。总的来说Redis 凭借其独特的优势在缓存、矢量数据库、文档数据库、流式计算引擎以及消息代理等多个方面都发挥着关键作用成为众多开发者在项目开发中的优选之一。 二、Redis 哨兵模式介绍 哨兵模式的作用 Redis Sentinel 在不使用 Redis 集群时为 Redis 提供高可用性这是其核心价值所在。它就像是一位时刻警惕的守护者承担着多项重要任务。 首先是监控功能Sentinel 会不断地检查 Master 和 Slave 实例是否运作正常。它通过定期向这些实例发送 PING 命令等方式来检测它们的网络连接状态以及是否能正常响应请求以此确定各个实例是否按预期工作。例如每隔 1 秒默认时间间隔可配置每个哨兵会向主节点、从节点及其余哨兵节点发送一次 PING 命令做一次心跳检测若在规定时间由 sentinel down-after-milliseconds 参数指定默认值为 30 秒内没有收到相应实例回复的 PING 命令就会对该实例的状态产生怀疑。 其次是通知功能当被监控的某个 Redis 节点出现问题时Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。这使得相关人员或程序能够及时知晓 Redis 实例出现了异常情况进而可以采取相应的应对措施比如人工介入查看具体故障原因等。 再者就是自动故障转移功能这也是哨兵模式非常关键的一个作用。当主节点Master不能正常工作时Sentinel 会进行自动故障迁移操作它会将失效 Master 的其中一个从节点Slave升级为新的主节点并让失效 Master 的其他从节点改为复制新的主节点。而且当客户端试图连接失效的 Master 时集群也会向客户端返回新 Master 的地址使得集群可以使用新 Master 代替失效 Master从而保障整个 Redis 服务不会因为主节点故障而中断确保业务的连续性。 最后Sentinel 还充当客户端服务发现的权限来源也就是配置提供程序的角色。客户端连接到 Sentinels 以询问负责给定服务的当前 Redis 主机的地址。如果发生故障转移Sentinels 将报告新地址方便客户端能动态地获取到当前可用的 Redis 主节点信息保证始终能和正确的主节点进行通信交互。 工作原理 监控机制 哨兵模式下的监控是一个多维度且持续进行的过程。一方面Sentinel 与 Redis Master Node 之间有着特定的关联配置在创建哨兵模式时就会指定好这种关系随后 Sentinel 会从主节点上获取所有从节点的信息。之后Sentinel 会定时向主节点发送 info 命令获取其拓扑结构和状态信息同时也会向从节点发送同样的命令来掌握各个从节点的相关情况比如节点是否存活、数据复制的进度等信息这个时间间隔通常为每 10 秒可配置。 另一方面基于 Redis 的订阅发布功能每个 Sentinel 节点会向主节点的 sentinel:hello 频道上发送该 Sentinel 节点对于主节点的判断以及当前 Sentinel 节点的信息像自身的运行状态、对主节点健康情况的初步判断等内容。同时每个 Sentinel 节点也会订阅该频道来获取其他 Sentinel 节点的信息以及它们对主节点的判断。 而最关键的是心跳检测机制每个 Sentinel 节点每隔 1 秒默认会向所有的 Master、Slave 以及其他 Sentinel 节点发送一个 PING 命令作用是通过心跳检测检测主从服务器的网络连接状态。如果 Master 节点回复 PING 命令的时间超过 down-after-milliseconds 设定的阈值比如默认 30 秒则这个 Master 会被 Sentinel 标记为主观下线修改其 flags 状态为 SRI_S_DOWN。不过主观下线只是单个 Sentinel 基于自身检测做出的判断为了避免误判后续还需要结合其他 Sentinel 的判断来进一步确认。 故障转移过程 当某个 Sentinel 将主节点标记为主观下线后如果这个主观下线的节点是主节点Master该 Sentinel 会向其余所有的 Sentinel 发送 sentinel is-master-down-by-addr 消息询问其他 Sentinel 是否同意该 Master 下线。其他 Sentinel 收到命令之后会根据发送过来的 IP 和端口检查自己判断的结果回复自己是否认为该 Master 节点已经下线了。 然后Sentinel 会收集这些回复如果同意 Master 节点进入主观下线的 Sentinel 数量大于等于配置文件中设定的 quorum 值法定人数用于判定客观下线的哨兵数量要求则 Master 会被标记为客观下线即认为该节点确实已经不可用了。 一旦主节点被判定为客观下线哨兵系统会进行协商选举出一个 Sentinel 作为领导者Leader Sentinel选举过程通常基于节点的优先级、延迟、网络稳定性以及其他因素进行权衡各个 Sentinel 节点之间通过投票来决定谁应该担任 Leader Sentinel投票机制有点类似于 Raft 算法需要拿到半数以上赞成票且票数大于等于 quorum 值的 Sentinel 才能成为领导者。 选出 Leader Sentinel 之后就由它来主导故障转移操作。它会按照一定的规则从多个从节点中选择一个合适的从节点升级为新的主节点规则大致包括先过滤掉所有不健康的如下线或者断线、没有回复哨兵 PING 响应的从节点然后优先选择 slave-priority 从服务器优先级最高的若优先级相同则选择复制偏移量最大的从服务器也就是复制数据最完整的若偏移量相同则按照运行从服务器 ID 进行排序选出其中运行 ID 最小的从服务器。 确定好新的主节点后Leader Sentinel 会向其发送 slaveof no one 命令让其成为主节点接着向剩余的从节点发送 slaveof 新主节点 IP 新主节点端口命令让它们成为新主节点的从节点。同时哨兵节点还会对旧主节点保持关注当其恢复后发送 slaveof 新主节点 IP 新主节点端口命令将其设置为从节点并让其去同步数据。并且整个过程中哨兵会将新主节点的信息通过发布订阅等方式通知给客户端以便客户端更新连接地址继续和新的主节点进行交互。 三、Redis 哨兵模式如何运行 运行哨兵的方式 在 Redis 中运行哨兵模式有以下两种常用的启动方式。 其一若你正在使用 redis-sentinel 可执行文件或者存在一个指向 redis-server 可执行文件的具有该名称的符号链接那么可以通过如下命令行来运行哨兵 redis-sentinel /path/to/sentinel.conf
其二也能够直接采用 redis-server 可执行文件并以 Sentinel 模式启动它对应的命令如下 redis-server /path/to/sentinel.conf –sentinel
这两种启动方法的本质是一样的最终都能让 Redis 进入哨兵模式运行。不过需要着重强调的是运行 Sentinel 时配置文件的使用是强制要求的。因为系统要依靠这个配置文件来保存其当前状态以便在重启的时候能够重新加载这些信息。要是没有给出配置文件又或者配置文件的路径不具备可写权限那么 Sentinel 将会拒绝启动。 另外Sentinels 在默认情况下会运行侦听到 TCP 端口 26379 的连接。所以为了保障 Sentinels 能够正常工作服务器的 26379 端口必须保持开放状态使其可以接收来自其他 Sentinel 实例的 IP 地址的连接。否则Sentinels 之间无法进行通信交流也就没办法针对后续的操作达成一致意见像故障转移、切主等操作就永远不会被执行了。 哨兵配置详情 配置文件示例与解读 Redis 源代码发行版中包含了一个名为 sentinel.conf 的文件它自身带有说明示例能够用于配置 Sentinel。不过典型的最小配置文件通常是如下这般模样 sentinel monitor mymaster 127.0.0.1 6379 2 sentinel down-after-milliseconds mymaster 60000 sentinel failover-timeout mymaster 180000 sentinel parallel-syncs mymaster 1 sentinel monitor resque 192.168.1.3 6380 4 sentinel down-after-milliseconds resque 10000 sentinel failover-timeout resque 180000 sentinel parallel-syncs resque 5
在这样的配置文件里我们只需要指定要监视的主机即可并且要为每个分离的主机每个主机可能配备有任意数量的副本赋予不同的名称对于副本是无需特意指定的因为 Sentinel 具备自动发现副本的能力。例如上述配置基本上就是在监视两组 Redis 实例每组实例都是由一个 master 和数量不定的副本所组成一组实例命名为 mymaster另一组则叫做 resque。 下面详细解读下 sentinel monitor 语句里各个参数的含义其语法格式为 sentinel monitor master-name ip port quorum。以配置中的 sentinel monitor mymaster 127.0.0.1 6379 2 这一行举例来说 mymaster代表的是被监控的主节点的名称这是一个自定义的标识方便后续在各种操作以及配置中对该主节点进行引用。 127.0.0.1明确指出了主节点所在的 IP 地址告知 Sentinel 去哪里寻找对应的主节点实例。 6379对应的是主节点运行时所监听的端口号通过这个端口Sentinel 才能与主节点建立连接并进行交互通信发送诸如检测心跳、获取状态信息等各类命令。 2这里的 quorum 参数指的是法定人数它代表着需要就主节点不可达这一事实达成一致的哨兵数量。只有当达到这个数量的哨兵都认为主节点出现问题无法正常访问时才会真正将主节点标记为失败并且在满足相应条件的情况下最终启动故障转移的相关流程。 法定人数相关规则 法定人数quorum在 Sentinel 的故障检测以及实际执行故障转移的过程中起着至关重要的判定作用有着明确的规则要求。 在检测故障阶段quorum 用于判定主节点是否处于不可达或者出现错误的状态。例如当配置的 quorum 值为 2 时如果有两个哨兵同时发现它们向主节点发送 PING 命令后在规定的 down-after-milliseconds 时间内没有收到有效的回复意味着主节点可能出现故障了那么这两个哨兵就会初步判断主节点出现问题。不过这仅仅是基于部分哨兵的主观判断此时主节点被标记为主观下线Subjectively Down简称 SDown。 而在实际执行故障转移阶段情况则有所不同。即使有足够数量的哨兵判定主节点主观下线了但要真正去执行故障转移操作还需要满足另一个条件那就是其中一个哨兵要被选为故障转移的领导者Leader Sentinel并且这个选择过程需要得到大多数哨兵这里指的是超过一半的哨兵数量的投票授权才行。 为了更清晰地理解举个例子来说明。假设现在部署了 5 个 Sentinel 进程并且给定主节点的仲裁quorum设置为值 2那么会出现以下情况 当有两个哨兵同时同意主节点无法访问时这两个哨兵中的某一个会尝试启动故障转移流程也就是先发起成为领导者并执行故障转移的请求。 然而只有当至少有三个哨兵能够正常通信、处于可访问状态时也就是达到了大多数哨兵的条件这个故障转移的请求才会被授权通过实际的故障转移操作才会真正开始执行。 相反如果在故障期间大部分的 Sentinel 进程之间无法进行通信也就是出现了少数分区的情况导致无法形成多数派的共识那么 Sentinel 是永远不会启动故障转移操作的。所以说quorum 参数的合理设置能够在一定程度上平衡对主节点故障检测的敏感度以及故障转移操作的严谨性帮助我们根据实际的部署环境和需求来灵活调整 Sentinel 的行为策略。 四、Redis 哨兵模式提供的 API 常用 API 介绍 获取当前主机地址 API 在 Redis 哨兵模式的实际应用中常常需要知道当前负责给定服务的 Redis 主机地址尤其是在面对可能发生的故障转移等情况时。这时就可以通过 SENTINEL get-master-addr-by-name 这个 API 来获取相关信息。例如我们有一个名为 mymaster 的 Redis 主节点服务在命令行中输入如下命令 127.0.0.1:5000 SENTINEL get-master-addr-by-name mymaster
执行后它会返回对应的主机地址和端口信息像下面这样 1) 127.0.0.1 2) 6379
其作用在于客户端或者其他需要与 Redis 主节点交互的应用程序无需提前知晓主节点的具体地址只需借助这个 API 向 Sentinel 询问就能动态地获取到准确的主节点地址从而顺利建立连接进行数据的读写等操作极大地提升了整个 Redis 服务使用的灵活性和可靠性保障业务能够持续稳定地运行不受节点变动的影响。 查询主机状态相关 API 在日常对 Redis 哨兵模式的监控和维护过程中需要及时了解主节点的运行状态以及与之相关的副本、其他哨兵等信息。比如sentinel master 命令可以用来检查正在被监控的主节点是否运行良好。例如我们通过以下方式来操作 \( redis-cli -p 5000 127.0.0.1:5000 sentinel master mymaster 通过这个命令可以获取主节点当前基本的状态信息。 而若想进一步探索更多相关信息还可以使用 SENTINEL replicas mymaster 命令它能够提供连接到主服务器的副本的类似信息帮助我们知晓副本节点的数量、状态等情况以便判断数据复制是否正常进行有没有副本节点出现异常等问题。 另外SENTINEL sentinels mymaster 命令则主要用于获取有关其他哨兵的信息比如当前有多少个哨兵在监控这个主节点各个哨兵的运行状态等内容。通过这些命令的综合运用运维人员或者开发人员可以全方位地掌握 Redis 集群中主节点以及周边相关节点的实时状态便于及时发现潜在问题并采取对应的解决措施。 其他实用 API 除了上述常见的 API 之外Redis 哨兵模式还提供了一些其他在日常运维等方面非常实用的 API。例如 sentinel reset 命令它可以重置某个主节点的相关状态信息常用于在一些配置调整或者故障修复后对主节点的部分统计、标记等状态进行初始化操作使其恢复到一个相对初始的干净状态方便后续重新进行准确的监控和判断。 还有 sentinel failover 命令这个命令可以手动触发一次故障转移操作。在某些特定场景下比如我们提前知道主节点即将进行维护或者已经出现了一些潜在问题但还未达到自动故障转移的条件时运维人员可以通过这个命令手动让 Sentinel 执行故障转移流程选择合适的从节点升级为主节点保障 Redis 服务的可用性和数据的正常流转。比如对于名为 mymaster 的主节点执行以下命令 \) redis-cli -p 26379 127.0.0.1:26379 sentinel failover mymaster
就可以启动对应的手动故障转移过程了。这些 API 从不同角度辅助我们更好地管理和维护 Redis 哨兵模式下的集群确保整个系统稳定高效地运行。 五、Redis 哨兵模式隐藏的风险 单点故障风险 在 Redis 哨兵模式中尽管其设计初衷是为了提升 Redis 的高可用性减少因主节点故障等问题导致的服务中断情况但它自身也存在着单点故障的风险隐患。 哨兵节点在整个架构里扮演着极为关键的角色承担着监控 Redis 主从节点状态、发起故障转移等重要任务。例如若某个哨兵节点本身出现硬件故障像服务器硬盘损坏、内存故障等或者软件层面出现问题如程序崩溃、遭遇恶意软件攻击等又或者所在的网络环境出现异常网络连接中断、网络延迟过高长时间无法恢复等就可能致使该哨兵节点无法正常工作。 而一旦有部分哨兵节点失去作用对于那些依赖法定人数quorum来判定主节点是否故障以及进行故障转移的情况来说可能会产生严重影响。比如配置的法定人数是 3原本有 5 个哨兵节点正常运行能较好地保证在主节点出现问题时准确判定并执行故障转移操作。但要是其中 2 个哨兵节点出现故障剩余 3 个哨兵节点在面对主节点故障时虽然刚好达到法定人数能判定主节点客观下线可在后续选举领导者Leader Sentinel以及执行故障转移的过程中如果再有 1 个哨兵节点出现临时的网络抖动等小问题就可能导致无法成功选出领导者进而故障转移操作无法顺利执行整个系统就会陷入故障状态影响 Redis 服务的正常提供对系统的可靠性构成较大威胁。 切换带来的延迟问题 当 Redis 的主库出现故障时哨兵节点会自动介入进行故障转移操作这个过程涉及到一系列的步骤其中就包括选举新的主库。而在这个切换的过程中往往难以避免地会产生网络延迟问题。 首先哨兵节点之间需要相互通信、交换信息来共同判定主节点是否真的出现故障这个信息同步的过程会消耗一定时间。比如各个哨兵节点需要发送如 “sentinel is-master-down-by-addr” 消息来询问、确认主节点的状态网络状况良好时这个消息传递和回复会相对较快但如果网络带宽有限或者存在网络拥塞情况消息的传递就会出现延迟进而拉长整个判定主节点故障的时长。 随后在确定主节点客观下线后要进行选举领导者Leader Sentinel以及选择合适的从节点升级为新主库等操作这些过程同样依赖于网络通信来完成投票、指令传达等环节。而且新主库确定后还需要通知客户端更新连接地址让客户端重新与新主库建立连接客户端获取到新地址并重新发起连接请求这个过程也会受到网络因素影响。在网络延迟较高的情况下就会导致客户端在一段时间内无法正常进行写操作或者读操作如果之前的读请求是指向旧主库且未及时切换的话系统性能会因此出现明显的下降影响业务的正常响应速度尤其是对于那些对实时性要求较高的应用场景这种延迟带来的影响可能会更为突出。 数据丢失风险 Redis 采用的是异步复制机制这一特性在正常运行情况下能保障数据的高效复制与读写性能但在一些特殊场景下却容易引发数据丢失的风险在 Redis 哨兵模式下同样需要重点关注这个问题。 例如在网络分区的情况下也就是部分节点之间的网络连接出现中断、彼此无法正常通信时可能会出现 “脑裂” 现象。具体而言某个主节点所在的机器突然脱离了正常的网络与其他从节点不能连接了但实际上主节点还在运行着。这时哨兵节点由于无法与该主节点通信可能会认为主节点宕机了进而开启选举将其他从节点切换成新的主节点。然而可能客户端还没来得及切换到新的主节点依旧向旧主节点写入数据这些数据后续就会丢失因为当旧主节点再次恢复网络连接重新加入集群时会被作为一个从节点挂到新的主节点上去自身原本的数据会被清空重新从新的主节点复制数据。 为了缓解这种因异步复制以及类似 “脑裂” 情况导致的数据丢失问题可以采用如 “min-replicas-to-write 1”“min-replicas-max-lag 10” 这样的配置。其要求是至少有 1 个从节点并且数据复制和同步的延迟不能超过 10 秒。如果所有的从节点数据复制和同步的延迟都超过了 10 秒钟那么主节点就不会再接收任何请求了。通过这样的配置一定程度上可以减少数据丢失情况的发生比如在从节点复制数据和确认ack延时太长时就认为可能主节点宕机后损失的数据太多了便拒绝写请求将主节点宕机时由于部分数据未同步到从节点导致的数据丢失降低到可控范围内。不过这种配置也存在一定的弊端比如当从节点数量不足或者出现多个从节点同时出现延迟等异常情况时主节点可能会频繁拒绝写请求影响业务的正常写入操作这是一种为了保障数据安全性而在可用性方面做出的权衡。 六、Redis 哨兵模式实现算法 法定人数算法 在 Redis 哨兵模式中法定人数quorum是一个关键概念对于触发故障转移以及后续授权等环节起着决定性作用。 从触发故障转移角度来看quorum 用于判定主节点是否处于不可达或者出现错误的状态。例如每个哨兵会定时向主节点发送 PING 命令做心跳检测若在规定的 “down-after-milliseconds” 时间内达到 quorum 数量的哨兵都没有收到主节点回复的 PING 命令就会认为主节点出现问题此时主节点被标记为主观下线SDown。不过这只是基于部分哨兵的主观判断像配置的 quorum 值为 3 时需要有 3 个哨兵同时觉得主节点有故障才会初步判定主节点主观下线。 而在实际执行故障转移阶段要求会更加严格。即便有足够数量的哨兵判定主节点主观下线了要真正去执行故障转移操作其中一个哨兵要被选为故障转移的领导者Leader Sentinel并且这个选择过程需要得到大多数哨兵超过一半的哨兵数量的投票授权才行。比如有 5 个哨兵进程quorum 设置为 3当 3 个哨兵判定主节点主观下线后想要执行故障转移的那个哨兵必须获得至少 3 个多数派哨兵的授权才能成为领导者进而主导故障转移工作。如果 quorum 配置为 5大于等于多数派那么必须所有 5 个哨兵都同意授权才能执行故障转移。 假设在一个实际部署场景中有 7 个哨兵在监控 Redis 主从节点quorum 设置为 4。当主节点出现网络故障等问题时若有 4 个哨兵同时检测到主节点无响应主节点就会被标记为主观下线。接着这 4 个哨兵中的某一个尝试发起故障转移请求只有当至少再有 3 个一共达到 7 个中的多数即 4 个哨兵认可这个请求并授权时该哨兵才能正式成为领导者去执行故障转移选择合适的从节点升级为新主节点完成后续一系列切换操作。法定人数的合理设置能够依据实际的网络环境、对故障敏感度的要求等因素灵活调整哨兵模式在故障检测以及故障转移方面的行为逻辑保障 Redis 服务的高可用性。 配置时期相关算法 在 Redis 哨兵模式的故障转移过程中配置纪元configuration epoch有着重要意义。当哨兵获得多数人授权启动故障转移时它会为正在故障转移的主机获得一个唯一的配置纪元这个配置纪元本质上就是一个数字相当于一个版本号会在故障转移完成后用于版本化新配置。 由于这个配置纪元是经过大多数哨兵同意分配给执行故障转移的特定哨兵的所以其他哨兵无法使用相同的版本号这就保证了每次故障转移所产生的新配置都有唯一的版本标识。例如在一个包含多个哨兵监控的 Redis 集群里主节点出现故障需要进行故障转移哨兵 A 被选举为领导者且获得授权开始执行故障转移此时它被分配了配置纪元为 5那么在这次故障转移期间及后续相关配置更新时都是基于这个版本号 5 来进行的。 同时哨兵还有相应的时间规则来避免同时多次尝试故障转移同一主机的情况。具体来说有一个规则是如果哨兵投票给另一个哨兵来进行给定主机的故障转移它将等待一段时间来再次尝试故障转移同一主机这个延迟时间是可以在 “sentinel.conf” 中配置的 “2 * failover-timeout”。比如“failover-timeout” 配置为 90 秒那么这个等待时间就是 180 秒。这意味着哨兵们不会无序地同时尝试对同一主机进行故障转移而是按照先后顺序第一个请求授权的哨兵先尝试如果失败了其他哨兵会在规定的等待时间之后再尝试依次类推。 通过这样的机制Redis Sentinel 保证了活性属性只要大多数的哨兵能够正常通信交流最终一定会授权一个哨兵在主服务器关闭时进行故障转移操作。而且还保证了每个哨兵将使用不同的配置时期对同一主机进行故障转移的安全属性避免了因配置混乱而导致的各种潜在问题确保整个 Redis 集群在故障转移过程中的稳定性和数据的正确流转。 配置传播算法 当故障转移成功完成后为了让整个 Redis 集群中的各个哨兵节点都能知晓并更新相关信息哨兵会通过广播新配置的方式来实现配置传播。 具体而言故障转移成功的标志之一是哨兵能够将 “REPLICAOF NO ONE” 命令发送到选定的副本节点并且稍后在主节点的 “INFO” 输出中观察到已经切换到新的主节点状态。一旦满足这个条件即使副本的重新配置工作还在进行当中也会认为故障转移已经成功此时所有的哨兵都需要开始报告新的配置信息了。 而传播新配置主要是依靠 Redis 的 Pub/Sub 消息机制每个哨兵都使用这个机制在主机以及所有副本所在的相关频道中不断广播其主机配置版本。所有的哨兵同时也都在等待接收消息通过对比其他哨兵宣传的配置版本号来决定是否更新自己的配置。这些配置信息都是在 “sentinel:hello” 这个 Pub/Sub 频道中进行广播的。 由于每个配置都带有不同的版本号也就是配置纪元并且遵循大版本号总是胜过小版本号的原则所以整个配置传播和更新的过程是有序且可靠的。例如一开始所有哨兵都认为主节点 mymaster 处于 192.168.1.50:6379 这个地址其配置版本为 1。一段时间后某个哨兵被授权使用版本 2 进行故障转移并且故障转移成功了它就会开始广播新的配置比如新的主节点地址变成了 192.168.1.50:9000版本号为 2。其他的哨兵接收到这个带有更大版本号的新配置消息后就会相应地更新自己所记录的主节点配置信息从而保证整个集群中的所有哨兵对于主节点的配置认知最终能够达成一致实现配置的收敛维持集群的稳定运行状态。 分区下一致性算法 在实际的网络环境中可能会出现网络分区的情况此时涉及 Redis 实例、哨兵实例、客户这三者之间的系统行为一致性就变得尤为重要其背后有着特定的算法逻辑来保障整体的协调运行。 当网络分区发生时不同分区内的节点之间无法正常通信就可能出现各种不一致的情况。比如在一个简单的网络场景里有 3 个节点每个节点运行一个 Redis 实例和一个哨兵实例初始状态是 Redis 3 是主机Redis 1 和 2 是副本。如果发生分区隔离了旧主机Redis 3 所在分区那么其他分区中的哨兵 1 和 2 会开始故障转移将哨兵 1 提升为新主机此时哨兵 1 和 2 会拥有主服务器的新配置。然而处于不同分区的哨兵 3 仍然保留着旧的配置。 对于客户端来说如果有客户端与旧主分区仍连接着 Redis 3在分区期间客户端可能依旧向旧主机写入数据。但当分区重新恢复连接时Redis 3 会变成 Redis 1 的副本分区期间写入的数据就会丢失。针对这种情况要依据具体的应用场景和需求来决定是否允许这样的数据丢失情况发生。 如果将 Redis 用作缓存一定程度上允许客户端继续向旧主机写入数据即使数据后续会丢失可能影响不大但要是将 Redis 用作数据存储这种情况就不太能接受了此时可以通过一些 Redis 配置选项来尽量减少数据丢失风险比如配置 “min-replicas-to-write 1” 和 “min-replicas-max-lag 10”。这意味着当 Redis 实例充当主服务器时如果它不能写入至少一个副本要么副本断开连接要么副本没有在规定的 10 秒内发送异步确认主服务器就会停止接受写入操作。按照这样的配置上述例子中的 Redis 3 在 10 秒后就会变得不可用等到分区愈合时哨兵 3 的配置会收敛到新配置客户端也能够获取到有效配置并继续正常工作。 总体而言RedisSentinel 作为一个整体是一个最终一致的系统在分区等特殊情况下遵循最后一次故障转移