CN107896172B - 监听故障处理方法及装置、存储介质和电子设备 - Google Patents

Abstract

本发明公开了一种监听故障处理方法及装置、存储介质和电子设备，涉及数据通信技术领域。该监听故障处理方法应用于包括消息队列和消息消费端的***，该监听故障处理方法包括：在消息消费端将消息***与消息处理应用解耦；对消息队列进行监测，如果监测出消息队列中存在异常消息队列，则通过预定通道将异常消息队列通知给消息消费端的监听管理器；监听管理器确定与异常消息队列对应的消息***作为目标***；对目标***进行检测以便在检测出目标***故障的情况下重启目标***。本发明可以解决由于***故障而导致消息队列异常的问题，并且通过将监视器与消息处理应用解耦，可以实现高内聚低耦合的设计要求。

Description

监听故障处理方法及装置、存储介质和电子设备

技术领域

本发明涉及数据通信技术领域，具体而言，涉及一种监听故障处理方法、监听故障处理装置、存储介质和电子设备。

背景技术

随着社会信息化的发展，各业务***之间的数据交互越来越频繁。目前，在各业务***之间往往采用RabbitMQ(一种数据通信方法)来实现数据交互。具体的，首先，消息生产端(Producer)可以将消息发送至消息交换机(Exchange)；随后，消息交换机可以将消息分发给各个与消息交换机绑定的队列(Queue)；另外，消息消费端(Consumer)可以通过***(Monitor)对队列进行监听，并且在队列中的消息被消息消费端监听到并处理完之后，消息消费端可以反馈回叫(Callback)至队列；接下来，队列可以将当前消息清除。由此，当前数据交互处理结束。

然而，一方面，目前存在由于***宕机等原因导致队列中消息长度堆积过高的问题；另一方面，针对消息消费端，***与具体处理消息的的消息处理应用的耦合度较高，在对***或消息处理应用进行代码维护或在项目迭代时，开发人员修改某一处代码可能导致整个***的错误，这不满足高内聚低耦合的设计要求。

鉴于此，需要一种监听故障处理方法、监听故障处理装置、存储介质和电子设备。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本发明的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本发明的目的在于提供一种监听故障处理方法、监听故障处理装置、存储介质和电子设备，进而至少在一定程度上克服由于相关技术的限制和缺陷而导致的一个或者多个问题。

根据本发明的一个方面，提供一种监听故障处理方法，应用于包括消息队列和消息消费端的***，监听故障处理方法包括：

在消息消费端将消息***与消息处理应用解耦；

对消息队列进行监测，如果监测出消息队列中存在异常消息队列，则通过预定通道将异常消息队列通知给消息消费端的监听管理器；

监听管理器确定与异常消息队列对应的消息***作为目标***；

对目标***进行检测以便在检测出目标***故障的情况下重启目标***。

可选地，将消息***与消息处理应用解耦包括：

对消息处理应用进行注册；

获取来自消息处理应用的消息传输条件；

根据消息传输条件将消息经由消息***发送至对应的消息处理应用。

可选地，监听故障处理方法还包括：

采用RESTful架构实现消息***与消息处理应用之间的数据传输。

可选地，通过预定通道将异常消息队列通知给消息消费端的监听管理器包括：

通过HTTP协议或RESTful接口将异常消息队列通知给消息消费端的监听管理器。

可选地，异常消息队列为队列长度异常的消息队列；

其中，对消息队列进行监测包括：

判断消息队列的长度是否异常。

可选地，监听管理器确定与异常消息队列对应的消息***作为目标***包括：

监听管理器根据消息***与消息队列之间的对应关系表确定与异常消息队列对应的消息***作为目标***。

可选地，监听故障处理方法还包括：

在检测出目标***故障的情况下，发送报警信号。

根据本发明的一个方面，提供一种监听故障处理***，包括消息队列和消息消费端，监听故障处理***还包括：

解耦模块，用于在消息消费端将消息***与消息处理应用解耦；

队列监测模块，用于对消息队列进行监测，并在监测出消息队列中存在异常消息队列时，通过预定通道将异常消息队列通知给消息消费端的监听管理器；

监听管理器，用于确定与异常消息队列对应的消息***作为目标***，对目标***进行检测以便在检测出目标***故障的情况下重启目标***。

