CN103019866B - 基于消息队列的分布式方法和系统 - Google Patents

Abstract

本发明提供一种基于消息队列的分布式方法和系统。该基于消息队列的分布式方法包括：由第一应用向队列管理器发送消息；确定所述消息是否成功发送；如果确定没有成功发送所述消息，则所述消息被放入第一异常处理模块进行处理；如果确定已经成功发送所述消息，则由所述队列管理器对所接收到的消息进行处理；将所述消息发送到第二应用；以及由所述第二应用对所接收到的消息进行处理。

Description

基于消息队列的分布式方法和系统

技术领域

本发明涉及一种基于消息中间件的分布式方法和系统，更具体地，涉及一种基于消息队列的分布式方法和系统。

背景技术

在大规模分布式系统中，消息中间件（message-oriented middleware，MOM）被广泛使用。消息中间件是一种由消息传输机制或消息队列模式组成的中间件技术。消息中间件利用高效可靠的消息传输机制进行平台无关的数据交流，并且基于数据通信来进行分布式系统的集成。

通常，消息中间件并不要求系统具备一个可靠的底部传输层，而是通过以消息的形式收发应用程序数据来连接运行于不同系统上的应用程序。信息可以同步传送，也支持异步传送。在异步方式下，应用程序并不需要消息即时即刻传送到对方，只是由MOM确保把信息以消息的方式传送到适当的目的地，并且只传一次。

消息队列（MQ）（Message Queuing）是一种应用程序对应用程序的通信方法。应用程序通过写和检索出入队列的针对应用程序的数据（消息）来通信，而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。MQ具有异步通信、消息路由可靠、安全性、协议无关性等优点。

然而，在大规模分布式系统，如果使用通常的MQ解决方案，存在诸多缺点，包括：消费消息阻塞；MQ单点；发送消息阻塞；消息不匹配；MQ/消息无监控；消息顺序不一致；死信队列无法处理。

因此，需要一种用于增强MQ方案的基于消息队列的分布式方法和系统。

发明内容

根据本发明的一方面，提供了一种基于消息队列的分布式方法，包括：由第一应用向队列管理器发送消息；确定所述消息是否成功发送；如果确定没有成功发送所述消息，则所述消息被放入第一异常处理模块进行处理；如果确定已经成功发送所述消息，则由所述队列管理器对所接收到的消息进行处理；将所述消息发送到第二应用；以及由所述第二应用对所接收到的消息进行处理。

根据本发明的一个实施例，所述由所述队列管理器对所接收到的消息进行处理的步骤进一步包括：确定所述消息是否是死信；以及如果确定所述消息是死信，则所述消息被放入死信处理模块以进行处理。

根据本发明的一个实施例，所述由第二应用对所接收到的消息进行处理的步骤进一步包括：确定所述第二应用是否已经成功处理了所述消息；以及如果确定没有成功处理所述消息，则所述消息被放入第二异常处理模块进行处理。

根据本发明的一个实施例，所述消息被放入第一异常处理模块进行处理的步骤进一步包括：确定所述第一异常处理模块是否已经成功处理了所述消息；如果确定没有成功处理所述消息，则向监控模块报告该情况；以及如果确定已经成功处理了所述消息，则将所述消息发送到所述队列管理器。

根据本发明的一个实施例，所述消息被放入死信处理模块以进行处理的步骤进一步包括：确定所述死信处理模块是否已经成功处理所述消息；以及如果确定没有成功处理所述消息，则向监控模块报告该情况。

根据本发明的一个实施例，所述消息被放入第二异常处理模块进行处理的步骤进一步包括：确定所述第二异常处理模块是否已经成功处理了所述消息；以及如果确定没有成功处理所述消息，则向监控模块报告该情况。

根据本发明的一个实施例，在所述第一应用向所述队列管理器发送所述消息之前，注册模块可以对所述消息进行匹配检查，并且仅当所述消息匹配时，才继续后续操作。

根据本发明的一个实施例，所述队列管理器是队列管理器集群。

