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

Redis集群模式之Redis Cluster(2)

        上篇文章我们讲解了Redis Cluster中的主要模块和两种重定向方式,这篇文章我们来讲解一下Redis Cluster的状态监测和维护。

Redis Cluster状态监测及维护

        要讲解Redis Cluster中节点的状态如何维护,我们要先知道Redis Cluster中的节点有哪些状态,gossip协议是什么以及具体的通讯(心跳)机制。

节点状态

        Redis Cluster中的每个节点都维护着一份在自己看来当前整个集群的状态,主要包括:

        (1)当前集群的状态;

        (2)集群中各节点所负责的Slots信息,及其migrate状态;

        (3)集群中各节点的Master-Slave状态;

        (4)集群中各节点的存活状态及不可达投票。

        当集群的状态发生变化时,比如新节点的加入、Slot迁移、节点宕机、新Master的出现等,我们希望这些变化尽快的被发现,传播到整个集群的所有节点并达成一致。节点之间相互的心跳(PING、PONG、MEET)及其携带的数据是集群状态传播最主要的途径。

gossip协议

        gossip协议又称为epidemic协议,是基于流行病传播方式的节点或进程之间信息交换的协议。在分布式系统中被广泛使用,比如我们可以使用gossip协议来确保网络中所有节点的数据一样。

        gossip协议已经是P2P网络中比较成熟的协议了。gossip协议的最大好处是,即使集群节点的数量增加,每个节点的负载也不会增加很多,几乎是恒定的。这就允许Consul管理的集群规模能横向扩展到数千个节点。

        Redis集群是去中心化的,彼此之间状态同步靠gossip协议通信,集群的消息有以下几种类型:

        (1)Meet:通过cluster meet ip port命令,已有集群的节点会向新的节点发送邀请,加入现有集群。

        (2)Ping:节点每秒会向集群中其他节点发送Ping消息,消息中带有自己已知的两个节点的地址、槽、状态信息、最后一次通信时间等。

        (3)Pong:节点收到Ping消息后会回复Pong消息,消息中同样带有自己已知的两个节点消息。

        (4)Fail:节点Ping不通某节点后,会向集群所有节点广播该节点挂掉的消息。其他节点收到消息后标记为已下线。        

        集群中的每个节点都会定期地向集群中的其他节点发送PING消息,以此交换各个节点状态信息,检测各个节点的状态:在线状态、疑似下线状态PFAIL、已下线状态FAIL。

        当主节点A通过消息得知主节点B认为主节点D进入疑似下线状态时,主节点A会在自己的clusterState.nodes字典中找到主节点D所对应的clusterNode结构,并将主节点B的下线报告添加到clusterNode结构的fail_reports链表中,并后续关于节点D疑似下线的状态通过gossip协议通知其他节点。

        如果集群中,半数以上的主节点都将主节点D报告为下线状态,那么主节点D就被标记为已下线状态,将主节点D标记为已下线的节点会向集群广播主节点D的Fail消息,所有收到Fail消息的节点都会立即更新nodes里面主节点D的状态,标记为已下线。

        将node标记为FAIL需要满足一下两个条件:①有半数以上的主节点将node标记为PFAIL状态。②当前节点也将node标记为PFAIL状态。