可选地，解耦模块包括：

处理应用注册单元，用于对消息处理应用进行注册；

传输条件获取单元，用于获取来自消息处理应用的消息传输条件；

消息发送单元，用于根据消息传输条件将消息经由消息***发送至对应的消息处理应用。

可选地，监听故障处理装置还包括：

数据传输模块，用于采用RESTful架构实现消息***与消息处理应用之间的数据传输。

可选地，队列监测模块包括：

异常队列通知单元，用于在监测出消息队列中存在异常消息队列时，通过HTTP协议或RESTful接口将异常消息队列通知给消息消费端的监听管理器。

可选地，异常消息队列为队列长度异常的消息队列；

其中，队列监测模块还包括：

长度异常判断单元，用于判断消息队列的长度是否异常。

可选地，监听管理器包括：

监听单元，用于监听管理器根据消息***与消息队列之间的对应关系表确定与异常消息队列对应的消息***作为目标***。

可选地，监听管理器还包括：

报警信号发送单元，用于在检测出目标***故障的情况下，发送报警信号。

根据本发明的一个方面，提供一种存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述任意一项的监听故障处理方法。

根据本发明的一个方面，提供一种电子设备，包括：

处理器；以及

存储器，用于存储处理器的可执行指令；

其中，处理器配置为经由执行可执行指令来执行上述任意一项的监听故障处理方法。

在本发明的一些实施例所提供的技术方案中，通过将消息***与消息处理应用解耦，监测异常消息队列，并确定异常消息队列对应的***作为目标***，检测目标***并在目标***故障时重启目标***，一方面，通过自动重启***，可以解决***故障导致消息队列异常的问题而无需人工参与；另一方面，将消息***与消息处理应用解耦，可以避免在进行代码维护或项目迭代时，由于修改某一处代码导致整个***错误的问题，实现了高内聚低耦合的设计要求。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1示意性示出了现有技术中一些方案的基于RabbitMQ模式的数据通信的方框图；

图2示意性示出了根据本发明的示例性实施方式的监听故障处理方法的流程图；

图3示意性示出了根据本发明的示例性实施方式的将消息***与消息处理应用解耦后的数据通信的方框图；

图4示意性示出了采用本发明的示例性实施方式的监听故障处理方法的数据通信的方框图；

图5示意性示出了根据本发明的示例性实施方式的监听故障处理***的方框图；

图6示意性示出了根据本发明的示例性实施方式的解耦模块的方框图；

图7示意性示出了根据本发明的示例性实施方式的监听故障处理***的另一方框图；

图8示意性示出了根据本发明的示例性实施方式的队列监测模块的方框图；

图9示意性示出了根据本发明的示例性实施方式的队列监测模块的另一方框图；

图10示意性示出了根据本发明的示例性实施方式的监听管理器的方框图；

图11示意性示出了根据本发明的示例性实施方式的监听管理器的另一方框图；

图12示出了根据本发明的示例性实施方式的存储介质的示意图；以及

图13示意性示出了根据本发明的示例性实施方式的电子设备的方框图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本发明的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本发明的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。

此外，附图仅为本发明的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的步骤。例如，有的步骤还可以分解，而有的步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

图1示意性示出了现有技术中一些方案的基于RabbitMQ模式的数据通信的方框图。数据通信的过程可以为：首先，消息生产端11可以将生产出的消息数据发送至消息队列服务器12中的消息交换机121；接下来，消息交换机121可以将消息数据发送至与其绑定的消息队列122、消息队列123、消息队列124或消息队列125；以消息数据发送至消息队列122为例，与消息队列122对应的消息消费端13可以通过其消息***131监听消息队列122，当消息数据发送至消息队列122时，消息***131可以监听到并获取该消息数据，并将该消息数据发送至消息消费端13内的消息处理应用(未示出)以便消息处理应用对该数据进行处理。由此，完成了基于RabbitMQ模式的数据通信过程。另外，包含有消息***141的消息消费端14可以与消息队列123对应，包含有消息***151的消息消费端15可以与消息队列124对应，以及包含消息***161的消息消费端16可以与消息队列125对应，它们具体的数据通信方式可以与消息队列122对应的通信方式相同，在此不再赘述。