根据本发明的一个实施例，所述由队列管理器对所接收到的消息进行处理进一步包括：确定所述队列管理器集群中的一个队列管理器未能正常工作；隔离所述一个队列管理器，使得不会再有新的消息路由到所述一个队列管理器；以及由其余的队列管理器接管所述一个队列管理器的工作。

根据本发明的一个实施例，所述确定所述第一异常处理模块是否已经成功处理了所述消息的步骤在预定时间间隔之后执行。

根据本发明的一个实施例，所述确定所述死信处理模块是否已经成功处理所述消息的步骤在预定时间间隔之后执行。

根据本发明的一个实施例，所述确定所述第二异常处理模块是否已经成功处理了所述消息的步骤在预定时间间隔之后执行。

根据本发明的一方面，提供了一种基于消息队列的分布式系统，包括：第一应用，所述第一应用被配置成向队列管理器发送消息；第一异常处理模块，所述第一异常处理模块连接到所述第一应用，并且被配置成对所述第一应用没有成功发送的消息进行处理；队列管理器，所述队列管理器与所述第一应用和所述第一异常处理模块相连，并且被配置成对所接收到的消息进行处理并且将所述消息发送到第二应用；以及第二应用，所述第二应用连接到所述队列管理器，并且被配置成对所接收到的消息进行处理。

根据本发明的一个实施例，所述系统进一步包括监控模块，所述监控模块被配置成对所述第一应用、所述队列管理器和所述第二应用进行监控。

根据本发明的一个实施例，所述队列管理器进一步包括死信处理模块，所述死信处理模块被配置成对死信进行处理。

根据本发明的一个实施例，所述第二应用进一步包括第二异常处理模块，所述第二异常处理模块被配置成对所述第二应用没有成功处理的消息进行处理。

根据本发明的一个实施例，所述第一异常处理模块进一步被配置成：确定是否已经成功处理了所述消息；如果确定没有成功处理所述消息，则向所述监控模块报告该情况；以及如果确定已经成功处理了所述消息，则将所述消息发送到所述队列管理器。

根据本发明的一个实施例，所述死信处理模块进一步被配置成：确定所述死信处理模块是否已经成功处理所述消息；以及如果确定没有成功处理所述消息，则向所述监控模块报告该情况。

根据本发明的一个实施例，所述第二异常处理模块进一步被配置成：确定是否已经成功处理了所述消息；以及如果确定没有成功处理所述消息，则向所述监控模块报告该情况。

根据本发明的一个实施例，所述系统进一步包括注册模块，所述注册模块被配置成对所述消息进行匹配检查，并且仅当所述消息匹配时，才继续后续操作。

根据本发明的一个实施例，所述队列管理器是队列管理器集群。

根据本发明的一个实施例，所述队列管理器集群进一步被配置成：确定所述队列管理器集群中的一个队列管理器未能正常工作；隔离所述一个队列管理器，使得不会再有新的消息路由到所述一个队列管理器；以及由其余的队列管理器接管所述一个队列管理器的工作。

根据本发明的一个实施例，所述第一异常处理模块进一步被配置成：在预定时间间隔之后，确定是否已经成功处理了所述消息。

根据本发明的一个实施例，所述死信处理模块进一步被配置成：在预定时间间隔之后，确定是否已经成功处理所述消息。

根据本发明的一个实施例，所述第二异常处理模块进一步被配置成：在预定时间间隔之后，确定是否已经成功处理了所述消息。

根据本发明的基于消息队列的分布式方法和系统针对大规模分布式系统，对MQ解决方案进行了有效改进，解决了存在的诸多缺点，包括消费消息阻塞；MQ单点；发送消息阻塞；消息不匹配；MQ/消息无监控；消息顺序不一致；死信队列无法处理等问题，从而实现了具有高效实时、高扩展性、系统松耦合的分布式方法和系统。

附图说明

附图图示了本发明的实施例，并与说明书一起用于解释本发明的原理。在附图中：

图1图示了根据本发明的实施例的用于基于消息队列的分布式系统的示意框图。

图2图示了根据本发明的实施例的用于基于消息队列的分布式方法的流程图。

图3图示了根据本发明的实施例的在队列管理器集群中消息的一个处理流程图。

具体实施方式

下面结合说明书附图详细描述本发明的实施例。

在消息中间件中，不同的应用之间传递交换的信息统称为消息，它是数据交换的基本单位。消息可以是各种各样的媒体，诸如文本、声音、图像等。每一个消息都可以拥有一个优先级属性，表示与其他消息的相对重要性。消息可以包含发送和接收者的标识、时间戳、到期时间等信息。无法传递或已过期的消息被称为死信。

队列可以看作一个容器，用于存放消息。队列可以分为很多种类型，例如包括：本地队列、远程队列等。本地队列按功能又被分为初始化队列、传输队列、目标队列、死信队列等。初始化队列用作消息触发。传输队列用于暂时存放待传送的消息，在条件许可的情况下将通过管道将消息传送到其他队列管理器。目标队列是消息的目的地，可以长期存放消息。死信队列是普通的本地队列。如果消息不能送达目标队列，也不能再路由出去，将自动将其放入死信队列保存。

集群通常指的是由多机系统共同负担计算机任务，如果其中一个节点出现故障，则剩余的部分会接管其工作。从本质上看，集群要解决的是系统容错和负载均衡这两个问题。

图1图示了根据本发明的实施例的用于基于消息队列的分布式系统100的示意框图。

如图1所示，根据本发明的用于管理消息队列的系统100包括应用102、队列管理器集群103、应用104、注册模块106、监控模块108以及异常处理模块110和112。

应用102是发送方，用于将消息发送到队列管理器集群103，并且可以例如是业务系统。应用104是接收方，用于从队列管理器集群接收消息并且将其发送到服务器，并且可以例如是报表系统。例如，业务系统在必要的处理环节，可以通过消息队列推送消息给报表系统，并且在报表系统侦听到消息后，对其进行相关处理。替代地，应用102可以是接收方，而应用104可以是发送方。应用102和104可以分布于同一台机器上，也可以分布于相连的网络空间中的任一位置。而且，可以存在不止一个应用102和104。

队列管理器集群103用于从应用102接收消息、处理本地消息并且将消息发送到应用104。队列管理器集群103可以包括一个或多个队列管理器。为了简单说明，在此仅示出了两个队列管理器114和116。队列管理器114和116用于管理所有的消息队列，包括消息的出队、入队以及分发到其他队列管理器。队列管理器114和116可以是本地队列管理器，也可以是远程队列管理器，而且它们也可以是不同操作系统上的队列管理器。

根据本发明的实施例，队列管理器114包括消息处理模块118和死信处理模块120，而队列管理器116包括消息处理模块122和死信处理模块124。

解决发送消息阻塞

在现有技术中，如果消息发送方由于队列管理器或消息接收方等问题而无法成功发送消息，则造成发送消息阻塞，从而消息丢失。

在根据本发明的实施例中，如果应用102不能成功发送消息，则将没有成功处理的消息放入异常处理模块110，该异常处理模块110将对该没有成功处理的消息进行处理，并且在成功处理该消息之后，由异常处理模块110将其发送到队列管理器集群103，由此避免了消息阻塞的问题。异常处理模块110可以包括异常数据库，在这种情况下在异常数据库中利用worker来处理没有成功处理的消息。

此外，也可以对进入异常处理模块110的没有成功处理的消息设定优先级，并根据优先级对这些消息进行处理，使得能够优先处理重要事件，从而使消息传递更有效率。如果异常处理模块110对没有成功处理的消息进行处理的次数或时间达到预定阈值仍然不成功，则通过监控模块108提示进行人工处理，以避免死循环。

解决MQ故障

在现有技术中，由于MQ是单点，所以如果队列管理器出现故障，则业务处理将失败。

在根据本发明的实施例中，将队列管理器实现为队列管理器集群，集群内部的队列管理器之间进行通信时，不需要两两之间建立通信信道，并且集群中的队列管理器之间能够自动进行负载均衡。如图1所示，队列管理器集群103包括多个并行设置的队列管理器。为了简单解释起见，图1中仅示出了两个队列管理器114和116。而且，队列管理器集群103可以水平扩展。

如果队列管理器集群103中的一个队列管理器出现故障或因其他原因而不工作，例如，队列管理器114出现故障，则队列管理器集群103可以自动将其隔离，使得不会再有新的消息路由到队列管理器114，并且由队列管理器116接管队列管理器114的工作，从而避免了业务处理失败。因此，系统100可以在充分利用现有资源、简化系统配置的同时，大大提高了消息传送的可靠性。

解决死信队列无法处理

如已知的，每个队列管理器都具有死信队列，死信队列保存的是未送达的消息。未送达可能是例如由于网络或目的地等问题造成的。虽然死信队列的设置可以一定程度上防止通道关闭或减少影响队列管理器的正常操作，但是如果死信过多，则仍然会对队列管理器甚至整个系统造成不利影响。

根据本发明的实施例，队列管理器118和122分别包括死信处理模块120和124。死信处理模块120、124用于对死信进行处理。死信处理模块120和124的设置使得可以在没有人工介入的情况下自动处理死信队列，从而有效避免了死信的积压并提高了系统效率。

具体地，死信处理模块120和124例如可以基于死信产生的原因、死信的目的地等等因素来进行重发、转发、删除等处理。死信产生的原因例如包括：目标队列已经满了、目标队列不存在、消息不允许被放置在队列中、发送者没有被授权使用目标队列、消息过大、消息含有重复的序列号等等。

例如，对于暂时性错误，死信处理模块120、124可以采取重试的策略，但是死信处理模块120、124应当控制重试的间隔和/或次数，例如可以事先设置预定的时间间隔和/或次数。可选地，可以在每一次重试之间增大间隔时间，从而防止增大系统的负荷。例如，对于由于系统繁忙引起的错误，死信处理模块120、124可以尽可能降低吞吐从而减少恢复的时间。然而，如果死信处理模块120、124在超过预定的时间间隔和/或次数之后仍未成功处理死信，则通过监控模块108将错误报告给管理员，以便人工介入分析原因。

解决消费消息阻塞

在现有技术中，业务涉及完全依赖于队列管理器。也就是，只有数据处理成功之后，才消费消息。如果接收方出现故障，则会造成堵塞，过多堵塞甚至造成消息积压，以致使报表系统无法工作，甚至因为死信队列过大而引发队列管理器故障。

在根据本发明的实施例中，队列管理器114、116仅用作一个通知系统，它们与应用104解耦，也就是说应用104本身直接消费消息。如果应用104本身出现故障或没有成功处理消息，则该消息被放入异常处理模块112，该异常处理模块112将对该消息进行处理，由此避免了消息阻塞的问题。另外，异常处理模块112可以包括异常数据库，在这种情况下在异常数据库中利用worker来处理没有成功处理的消息。

类似地，也可以对进入异常处理模块112的没有成功处理的消息设定优先级，并根据优先级对这些消息进行处理，从而使消息传递更有效率。如果异常处理模块112对没有成功处理的消息进行处理的次数或时间达到预定阈值仍然不成功，则通过监控模块108提示进行人工处理，以避免死循环。

解决消息不匹配

在现有技术中，消息生产者和消费者利用配置文件独立定义消息，缺乏匹配检查。如果消息生产者和消费者的消息不一致，则会造成报表数据不准或者产生大量死信队列。

根据本发明的实施例，作为消息生产者的应用102和作为消息消费者的应用104需要通过注册模块106进行注册，并且在系统100启动时注册模块106进行消息匹配检查，如果出现消息不一致的情况，则系统100不能启动，避免上线出现问题。该消息集中注册机制可以防止出现数据不准或大量死信队列的产生。

解决MQ/消息无监控

在现有技术中，由于没有对队列管理器和/或消息进行监控，因此在出现异常的情况下，不能做到提前预警，也无法知道发送和/或接收数量是否准确。

根据本发明的实施例，系统100包括监控模块108，该监控模块108对应用102、队列管理器集群103、应用104的各项指标进行监控，并根据需要相应地发出警报。例如，监控模块108可以对发送和消费消息数量进行统计监控。例如，如果正常队列超过某个阈值（例如，5000条），则监控模块108就会报警。又例如，如果死信队列有数据，则监控模块108就会报警。

通常，如上所述，对于应用或队列管理器自己能够处理和解决的可恢复的错误是由其相应的异常处理模块110、112或死信处理模块120、124自行处理，例如，连接失败（可以按照一定规则重新连接）、暂时的错误（可以稍后进行重试）。然而，对于在进行人工介入之前不可能由应用程序恢复的错误是由监控模块108通知给管理员，例如，应用错误（例如，使用了不正确的参数）、系统错误（例如，硬件问题、磁盘满或队列损坏等）以及软件问题（例如，其他应用停止工作导致队列满等）。

然而，如果对可恢复的错误处理若干次后，仍然不能成功处理的情况下，则认为这个错误是不可恢复。在这种情况下，通过监控模块108将该情况通知给管理员，同时释放其他相关的资源。例如，如果当前链接失效或中断，则应用或队列管理器可以重新建立连接并尝试重新开始操作，但是如果在重试预定次数和/或预定时间间隔之后，仍未能成功连接，则应用或队列管理器通过监控模块108将该情况通知给管理员，以保证系统正常运行并防止意外的发生。

对本领域技术人员显而易见的是，对于以上描述的发送消息阻塞、MQ故障、死信队列无法处理、消费消息阻塞、消息不匹配以及MQ/消息无监控的问题的解决方案，可以同时应用以上所有的技术方案，也可以选择性地应用以上解决方案中的一个或多个。例如，可以仅应用针对发送消息阻塞的技术方案。替代地，可以应用包括针对发送消息阻塞和MQ/消息无监控的技术方案，等等。

图2图示了根据本发明的实施例的用于基于消息队列的分布式方法的流程图200。

如图2所示，根据本发明的实施例的方法的流程图200，在步骤204中，应用102向队列管理器集群103发送消息。在可选步骤206中，确定该消息是否成功发送。如果在步骤206中确定没有成功发送，则在步骤208中，该消息被放入异常处理模块110进行处理。然后，在可选步骤210中，确定是否已经成功处理了该消息。如果在预定时间间隔之后，仍然没有成功处理该消息，则在步骤212中，向监控模块108报告该情况。如果在步骤210中确定已经成功处理了该消息，则在步骤214中异常处理模块110将该消息发送到队列管理器集群103。

如果在步骤206中确定已经成功发送了消息或者在步骤214中异常处理模块110将成功处理的消息发送到队列管理器集群103，则在步骤216中，队列管理器集群103对所接收到的消息进行处理。然后，在可选步骤218中，确定该消息是否是死信。如果在步骤218中确定该消息是死信，则在步骤220中，该消息被放入死信处理模块120中进行处理。接着，在可选步骤222中，确定该消息是否已经被成功处理。如果在预定时间间隔之后，仍然没有成功处理该消息，则在步骤224中，向监控模块108报告该情况。

如果在步骤218中确定该消息不是死信或者在步骤222中确定已经成功处理了该消息，则队列管理器集群103向应用104发送该消息。在步骤228中，应用104从队列管理器集群103接收消息并对所接收到的消息进行处理。然后，在可选步骤230中，确定是否成功处理了所接收到的消息。如果在步骤230中确定没有成功处理所接收到的消息，则在步骤232中，没有成功处理的消息被放入异常处理模块中进行处理。然后，在可选步骤234中，确定是否已经成功处理了该消息。如果在预定时间间隔之后，仍然没有成功处理该消息，则在步骤236中，向监控模块108报告该情况。如果在步骤230中确定已经成功处理了该消息或者在步骤234中确定已经成功处理了该消息，则该流程图200结束。

应当理解，对于上述流程图200中的可选步骤206、210、218、222、230和234，可以同时应用所有的可选步骤，也可以选择性地应用以上可选步骤中的一个或多个。例如，在可选步骤206、210、218、222、230和234当中，可以仅应用可选步骤206。替代地，可以应用可选步骤206和218，等等。

而且，在根据本发明的一个实施例中，在应用102向队列管理器集群103发送消息之前，注册模块106可以对消息进行匹配检查。仅当消息匹配时，才继续后续操作。

图3图示了根据本发明的实施例的在队列管理器集群中消息的一个处理流程图。在队列管理器是队列管理器集群的情况下，如图3所示，流程图200可以进一步包括以下步骤。在步骤302中，确定队列管理器集群103中的一个队列管理器（例如，队列管理器114）未能正常工作。然后，在步骤304中，隔离该未能正常工作的队列管理器，使得不会再有新的消息路由到该队列管理器。在步骤306中，由其余的队列管理器（例如，队列管理器116）接管未能正常工作的队列管理器的工作。

根据本发明的基于消息队列的分布式方法和系统针对现有MQ解决方案中的诸多问题改进了现有大规模分布式系统MQ解决方案，提高了系统性能、稳定性和安全性。

上述实施例仅是本发明的优选实施例，并不用于限制本发明。对本领域技术人员显而易见的是，在不脱离本发明的精神和范围的情况下，可以对本发明的实施例进行各种修改和改变。因此，本发明意在涵盖落入如权利要求所限定的本发明的范围之内的所有这样的修改或变型。

Claims (23)

1.一种基于消息队列的分布式方法，包括：

由第一应用向队列管理器发送消息；

确定所述消息是否成功发送；

如果确定没有成功发送所述消息，则所述消息被放入第一异常处理模块进行处理，包括：对进入所述第一异常处理模块的没有成功处理的消息设定优先级，并根据优先级对这些消息进行处理；如果所述第一异常处理模块对没有成功处理的消息进行处理的次数或时间达到预定阈值仍然不成功，则提示进行人工处理；

如果确定已经成功发送所述消息，则由所述队列管理器对所接收到的消息进行处理；

将所述消息发送到第二应用；以及

由所述第二应用对所接收到的消息进行处理，

其中所述由所述队列管理器对所接收到的消息进行处理的步骤进一步包括：

确定所述消息是否是死信；以及

如果确定所述消息是死信，则所述消息被放入死信处理模块进行处理，以预定的时间间隔和/或次数重发、转发或删除所述消息。

2.根据权利要求1所述的方法，其中所述由第二应用对所接收到的消息进行处理的步骤进一步包括：

确定所述第二应用是否已经成功处理了所述消息；以及

如果确定没有成功处理所述消息，则所述消息被放入第二异常处理模块进行处理。

3.根据权利要求1所述的方法，其中所述消息被放入第一异常处理模块进行处理的步骤进一步包括：

确定所述第一异常处理模块是否已经成功处理了所述消息；

如果确定没有成功处理所述消息，则向监控模块报告该情况；以及

如果确定已经成功处理了所述消息，则将所述消息发送到所述队列管理器。

4.根据权利要求1所述的方法，其中所述消息被放入死信处理模块以进行处理的步骤进一步包括：

确定所述死信处理模块是否已经成功处理所述消息；以及

如果确定没有成功处理所述消息，则向监控模块报告该情况。

5.根据权利要求2所述的方法，其中所述消息被放入第二异常处理模块进行处理的步骤进一步包括：

确定所述第二异常处理模块是否已经成功处理了所述消息；以及

如果确定没有成功处理所述消息，则向监控模块报告该情况。

6.根据权利要求1所述的方法，其中在所述第一应用向所述队列管理器发送所述消息之前，注册模块可以对所述消息进行匹配检查，并且仅当所述消息匹配时，才继续后续操作。