通讯状态和维护

        什么时候进行心跳?

        Redis节点会记录其向每一个节点上一次发出ping和收到pong的时间,心跳发送时机与这两个值有关。通过下面的方式既能保证及时更新集群状态,又不至于使心跳次数过多:

        (1)每次Cron向所有未建立链接的节点发送ping或meet;

        (2)每1秒从所有已知节点中随机选取5个,向其中上次收到的pong最久远的一个发送ping。

        (3)每次Cron向收到pong超过timeout/2的节点发送pong;

        (4)收到ping或者meet,立即回复pong。

        发送哪些心跳数据?

        (1)Header:发送者自己的信息,包括所负责的slots信息、主从信息、ip port信息和状态信息。

        (2)gossip:发送者所了解的部分其他节点的信息,包括ping_sent,pong_received、ip,port信息、状态信息(比如发送者认为该节点已经不可达,会在状态信息中标记其为PFAIL或FAIL)。

        如何处理心跳数据?

        (1)新节点的加入。发送meet包加入集群,从pong包中的gossip得到未知的其他节点。通过循环上述过程,直到最终加入集群。

        (2)slots信息。判断发送者声明的slots信息,跟本地记录的是否有不同。如果不同,并且发送者epoch较大,更新本地记录;如果不同,并且发送者epoch比较小,发送update信息通知发送者。

        (3)Master slave信息。发现发送者的master、slave信息变化,更新本地状态。

        (4)节点FAIL探测(故障发现)。超过超时时间仍然没有收到pong包的节点会被当前节点标记为PFAIL;PFAIL标记会随着gossip传播;每次收到心跳包会检测其中对其他节点的PFAIL标记,当做对该节点FAIL的投票维护在本机;对某个节点的PFAIL标记达到大多数时,将其变为FAIL标记并广播FAIL消息。

        gossip的存在使得集群状态的改变可以更快的达到整个集群。每个心跳包中会包含多个gossip包,那么多少个才是合适的呢,Redis的选择是N/10,其中N是节点数,这样可以保证在PFAIL投票的过期时间内,节点可以收到80%机器关于失败节点的gossip,从而使其顺利进入Fail状态。

        如何将信息广播给其它节点?

        当需要发布一些非常重要需要立即送达的消息时,上述心跳+gossip的方式就显得捉襟见肘了,这时就需要向所有集群内的机器广播信息,使用广播发的场景:

        节点的Fail信息:当发现某一节点不可达时,探测节点会将其标记为PFAIL状态,并通过心跳传播出去。当某一节点发现这个节点的PFAIL超过半数时修改其为FAIL并发起广播。

        Failover Request信息:slave尝试发起FailOver时广播其要求投票的信息。

        新Master信息:Failover成功的节点向整个集群广播自己的信息。

故障恢复

        当slave发现自己的master变为FAIL状态时,便尝试进行Failover,以期成为新的Master。由于挂掉的Master可能会有多个Slave。Failover的过程需要经过类Raft协议的过程在整个集群内达到一致,具体的过程如下:

        (1)Slave发现自己的Master变为FAIL;

        (2)将自己记录的集群currentepoch+1,并广播Failover Request信息;

        (3)其他节点收到该消息,只有Master响应,判断请求者的合法性,并发送FAILOVER_AUTH_ACK,对每一个epoch只发送一次ack;

        (4)尝试Failover的Slave收集FAILOVER_AUTH_ACK;

        (5)超过半数后变为新Master;

        (6)广播Pong通知其他集群节点。

        这篇文章我们主要讲解了Redis Cluster的状态监测和维护,大家有什么问题或勘误可以在评论区留言,笔者看到都会回复的。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.dtcms.com/a/249377.html

相关文章:

  • PHP+mysql雪里开轻量级报修系统 V1.0Beta
  • 端到端记忆网络 vs 神经图灵机:外部记忆的两种哲学之争
  • PHP、Apache环境中部署sqli-labs
  • 创客匠人解析:美团护城河战略对 IP 可持续变现的启示
  • 查看哪些IP在向kafka的broker生产消息
  • SLAM文献之-LOAM: Lidar Odometry and Mapping in Real-time
  • 2025-06-14【视觉】视频转化为图集
  • 2.4.1 ASPICE的编码与单元测试
  • 新能源汽车电子架构革命:深度解析AUTOSAR标准与实践
  • leetcode_49 字母异位分组
  • 写出优秀的 Git 提交信息:一份详尽指南(Angular 风格)
  • 板凳-------Mysql cookbook学习 (十--6)
  • 1 Studying《Arm A715 Software Optimization Guide》
  • Vue 事件修饰符详解
  • Java相关-链表-设计链表-力扣707
  • JavaScript基础-阻止事件冒泡
  • Linux 系统目录结构概述-linux024
  • 实现回显服务器(基于UDP)
  • 自定义 eslint 规则
  • PDF转Markdown基准测试
  • SKUA-GOCAD入门教程-第八节 线的创建与编辑3
  • uniapp的app项目,在华为pad上运行,页面显示异常
  • Odoo 如何系统地管理产品从概念设计到废弃淘汰的全过程
  • pycharm 2025.1.1-专业版jupyter notebook远程连接
  • 从STM32到NXP:GPIO就像装修房子,多了个“智能开关”
  • RabbitMQ的交换机和队列概念
  • 前端面试专栏-主流框架:7. React核心概念(组件、JSX、状态管理)
  • 从数据孤岛到智能决策:数据编排如何重构企业数据架构?
  • Java重构实战:小步快跑的高效策略分析
  • 创客匠人:AI重构知识IP定位与变现效率新范式