然而，这样的数据通信方式的缺点可能包括：一方面，如果一消息***宕机，则可能出现对应的消息队列数据堆积的问题，而开发人员或运维人员不能及时发现；另一方面，针对消息消费端，***与消息处理应用的耦合度较高，在对***或消息处理应用进行代码维护或在项目迭代时，开发人员修改某一处代码可能导致整个***的错误，这不满足高内聚低耦合的设计要求。

鉴于此，本发明提供了一种监听故障处理方法。

图2示意性示出了本发明的示例性实施方式的监听故障处理方法的流程图。该监听故障处理方法可以应用于包括消息队列和消息消费端的***，参考图2，本发明的监听故障处理方法可以包括以下步骤：

S20.在所述消息消费端将消息***与消息处理应用解耦。

在本发明的示例性实施方式中，消息消费端可以包括消息***和消息处理应用。其中，消息***可以用于监听与该消息消费端对应的消息队列，而消息处理应用可以是具体处理消息数据的应用，可以用于对数据进行加工、整合、展示等，本发明对消息处理应用的具体功能不做特殊限定。

根据本发明的一些实施例，具体解耦的方法可以例如包括：首先，可以对消息处理应用进行注册；接下来，用户可以在其客户端配置消息传输条件，具体的，用户可以通过消息处理应用对应的用户操作界面配置消息传输条件；随后，服务器可以根据消息传输条件将消息经由消息***发送至对应的消息处理应用。在上述消息传输过程中，可以采用RESTful架构实现消息***与消息处理应用之间的数据传输，具体的，消息传输条件可以被转化为与各模块兼容的RESTful数据，并且可以提供RESTful服务接口进行相应的传输服务。另外，可以基于RESTful的各类标记语言(例如，URI)进行数据分块整理，根据历史记录将数据进行分类，由此，不仅可以获得最大化的数据存储，也为筛选时提供更精确的导向。

基于RESTful架构，可以实现无状态的面向资源的松耦合结构，无需考虑当前消息传输的状态，满足了消息***与消息处理应用的高内聚低耦合的设计目标。

图3示意性示出了根据本发明的示例性实施方式的将消息***与消息处理应用解耦后的数据通信的方框图。首先，消息生产端31可以将其生产的消息发送至消息队列服务器32中的消息交换机321，另外，虽然图中未示出，然而应当理解的是，消息队列服务器32还可以包括其他消息交换机，并且本发明对消息交换机的数量不做特殊限定；随后，消息交换机321可以将消息发送至消息队列322、消息队列323、消息队列324或消息队列325，另外，类似地，消息队列服务器32中还可以包含其他消息队列和/或与消息交换机321对应的其他消息队列；接下来，以消息发送至消息队列322为例，消息消费端33中的消息***331监测到消息队列322接收有消息后，可以获取该消息。此外，一方面，消息消费端33中的消息***331可以将消息发送至与其解耦的消息处理应用332，以便消息处理应用332对该消息进行处理，此处解耦的优势在于，若修改消息***331的代码，则不会直接影响到消息处理应用332；另一方面，虽然图中未示出，消息消费端33中还可以包含其他与消息***331对应的消息处理应用。类似地，包含有消息***341和与其解耦的消息处理应用342的消息消费端34可以与消息队列323对应，包含有消息***351和与其解耦的消息处理应用352的消息消费端35可以与消息队列324对应，以及包含消息***361和与其解耦的消息处理应用362的消息消费端36可以与消息队列325对应，它们具体的数据通信方式与消息队列322对应的通信方式相同，在此不再赘述。

此外，本发明可以采用其他架构实现消息***与消息消费端的解耦，例如，可以采用轻量级开源架构Spring来实现解耦等。应当理解的是，对消息消费端中消息***与消息处理应用进行解耦的方案均属于本发明的构思。

通过将消息***与消息处理应用解耦，可以避免在进行代码维护或项目迭代时，由于修改某一处代码导致整个***错误的问题，实现了高内聚低耦合的设计要求。

S22.对消息队列进行监测，如果监测出消息队列中存在异常消息队列，则通过预定通道将异常消息队列通知给消息消费端的监听管理器。

在本发明的示例性实施方式中，可以在消息队列服务器中配置队列监测模块。首先，队列监测模块可以对各消息队列进行监测，具体的，队列监测模块监测的对象可以包括但不限于消息队列的长度，在这种情况下，对消息队列进行监测可以包括判断消息队列的长度是否异常；接下来，可以在消息消费端配置用于检测消息***的监听管理器。当队列监测模块监测出消息队列中存在异常消息队列时，可以将该异常消息队列通知给消息消费端的监听管理器。

例如，预先定义的消息队列的长度为1M，当队列监测模块监测出消息队列A的长度大于1M时，可以将消息队列A确定为异常消息队列并将消息队列A通知给监听管理器。

根据本发明的一些实施例，队列监测模块可以通过预定通道将异常消息队列通知给监听管理器。具体的，预定通道可以是由HTTP协议搭建的传输通道，然而，预定通道还可以是采用RESTful接口进行通信的传输通道，然而，不限于此，本发明还可以采用其他通信方式实现队列监测模块与监听管理器之间的信息传输，本示例性实施方式中对此不做特殊限定。

S24.监听管理器确定与异常消息队列对应的消息***作为目标***。

在本发明的示例性实施方式中，队列监测模块将异常消息队列通知给监听管理器后，监听管理器可以确定与该异常消息队列对应的消息***，并可以将该消息***作为目标***。

根据本发明的一些实施例，消息***可以对应一个或多个消息队列。监听管理器可以基于配置的消息***与消息队列的对应关系确定出异常消息队列对应的消息***。例如，服务器可以存储有消息***与消息队列之间的对应关系表，可以通过查表的方式确定出异常消息队列对应的消息***。

S26.对目标***进行检测以便在检测出目标***故障的情况下重启所述目标***。

在确定出目标***后，可以对目标***的工作状态进行检测。具体的，如果检测出目标***故障，则重启目标***。其中，造成目标***故障的原因可能包含多方面，例如，软件故障、数据损坏、安全漏洞等。而这些故障可能会导致目标***宕机，进而导致消息队列长度异常。也就是说，目标***故障可能是消息队列出现异常的原因。

另外，在监听管理器在检测出目标***时，也就是说，在监听管理器确定出与异常消息队列对应的消息***时，可以发送报警信号。例如，可以以短信或邮件的形式向开发人员或运维人员发送报警信息以便开发人员或运维人员获知异常消息队列的情况。

下面将以图4所示数据通信为例对本发明的监听故障处理方法进行说明。

一方面，消息生产端41可以将其生产的消息发送给消息队列服务器42中的消息交换机421，消息交换机421可以将接收到的消息数据发送至消息队列422、消息队列423、消息队列424、消息队列425、消息队列426或消息队列427。另外，队列检测模块4800可以实时监测消息队列422至427中是否存在长度异常的消息队列；另一方面，可以将消息消费端43中的消息***431与消息处理应用432和消息处理应用433解耦，另外，可以将消息消费端44中的消息***441与消息处理应用442和消息处理应用443解耦，可以将消息消费端45中的消息***451与消息处理应用452和消息处理应用453解耦。

首先，以消息队列422长度异常为例，当队列监测模块4800监测出消息队列422异常时，可以通过RESTful接口4700将消息队列422通知给监听管理器4900；接下来，监听管理器4900可以确定出与消息队列422对应的消息***为消息***431，并对消息***431是否故障进行检测。如果检测出消息***431故障，则重启消息***431。

从此过程可以看出，运用本发明的监听故障处理方法，整个过程无需人工参与，仅在发现消息***故障时可以向开发人员或运维人员发送报警信息，而发送报警信息仅为告知***问题，并非需要人工对故障进行修复。本发明可以实现消息队列异常的自动修复过程，由此，缩短了人工参与而耽误的时间。

在本发明的示例性实施方式的监听故障处理方法中，通过将消息***与消息处理应用解耦，监测异常消息队列，并确定异常消息队列对应的***作为目标***，检测目标***并在目标***故障时重启目标***，一方面，通过自动重启***，可以解决***故障导致消息队列异常的问题而无需人工参与；另一方面，将消息***与消息处理应用解耦，可以避免在进行代码维护或项目迭代时，由于修改某一处代码导致整个***错误的问题，实现了高内聚低耦合的设计要求。

应当注意，尽管在附图中以特定顺序描述了本发明中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

进一步的，本示例实施方式中还提供了一种监听故障处理***。

图5示意性示出了本发明的示例性实施方式的监听故障处理***的方框图。监听故障处理***可以包括消息队列和消息消费端。参考图5，根据本发明的示例性实施方式的监听故障处理***5可以包括解耦模块51、队列监测模块53和监听管理器55，其中：

解耦模块51，可以用于在所述消息消费端将消息***与消息处理应用解耦；

队列监测模块53，可以用于对所述消息队列进行监测，并在监测出所述消息队列中存在异常消息队列时，通过预定通道将所述异常消息队列通知给所述消息消费端的监听管理器；

监听管理器55，可以用于确定与所述异常消息队列对应的消息***作为目标***，对所述目标***进行检测以便在检测出所述目标***故障的情况下重启所述目标***。

在本发明的示例性实施方式的监听故障处理***中，一方面，通过自动重启***，可以解决***故障导致消息队列异常的问题而无需人工参与；另一方面，将消息***与消息处理应用解耦，可以避免在进行代码维护或项目迭代时，由于修改某一处代码导致整个***错误的问题，实现了高内聚低耦合的设计要求。

根据本发明的示例性实施例，参考图6，解耦模块51可以包括处理应用注册单元601、传输条件获取单元603和消息发送单元605，其中：

处理应用注册单元601，可以用于对消息处理应用进行注册；

传输条件获取单元603，可以用于获取来自消息处理应用的消息传输条件；

消息发送单元605，可以用于根据消息传输条件将消息经由消息***发送至对应的消息处理应用。

本示例性实施例提供了一种实现消息***与消息处理应用解耦的方案。

根据本发明的示例性实施例，参考图7，监听故障处理***7相对于监听故障处理***5，除包括解耦模块51、队列监测模块53和监听管理器55外，还可以包括数据传输模块71，其中：

数据传输模块71，可以用于采用RESTful架构实现消息***与消息处理应用之间的数据传输。

通过RESTful架构，可以实现无状态的资源松耦合，满足了消息***与消息处理应用的高内聚低耦合的设计目标。

根据本发明的示例性实施例，参考图8，队列监测模块53可以包括异常队列通知单元801，其中：

异常队列通知单元801，可以用于在监测出消息队列中存在异常消息队列时，通过HTTP协议或RESTful接口将异常消息队列通知给消息消费端的监听管理器。

通过HTTP协议或RESTful接口配置队列监测模块与监听管理器之间的信息通道，实现了基于队列监测模块的监测结果确定消息***故障的过程。

根据本发明的示例性实施例，异常消息队列为队列长度异常的消息队列。参考图9，队列监测模块91相对于队列监测模块53，除包括异常队列通知单元801外，还可以包括长度异常判断单元901，其中：

长度异常判断单元901，可以用于判断消息队列的长度是否异常。

根据本发明的示例性实施例，参考图10，监听管理器55可以包括监听单元1001，其中：

监听单元1001，可以用于监听管理器根据消息***与消息队列之间的对应关系表确定与异常消息队列对应的消息***作为目标***。

通过查表的方式确定出目标***，过程简便，效率较高。

根据本发明的示例性实施例，参考图11，监听管理器111可以包括报警信号发送单元1101，其中：

报警信号发送单元1101，可以用于在检测出所述目标***故障的情况下，发送报警信号。

通过发送报警信息，使得开发人员或运维人员可以获知目标***故障的情况。

由于本发明实施方式的程序运行性能分析装置的各个功能模块与上述方法发明实施方式中相同，因此在此不再赘述。

在本发明的示例性实施例中，还提供了一种计算机可读存储介质，其上存储有能够实现本说明书上述方法的程序产品。在一些可能的实施方式中，本发明的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在终端设备上运行时，所述程序代码用于使所述终端设备执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施方式的步骤。

参考图12所示，描述了根据本发明的实施方式的用于实现上述方法的程序产品1200，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行***、装置或者器件使用或者与其结合使用。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的***、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

在本发明的示例性实施例中，还提供了一种能够实现上述方法的电子设备。

所属技术领域的技术人员能够理解，本发明的各个方面可以实现为***、方法或程序产品。因此，本发明的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“***”。

下面参照图13来描述根据本发明的这种实施方式的电子设备1300。图13显示的电子设备1300仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图13所示，电子设备1300以通用计算设备的形式表现。电子设备1300的组件可以包括但不限于：上述至少一个处理单元1310、上述至少一个存储单元1320、连接不同***组件(包括存储单元1320和处理单元1310)的总线1330、显示单元1340。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元1310执行，使得所述处理单元1310执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施方式的步骤。例如，所述处理单元1310可以执行如图2中所示的步骤S20：在消息消费端将消息***与消息处理应用解耦；步骤S22：对消息队列进行监测，如果监测出消息队列中存在异常消息队列，则通过预定通道将异常消息队列通知给消息消费端的监听管理器；步骤S24：监听管理器确定与异常消息队列对应的消息***作为目标***；步骤S26：对目标***进行检测以便在检测出目标***故障的情况下重启目标***。

存储单元1320可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)13201和/或高速缓存存储单元13202，还可以进一步包括只读存储单元(ROM)13203。

存储单元1320还可以包括具有一组(至少一个)程序模块13205的程序/实用工具13204，这样的程序模块13205包括但不限于：操作***、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线1330可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、***总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

电子设备1300也可以与一个或多个外部设备1500(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备1300交互的设备通信，和/或与使得该电子设备1300能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口1350进行。并且，电子设备1300还可以通过网络适配器1360与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器1360通过总线1330与电子设备1300的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备1300使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID***、磁带驱动器以及数据备份存储***等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本发明实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本发明实施方式的方法。

此外，上述附图仅是根据本发明示例性实施例的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本发明的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其他实施例。本申请旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由权利要求指出。

应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限。

Claims (9)

1.一种监听故障处理方法，应用于包括消息队列和消息消费端的***，其特征在于，所述监听故障处理方法包括：

在所述消息消费端，采用RESTful架构实现消息***与消息处理应用之间的数据传输，以将消息***与消息处理应用解耦；其中，所述消息***对应一个或多个消息队列；

对所述消息队列进行监测，如果监测出所述消息队列中存在异常消息队列，则通过预定通道将所述异常消息队列通知给所述消息消费端的监听管理器；

所述监听管理器确定与所述异常消息队列对应的消息***作为目标***；

对所述目标***进行检测以便在检测出所述目标***故障的情况下重启所述目标***。

2.根据权利要求1所述的监听故障处理方法，其特征在于，将消息***与消息处理应用解耦包括：

对消息处理应用进行注册；

获取来自所述消息处理应用的消息传输条件；

根据消息传输条件将消息经由消息***发送至对应的消息处理应用。

3.根据权利要求1所述的监听故障处理方法，其特征在于，通过预定通道将所述异常消息队列通知给所述消息消费端的监听管理器包括：

通过HTTP协议或RESTful接口将所述异常消息队列通知给所述消息消费端的监听管理器。

4.根据权利要求1或3所述的监听故障处理方法，其特征在于，所述异常消息队列为队列长度异常的消息队列；

其中，对所述消息队列进行监测包括：

判断所述消息队列的长度是否异常。

5.根据权利要求1所述的监听故障处理方法，其特征在于，所述监听管理器确定与所述异常消息队列对应的消息***作为目标***包括：

所述监听管理器根据消息***与消息队列之间的对应关系表确定与所述异常消息队列对应的消息***作为目标***。

6.根据权利要求1所述的监听故障处理方法，其特征在于，所述监听故障处理方法还包括：

在检测出所述目标***故障的情况下，发送报警信号。

7.一种监听故障处理***，包括消息队列和消息消费端，其特征在于，所述监听故障处理***还包括：

解耦模块，用于在所述消息消费端，采用RESTful架构实现消息***与消息处理应用之间的数据传输，以将消息***与消息处理应用解耦；其中，所述消息***对应一个或多个消息队列；

队列监测模块，用于对所述消息队列进行监测，并在监测出所述消息队列中存在异常消息队列时，通过预定通道将所述异常消息队列通知给所述消息消费端的监听管理器；

监听管理器，用于确定与所述异常消息队列对应的消息***作为目标***，对所述目标***进行检测以便在检测出所述目标***故障的情况下重启所述目标***。

8.一种存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至6中任一项所述的监听故障处理方法。

9.一种电子设备，其特征在于，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行权利要求1至6中任一项所述的监听故障处理方法。

Images