7.根据权利要求1所述的方法，其中所述队列管理器是队列管理器集群。

8.根据权利要求7所述的方法，其中所述由队列管理器对所接收到的消息进行处理进一步包括：

确定所述队列管理器集群中的一个队列管理器未能正常工作；

隔离所述一个队列管理器，使得不会再有新的消息路由到所述一个队列管理器；以及

由其余的队列管理器接管所述一个队列管理器的工作。

9.根据权利要求3所述的方法，其中所述确定所述第一异常处理模块是否已经成功处理了所述消息的步骤在预定时间间隔之后执行。

10.根据权利要求4所述的方法，其中所述确定所述死信处理模块是否已经成功处理所述消息的步骤在预定时间间隔之后执行。

11.根据权利要求5所述的方法，其中所述确定所述第二异常处理模块是否已经成功处理了所述消息的步骤在预定时间间隔之后执行。

12.一种基于消息队列的分布式系统，包括：

第一应用，所述第一应用被配置成向队列管理器发送消息；

第一异常处理模块，所述第一异常处理模块连接到所述第一应用，并且被配置成对所述第一应用没有成功发送的消息进行处理，包括：对进入所述第一异常处理模块的没有成功处理的消息设定优先级，并根据优先级对这些消息进行处理；如果所述第一异常处理模块对没有成功处理的消息进行处理的次数或时间达到预定阈值仍然不成功，则提示进行人工处理；

队列管理器，所述队列管理器与所述第一应用和所述第一异常处理模块相连，并且被配置成对所接收到的消息进行处理并且将所述消息发送到第二应用；以及

第二应用，所述第二应用连接到所述队列管理器，并且被配置成对所接收到的消息进行处理，

其中所述队列管理器进一步包括死信处理模块，所述死信处理模块被配置成对死信进行处理，以预定的时间间隔和/或次数重发、转发或删除所述消息。

13.根据权利要求12所述的系统，进一步包括监控模块，所述监控模块被配置成对所述第一应用、所述队列管理器和所述第二应用进行监控。

14.根据权利要求13所述的系统，其中所述第二应用进一步包括第二异常处理模块，所述第二异常处理模块被配置成对所述第二应用没有成功处理的消息进行处理。

15.根据权利要求13所述的系统，其中所述第一异常处理模块进一步被配置成：确定是否已经成功处理了所述消息；如果确定没有成功处理所述消息，则向所述监控模块报告该情况；以及如果确定已经成功处理了所述消息，则将所述消息发送到所述队列管理器。

16.根据权利要求13所述的系统，其中所述死信处理模块进一步被配置成：确定所述死信处理模块是否已经成功处理所述消息；以及如果确定没有成功处理所述消息，则向所述监控模块报告该情况。

17.根据权利要求14所述的系统，其中所述第二异常处理模块进一步被配置成：确定是否已经成功处理了所述消息；以及如果确定没有成功处理所述消息，则向所述监控模块报告该情况。

18.根据权利要求12所述的系统，进一步包括注册模块，所述注册模块被配置成对所述消息进行匹配检查，并且仅当所述消息匹配时，才继续后续操作。

19.根据权利要求12所述的系统，其中所述队列管理器是队列管理器集群。

20.根据权利要求19所述的系统，其中所述队列管理器集群进一步被配置成：确定所述队列管理器集群中的一个队列管理器未能正常工作；隔离所述一个队列管理器，使得不会再有新的消息路由到所述一个队列管理器；以及由其余的队列管理器接管所述一个队列管理器的工作。

21.根据权利要求15所述的系统，其中所述第一异常处理模块进一步被配置成：在预定时间间隔之后，确定是否已经成功处理了所述消息。

22.根据权利要求16所述的系统，其中所述死信处理模块进一步被配置成：在预定时间间隔之后，确定是否已经成功处理所述消息。

23.根据权利要求17所述的系统，其中所述第二异常处理模块进一步被配置成：在预定时间间隔之后，确定是否已经成功处理了所述消息。