CN109286529A - 一种恢复RabbitMQ网络分区的方法及系统 - Google Patents
一种恢复RabbitMQ网络分区的方法及系统 Download PDFInfo
- Publication number
- CN109286529A CN109286529A CN201811289763.7A CN201811289763A CN109286529A CN 109286529 A CN109286529 A CN 109286529A CN 201811289763 A CN201811289763 A CN 201811289763A CN 109286529 A CN109286529 A CN 109286529A
- Authority
- CN
- China
- Prior art keywords
- node
- state
- rabbitmq
- service
- network
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0663—Performing the actions predefined by failover planning, e.g. switching to standby network elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/02—Standardisation; Integration
- H04L41/0246—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols
- H04L41/0253—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols using browsers or web-pages for accessing management information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
- H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1034—Reaction to server failures by a load balancer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0668—Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
- H04L67/025—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Environmental & Geological Engineering (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种恢复RabbitMQ网络分区的方法及系统,涉及分布式消息系统技术领域,在每个RabbitMQ节点配置Keepalived服务,Keepalived主节点作为中心节点,在每个RabbitMQ节点配置集群状态检测脚本,仅中心节点运行检测脚本,对所有RabbitMQ节点进行周期性集群状态检测,根据检测结果执行对应的恢复操作;每次检测结束时,在所有RabbitMQ节点写入记录检测结果的状态检测文件;在每个RabbitMQ节点配置xinetd服务,将状态检测文件暴露给HTTP接口;配置HAProxy软件调用HTTP接口进行节点健康检测,相关应用客户端通过调用HAProxy软件调用RabbitMQ服务。实现自动检测故障并自动恢复,减轻运维人员工作量。
Description
技术领域
本发明涉及分布式消息系统技术领域,具体涉及一种恢复RabbitMQ网络分区的方法及系统。
背景技术
RabbitMQ是一个由erlang开发的基于高级消息队列协议(AMQP,AdvancedMessage Queue)协议的开源实现,用于在分布式系统中存储转发消息,在易用性、扩展性、高可用性等方面都非常的优秀,是当前最主流的消息中间件之一。RabbitMQ集群应用非常广泛,尤其是在需要跨系统异步通信的应用场景比如云计算领域。当多节点出现网络抖动时,集群容易出现网络分区,而RabbitMQ集群自身无法很好的应对网络分区情况。
判定出现网络分区的定义是:如果其他节点无法连接该节点的时间达到1分钟以上,当这两个节点恢复到能联系上的状态时,都会认为对端节点已down掉了,此时Mnesia将会判定发生了网络分区。(Mnesia是一个分布式数据库管理系统,是构建电信应用的控制系统平台开放式电信平台的一部分。)
例如,在实际三节点RabbitMQ测试时,在集群某两个RabbitMQ节点执行管理网网卡闪断操作30次,持续大概一分半钟,将会有很大概率出现网络分区。
当发生网络分区时,可能会产生两个或多个分区,同时认为其他分区里面的节点已经不可用。由于网络分区而被割裂的镜像队列最终会在每个分区中产生一个master,每个分区均能够独立工作(如果达到集群工作条件),也可能发生其他未定义和奇怪的行为。另外,当网络分区情况得到恢复后,问题依旧存在,需要手动按照步骤进行修复。参见图1所示,此时通过RabbitMQ的web管理界面看告警。
一般情况下,针对RabbitMQ网络分区问题处理,有如下方法:
一、手动处理网络分区:
为了从网络分区中恢复,首先需要挑选一个信任的分区,这个分区才有决定Mnesia内容的权限,发生在其他分区的改变将不被记录到Mnesia中而直接丢弃。手动恢复网络分区有两种思路:
1.停止其他分区中的节点,然后重新启动这些节点。最后重启信任分区中的节点,以去除告警。当出现分区时,当网络恢复或者挂起恢复后,分区独立问题仍旧存在,需要手动恢复。
2.关闭整个集群的节点,然后再启动每一个节点,这里需确保启动的第一个节点在信任的分区之中。
二、自动处理网络分区:
RabbitMQ提供了4种处理网络分区的方式,在详细配置参数rabbitmq.config中配置cluster_partition_handling参数即可,分别为:
1.ignore
2.pause_minority
3.pause_if_all_down,[nodes],ignore|autoheal
4.autoheal
ignore的配置是当网络分区的时候,RabbitMQ不会自动做任何处理,即需要手动处理。
pause_minority配置后,当发生网络分区时,集群中的节点在观察到某些节点down掉时,会自动检测其自身是否处于少数派(小于或者等于集群中一般的节点数)。少数派中的节点在分区发生时会自动关闭,当分区结束时又会启动。需要注意的是RabbitMQ也会关闭不是严格意义上的大多数,如果节点为偶数个,可能导致所有节点都down掉。
在pause_if_all_down模式下,RabbitMQ会自动关闭不能和list中节点通信的节点。需要在配置文件中事先配置好指定的list,如果一个节点与list中的所有节点都无法通信时,自关闭其自身。如果list中的所有节点都down时,其余节点如果是ok的话,也会根据这个规则去关闭其自身,此时集群中所有的节点会关闭。并且需要事先手动配置信任节点,但生产环境中无法保证某些节点服务可靠性更高。
在autoheal模式下,当认为发生网络分区时,RabbitMQ会自动决定一个获胜的分区,然后重启不在这个分区中的节点以恢复网络分区。但即使配置后,网络恢复后,仍旧可能需要手动处理。
可见自动网络分区并不能保证节点不出任何问题,在任何时候都能自动恢复。存在如下缺点:
1)当出现分区时,当网络恢复或者挂起恢复后,分区独立问题仍旧存在,需要手动恢复;
2)当一个或者多个节点出现故障时,没有节点状态监控机制,无法自动恢复;
3)可能需要事先手动配置信任节点,但生产环境中无法保证某些节点服务可靠性更高。
发明内容
针对现有技术中存在的缺陷,本发明的目的在于提供一种恢复RabbitMQ网络分区的方法及系统,当出现网络分区后,自动检测故障并自动恢复,减轻运维人员工作量,增强系统可靠性。
为达到以上目的,本发明采取的技术方案是:一种恢复RabbitMQ网络分区的方法,包括以下步骤:
在每个RabbitMQ节点配置Keepalived服务,选取RabbitMQ集群中一个RabbitMQ节点作为Keepalived主节点,将Keepalived主节点作为中心节点;
在每个RabbitMQ节点配置集群状态检测脚本,仅中心节点运行集群状态检测脚本,对所有RabbitMQ节点进行集群状态检测,并根据检测结果执行对应的恢复操作;每次检测结束时,在所有RabbitMQ节点写入用于记录检测结果的状态检测文件;
在每个RabbitMQ节点配置xinetd服务,将状态检测文件暴露给HTTP接口;
配置HAProxy软件调用HTTP接口进行节点健康检测,应用客户端通过调用HAProxy软件调用RabbitMQ服务。
在上述技术方案的基础上,所述仅中心节点运行集群状态检测脚本,对所有RabbitMQ节点进行集群状态检测,具体包括以下步骤:
所述集群状态包括:网络状态,单节点服务状态和网络分区状态;
所述单节点服务状态以及网络分区状态通过RabbitMQ节点的API去获取;所述网络状态通过socket获取。
在上述技术方案的基础上,所述仅中心节点运行集群状态检测脚本,对所有RabbitMQ节点进行集群状态检测,还包括以下步骤:
进行集群状态检测时,所述集群状态的优先级由高至低依次为网络状态,单节点服务状态和网络分区状态;
若网络状态异常,则不去判断剩下状态,直接记录该节点网络状态异常;
若单节点服务异常,则不会判断网络分区状态,记录该节点服务异常;
若网络正常以及服务正常,则去判断是否有网络分区发生。
在上述技术方案的基础上,所述根据检测结果执行对应的恢复操作,具体包括以下步骤:
针对网络异常,默认该节点不采取任何措施,等待下一个周期检测网络恢复再进行判断;
针对检测后的服务异常,如果服务异常节点数量小于节点总数量的一半,执行重启异常节点RabbitMQ服务的命令;如果超过节点总数量的一半,执行重启所有节点RabbitMQ服务的命令;
针对分区异常,按照预设方法执行分区恢复脚本。
在上述技术方案的基础上,该方法还包括以下步骤,当所述Keepalived主节点出现故障时,执行主备切换。
本发明还公开了一种恢复RabbitMQ网络分区的系统,包括:
Keepalived服务配置模块,其用于:在每个RabbitMQ节点配置Keepalived服务,选取RabbitMQ集群中一个RabbitMQ节点作为Keepalived主节点,将Keepalived主节点作为中心节点;
状态检测模块,其用于:在每个RabbitMQ节点配置集群状态检测脚本,仅中心节点运行集群状态检测脚本,对所有RabbitMQ节点进行集群状态检测,并根据检测结果执行对应的恢复操作;每次检测结束时,在所有RabbitMQ节点写入用于记录检测结果的状态检测文件;
接口配置模块,其用于:在每个RabbitMQ节点配置xinetd服务,将状态检测文件暴露给HTTP接口;
HAProxy软件配置模块,其用于:配置HAProxy软件调用HTTP接口进行节点健康检测;应用客户端通过调用HAProxy软件调用RabbitMQ服务。
在上述技术方案的基础上,所述仅中心节点运行集群状态检测脚本,对所有RabbitMQ节点进行集群状态检测,具体包括以下步骤:
所述集群状态包括:网络状态,单节点服务状态和网络分区状态;
所述单节点服务状态以及网络分区状态通过RabbitMQ节点的API去获取;所述网络状态通过socket获取。
在上述技术方案的基础上,所述仅中心节点运行集群状态检测脚本,对所有RabbitMQ节点进行集群状态检测,还包括以下步骤:
进行集群状态检测时,所述集群状态的优先级由高至低依次为网络状态,单节点服务状态和网络分区状态;
若网络状态异常,则不去判断剩下状态,直接记录该节点网络状态异常;
若单节点服务异常,则不会判断网络分区状态,记录该节点服务异常;
若网络正常以及服务正常,则去判断是否有网络分区发生。
在上述技术方案的基础上,所述根据检测结果执行对应的恢复操
作,具体包括以下步骤:
针对网络异常,默认该节点不采取任何措施,等待检测网络恢复再进行判断;
针对检测后的服务异常,如果服务异常节点数量小于节点总数量的一半,执行重启异常节点RabbitMQ服务的命令;如果超过节点总数量的一半,执行重启所有节点RabbitMQ服务的命令;
针对分区异常,按照预设方法执行分区恢复脚本。
在上述技术方案的基础上,所述Keepalived服务配置模块还用于:当所述Keepalived主节点出现故障时,执行主备切换。
与现有技术相比,本发明的优点在于:
(1)本发明在每个RabbitMQ节点配置Keepalived服务,其中一个RabbitMQ节点作为Keepalived主节点,Keepalived主节点作为中心节点,在每个RabbitMQ节点配置集群状态检测脚本,仅中心节点运行集群状态检测脚本,对所有RabbitMQ节点进行集群状态检测,并根据检测结果执行对应的恢复操作;每次检测结束时,在所有RabbitMQ节点写入记录检测结果的状态检测文件;在每个RabbitMQ节点配置xinetd服务,将状态检测文件暴露给HTTP接口;配置HAProxy软件调用HTTP接口进行节点健康检测,客户端通过调用HAProxy软件调用RabbitMQ节点。当出现网络分区后,自动检测故障并自动恢复,避免人工干预,减轻运维人员工作量;
2)支持检测网络分区以外的原因引起的任意RabbitMQ节点的故障,并且自动恢复,增强系统可靠性。
3)客户端通过调用HAProxy软件调用RabbitMQ节点,实现RabbitMQ集群的负载均衡。
附图说明
图1为背景技术中RabbitMQ的web管理界面告警示意图;
图2为本发明实施例中恢复RabbitMQ网络分区的方法的原理示意图;
图3为本发明实施例中恢复RabbitMQ网络分区的方法的流程示意图。
具体实施方式
术语说明:
HAProxy:一个使用C语言编写的自由及开放源代码软件[1],其提供高可用性、负载均衡,以及基于TCP和HTTP的应用程序代理。
MQ:全称为Message Queue,消息队列,是一种应用程序对应用程序的通信方法。RabbitMQ是MQ的一种开源实现。
Xinetd:xinetd即extended internet daemon,扩展互联网守护进程。xinetd是新一代的网络守护进程服务程序,又叫超级Internet服务器。经常用来管理多种轻量级Internet服务。xinetd提供类似于inetd+tcp_wrapper的功能,但是更加强大和安全。
以下结合附图及实施例对本发明作进一步详细说明。
实施例1:
参见图2所示,本发明实施例提供一种恢复RabbitMQ网络分区的方法,包括以下步骤:
首先选取中心节点,中心节点是选取RabbitMQ集群的某一个节点作为恢复检测脚本运行的中心节点,集群中另外节点也有脚本存在,但是没有当即运行。通过Keepalived来实现主备的监控切换,Keepalived主节点即为中心节点;当Keepalived主节点发生网络故障时,会自动切换到备用节点继续进行监控。
然后定义针对不同场景的检测和恢复脚本。将影响RabbitMQ的集群状态主要分为三类:网络状态,单节点服务状态,网络分区状态。单节点服务状态以及网络分区状态通过RabbitMQ自带的API去获取;网络状态通过socket来获取。三状态的优先级依次降低,即满足网络状态异常,则不去判断剩下状态,直接记录该节点网络状态异常;否则如果单节点服务异常,则不会判断网络分区状态,记录该节点服务异常;最后如果满足网络正常以及服务正常,则去判断是否有网络分区发生。通过上述判断过程,得到一个集群节点状态的返回对象cluster_status,针对此状态进行进一步判断并根据特定场景执行特定恢复步骤。中心节点每次检测结束会远程各个节点生成状态文件。
针对网络异常,默认该节点不采取任何措施,等待检测网络恢复再进行判断;
针对检测后的服务异常,如果服务异常节点数量小于集群节点总数量的一半,则执行重启异常节点RabbitMQ服务的命令,如果超过集群节点总数量的一半,则认为集群不可用,会执行重启集群所有节点服务的脚本;
针对分区异常,只要任意节点发生网络分区,则会按照指定方法执行分区恢复脚本;
最后增加HAProxy,由xinted将状态文件暴露出指定服务端口供haproxy进行节点健康状态判断,通过haproxy实时反馈状态结果,组件通过HAProxy调用服务,从而实现负载均衡。
采用本发明实施例的方法,当出现网络分区后,自动检测故障并自动恢复,避免人工干预,减轻运维人员工作量。
实施例2:
参见图3所示,本发明实施例提供一种恢复RabbitMQ网络分区的方法,具体包括以下步骤:
步骤1:在每个RabbitMQ节点配置Keepalived服务,配置Keepalived检测脚本,自动将Keepalived主节点作为中心节点。当Keepalived主节点出现故障时,会自动主备切换。进入步骤2;
步骤2:在每个RabbitMQ节点增加集群状态检测脚本,配置只有Keepalived主节点也就是中心节点才会运行检测脚本,其它节点不运行;并将检测结果状态检测文件写入每个节点。首先通过socket检测该节点网络状态是否异常,若是则不去判断剩下状态,直接记录该节点网络状态异常,并跳至步骤5;若否,跳至步骤3;
步骤3:当网络状态正常时,通过RabbitMQ API检测该节点服务是否异常,若是则不会判断网络分区状态,记录该节点服务异常,跳至步骤6;若否,跳至步骤4;
步骤4:如果满足网络正常以及服务正常,则通过RabbitMQ API检测去判断是否有网络分区发生,若是,跳至步骤7;若否,跳至步骤8;
步骤5:当节点网络异常时,不处理;跳至步骤8;
步骤6:当节点服务异常时,根据异常节点的个数,执行不同的恢复操作;跳至步骤8;
步骤7:当节点出现网络分区时,按照指定方法恢复分区;跳至步骤8;
步骤8:每个节点配置xinetd服务,将状态检测文件暴露HTTP接口用于HAProxy健康检测,进入步骤9;
步骤9:配置HAProxy调用检测接口,检测当前节点的服务状态,进入步骤10;
步骤10:应用客户端调用HAProxy前端服务来调用RabbitMQ服务,结束。
本发明实施例的方法支持检测网络分区以外的原因引起的任意RabbitMQ节点的故障,并且自动恢复,增强系统可靠性。
实施例3:
本发明实施例提供一种恢复RabbitMQ网络分区的系统,包括:
Keepalived服务配置模块,其用于:在每个RabbitMQ节点配置Keepalived服务,选取RabbitMQ集群中一个RabbitMQ节点作为Keepalived主节点,将Keepalived主节点作为中心节点;
状态检测模块,其用于:在每个RabbitMQ节点配置集群状态检测脚本,仅中心节点运行集群状态检测脚本,对所有RabbitMQ节点进行集群状态检测,并根据检测结果执行对应的恢复操作;每次检测结束时,在所有RabbitMQ节点分别写入记录检测结果的状态检测文件;
接口配置模块,其用于:在每个RabbitMQ节点配置xinetd服务,将状态检测文件暴露给HTTP接口;
HAProxy软件配置模块,其用于:配置HAProxy软件调用HTTP接口进行节点健康检测;应用客户端通过调用HAProxy软件调用RabbitMQ服务。
采用本发明实施例的系统,当出现网络分区后,自动检测故障并自动恢复,避免人工干预,减轻运维人员工作量。
本发明不局限于上述实施方式,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也视为本发明的保护范围之内。本说明书中未作详细描述的内容属于本领域专业技术人员公知的现有技术。
Claims (10)
1.一种恢复RabbitMQ网络分区的方法,其特征在于,包括以下步骤:
在每个RabbitMQ节点配置Keepalived服务,选取RabbitMQ集群中一个RabbitMQ节点作为Keepalived主节点,将Keepalived主节点作为中心节点;
在每个RabbitMQ节点配置集群状态检测脚本,仅中心节点运行集群状态检测脚本,对所有RabbitMQ节点进行集群状态检测,并根据检测结果执行对应的恢复操作;每次检测结束时,在所有RabbitMQ节点写入用于记录检测结果的状态检测文件;
在每个RabbitMQ节点配置xinetd服务,将状态检测文件暴露给HTTP接口;
配置HAProxy软件调用HTTP接口进行节点健康检测,应用客户端通过调用HAProxy软件调用RabbitMQ服务。
2.如权利要求1所述的方法,其特征在于:所述仅中心节点运行集群状态检测脚本,对所有RabbitMQ节点进行集群状态检测,具体包括以下步骤:
所述集群状态包括:网络状态,单节点服务状态和网络分区状态;
所述单节点服务状态以及网络分区状态通过RabbitMQ节点的API去获取;所述网络状态通过socket获取。
3.如权利要求1所述的方法,其特征在于:所述仅中心节点运行集群状态检测脚本,对所有RabbitMQ节点进行集群状态检测,还包括以下步骤:
进行集群状态检测时,所述集群状态的优先级由高至低依次为网络状态,单节点服务状态和网络分区状态;
若网络状态异常,则不去判断剩下状态,直接记录该节点网络状态异常;
若单节点服务异常,则不会判断网络分区状态,记录该节点服务异常;
若网络正常以及服务正常,则去判断是否有网络分区发生。
4.如权利要求1所述的方法,其特征在于:所述根据检测结果执行对应的恢复操作,具体包括以下步骤:
针对网络异常,默认该节点不采取任何措施,等待下一个周期检测网络恢复再进行判断;
针对检测后的服务异常,如果服务异常节点数量小于节点总数量的一半,执行重启异常节点RabbitMQ服务的命令;如果超过节点总数量的一半,执行重启所有节点RabbitMQ服务的命令;
针对分区异常,按照预设方法执行分区恢复脚本。
5.如权利要求1所述的方法,其特征在于:该方法还包括以下步骤,当所述Keepalived主节点出现故障时,执行主备切换。
6.一种恢复RabbitMQ网络分区的系统,其特征在于,包括:
Keepalived服务配置模块,其用于:在每个RabbitMQ节点配置Keepalived服务,选取RabbitMQ集群中一个RabbitMQ节点作为Keepalived主节点,将Keepalived主节点作为中心节点;
状态检测模块,其用于:在每个RabbitMQ节点配置集群状态检测脚本,仅中心节点运行集群状态检测脚本,对所有RabbitMQ节点进行集群状态检测,并根据检测结果执行对应的恢复操作;每次检测结束时,在所有RabbitMQ节点写入用于记录检测结果的状态检测文件;
接口配置模块,其用于:在每个RabbitMQ节点配置xinetd服务,将状态检测文件暴露给HTTP接口;
HAProxy软件配置模块,其用于:配置HAProxy软件调用HTTP接口进行节点健康检测;应用客户端通过调用HAProxy软件调用RabbitMQ服务。
7.如权利要求6所述的系统,其特征在于:所述仅中心节点运行集群状态检测脚本,对所有RabbitMQ节点进行集群状态检测,具体包括以下步骤:
所述集群状态包括:网络状态,单节点服务状态和网络分区状态;
所述单节点服务状态以及网络分区状态通过RabbitMQ节点的API去获取;所述网络状态通过socket获取。
8.如权利要求6所述的系统,其特征在于:所述仅中心节点运行集群状态检测脚本,对所有RabbitMQ节点进行集群状态检测,还包括以下步骤:
进行集群状态检测时,所述集群状态的优先级由高至低依次为网络状态,单节点服务状态和网络分区状态;
若网络状态异常,则不去判断剩下状态,直接记录该节点网络状态异常;
若单节点服务异常,则不会判断网络分区状态,记录该节点服务异常;
若网络正常以及服务正常,则去判断是否有网络分区发生。
9.如权利要求6所述的系统,其特征在于:所述根据检测结果执行对应的恢复操作,具体包括以下步骤:
针对网络异常,默认该节点不采取任何措施,等待检测网络恢复再进行判断;
针对检测后的服务异常,如果服务异常节点数量小于节点总数量的一半,执行重启异常节点RabbitMQ服务的命令;如果超过节点总数量的一半,执行重启所有节点RabbitMQ服务的命令;
针对分区异常,按照预设方法执行分区恢复脚本。
10.如权利要求6所述的系统,其特征在于:所述Keepalived服务配置模块还用于:当所述Keepalived主节点出现故障时,执行主备切换。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811289763.7A CN109286529B (zh) | 2018-10-31 | 2018-10-31 | 一种恢复RabbitMQ网络分区的方法及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811289763.7A CN109286529B (zh) | 2018-10-31 | 2018-10-31 | 一种恢复RabbitMQ网络分区的方法及系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN109286529A true CN109286529A (zh) | 2019-01-29 |
CN109286529B CN109286529B (zh) | 2021-08-10 |
Family
ID=65174281
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201811289763.7A Active CN109286529B (zh) | 2018-10-31 | 2018-10-31 | 一种恢复RabbitMQ网络分区的方法及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN109286529B (zh) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110290012A (zh) * | 2019-07-03 | 2019-09-27 | 浪潮云信息技术有限公司 | RabbitMQ集群故障的检测恢复系统及方法 |
CN110430071A (zh) * | 2019-07-19 | 2019-11-08 | 云南电网有限责任公司信息中心 | 业务节点故障自愈方法、装置、计算机设备及存储介质 |
CN110688284A (zh) * | 2019-09-29 | 2020-01-14 | 武汉易酒批电子商务有限公司 | 一种管理和监控RabbitMq消息队列的方法及系统 |
CN111737079A (zh) * | 2020-05-20 | 2020-10-02 | 山东鲸鲨信息技术有限公司 | 一种集群网络的监控方法和装置 |
CN112187877A (zh) * | 2020-09-10 | 2021-01-05 | 华云数据控股集团有限公司 | 一种基于分布式集群的节点唤醒方法及受控终端 |
CN112667449A (zh) * | 2020-12-29 | 2021-04-16 | 新华三技术有限公司 | 一种集群管理方法及装置 |
CN113438111A (zh) * | 2021-06-23 | 2021-09-24 | 华云数据控股集团有限公司 | 基于Raft分布式恢复RabbitMQ网络分区的方法及应用 |
CN115037595A (zh) * | 2022-04-29 | 2022-09-09 | 北京华耀科技有限公司 | 网络恢复方法、装置、设备及存储介质 |
CN117395263A (zh) * | 2023-12-12 | 2024-01-12 | 苏州元脑智能科技有限公司 | 一种数据同步方法、装置、设备和存储介质 |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101582787A (zh) * | 2008-05-16 | 2009-11-18 | 中兴通讯股份有限公司 | 一种双机备份系统及备份方法 |
CN103647668A (zh) * | 2013-12-16 | 2014-03-19 | 上海证券交易所 | 一种高可用集群内主机群体决策系统及切换方法 |
US20140137187A1 (en) * | 2012-11-14 | 2014-05-15 | Microsoft Corporation | Scalable and Highly Available Clustering for Large Scale Real-Time Applications |
CN105205003A (zh) * | 2015-10-28 | 2015-12-30 | 努比亚技术有限公司 | 一种基于集群化系统的自动化测试方法和装置 |
CN106131122A (zh) * | 2016-06-21 | 2016-11-16 | 浪潮电子信息产业股份有限公司 | 一种部署负载均衡服务的方法及装置 |
CN107147540A (zh) * | 2017-07-19 | 2017-09-08 | 郑州云海信息技术有限公司 | 高可用性系统中的故障处理方法和故障处理集群 |
CN108173971A (zh) * | 2018-02-05 | 2018-06-15 | 江苏物联网研究发展中心 | 一种基于主备切换的MooseFS高可用方法及系统 |
US10095547B1 (en) * | 2015-03-13 | 2018-10-09 | Twitter, Inc. | Stream processing at scale |
-
2018
- 2018-10-31 CN CN201811289763.7A patent/CN109286529B/zh active Active
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101582787A (zh) * | 2008-05-16 | 2009-11-18 | 中兴通讯股份有限公司 | 一种双机备份系统及备份方法 |
US20140137187A1 (en) * | 2012-11-14 | 2014-05-15 | Microsoft Corporation | Scalable and Highly Available Clustering for Large Scale Real-Time Applications |
CN103647668A (zh) * | 2013-12-16 | 2014-03-19 | 上海证券交易所 | 一种高可用集群内主机群体决策系统及切换方法 |
US10095547B1 (en) * | 2015-03-13 | 2018-10-09 | Twitter, Inc. | Stream processing at scale |
CN105205003A (zh) * | 2015-10-28 | 2015-12-30 | 努比亚技术有限公司 | 一种基于集群化系统的自动化测试方法和装置 |
CN106131122A (zh) * | 2016-06-21 | 2016-11-16 | 浪潮电子信息产业股份有限公司 | 一种部署负载均衡服务的方法及装置 |
CN107147540A (zh) * | 2017-07-19 | 2017-09-08 | 郑州云海信息技术有限公司 | 高可用性系统中的故障处理方法和故障处理集群 |
CN108173971A (zh) * | 2018-02-05 | 2018-06-15 | 江苏物联网研究发展中心 | 一种基于主备切换的MooseFS高可用方法及系统 |
Non-Patent Citations (1)
Title |
---|
朱小厮: "RabbitMQ负载均衡(3)——Keepalived+HAProxy实现高可用的负载均衡", 《CSDN》 * |
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110290012A (zh) * | 2019-07-03 | 2019-09-27 | 浪潮云信息技术有限公司 | RabbitMQ集群故障的检测恢复系统及方法 |
CN110430071A (zh) * | 2019-07-19 | 2019-11-08 | 云南电网有限责任公司信息中心 | 业务节点故障自愈方法、装置、计算机设备及存储介质 |
CN110688284A (zh) * | 2019-09-29 | 2020-01-14 | 武汉易酒批电子商务有限公司 | 一种管理和监控RabbitMq消息队列的方法及系统 |
CN111737079B (zh) * | 2020-05-20 | 2024-04-09 | 山东鲸鲨信息技术有限公司 | 一种集群网络的监控方法和装置 |
CN111737079A (zh) * | 2020-05-20 | 2020-10-02 | 山东鲸鲨信息技术有限公司 | 一种集群网络的监控方法和装置 |
CN112187877A (zh) * | 2020-09-10 | 2021-01-05 | 华云数据控股集团有限公司 | 一种基于分布式集群的节点唤醒方法及受控终端 |
CN112187877B (zh) * | 2020-09-10 | 2022-04-01 | 华云数据控股集团有限公司 | 一种基于分布式集群的节点唤醒方法及受控终端 |
CN112667449A (zh) * | 2020-12-29 | 2021-04-16 | 新华三技术有限公司 | 一种集群管理方法及装置 |
CN113438111A (zh) * | 2021-06-23 | 2021-09-24 | 华云数据控股集团有限公司 | 基于Raft分布式恢复RabbitMQ网络分区的方法及应用 |
CN115037595A (zh) * | 2022-04-29 | 2022-09-09 | 北京华耀科技有限公司 | 网络恢复方法、装置、设备及存储介质 |
CN115037595B (zh) * | 2022-04-29 | 2024-04-23 | 北京华耀科技有限公司 | 网络恢复方法、装置、设备及存储介质 |
CN117395263A (zh) * | 2023-12-12 | 2024-01-12 | 苏州元脑智能科技有限公司 | 一种数据同步方法、装置、设备和存储介质 |
CN117395263B (zh) * | 2023-12-12 | 2024-03-12 | 苏州元脑智能科技有限公司 | 一种数据同步方法、装置、设备和存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN109286529B (zh) | 2021-08-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109286529A (zh) | 一种恢复RabbitMQ网络分区的方法及系统 | |
US7225356B2 (en) | System for managing operational failure occurrences in processing devices | |
CN108173911B (zh) | 一种微服务故障检测处理方法及装置 | |
CN107544839B (zh) | 虚拟机迁移系统、方法及装置 | |
Castelli et al. | Proactive management of software aging | |
CN100498725C (zh) | 用于最小化计算机应用程序中的丢失的方法和系统 | |
CN106789306B (zh) | 通信设备软件故障检测收集恢复方法和系统 | |
CN106856489A (zh) | 一种分布式存储系统的服务节点切换方法和装置 | |
CN109788068B (zh) | 心跳状态信息上报方法、装置和设备及计算机存储介质 | |
US10924326B2 (en) | Method and system for clustered real-time correlation of trace data fragments describing distributed transaction executions | |
US20080288812A1 (en) | Cluster system and an error recovery method thereof | |
CN110333986B (zh) | 一种保障redis集群可用性的方法 | |
CN108710673A (zh) | 实现数据库高可用方法、系统、计算机设备和存储介质 | |
CN110580198B (zh) | OpenStack计算节点自适应切换为控制节点的方法及装置 | |
CN109600264A (zh) | CloudStack云平台 | |
CN105490847B (zh) | 一种私有云存储系统中节点故障实时检测及处理方法 | |
CN110674192A (zh) | 一种Redis高可用VIP漂移方法、终端及存储介质 | |
CN115712521A (zh) | 一种集群节点故障处理方法、系统及介质 | |
CN115328735A (zh) | 一种基于容器化应用管理系统的故障隔离方法和系统 | |
CN109324925A (zh) | 分布式框架的事务处理方法及装置 | |
CN116723077A (zh) | 一种分布式it自动化运维系统 | |
US20060248531A1 (en) | Information processing device, information processing method and computer-readable medium having information processing program | |
US20190075036A1 (en) | Protecting virtual computing instances from network failures | |
Stack et al. | Self-healing in a decentralised cloud management system | |
Kitamura et al. | Development of a Server Management System Incorporating a Peer-to-Peer Method for Constructing a High-availability Server System |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |