CN104579905B - 消息传递方法和***及mom服务器、接收端 - Google Patents

Abstract

本申请实施例公开了消息传递方法、***、消息中间件服务器及接收端。所述消息传递方法例如包括：发布者发布消息到消息中间件服务器；消息中间件服务器接收所述发布者发布的消息，并将该接收的消息置于队列中；消息接收器监听所述消息中间件服务器上的队列，并在监听到所述队列上有消息后，将所述队列上的消息取回，并通知消息拆分器；消息拆分器收到所述通知后获取消息关注者列表，并通知关注者列表中的关注者；被通知的关注者将消息发送至该关注者对应的消息处理器。利用本申请各实施例，可以减轻消息中间件服务器的压力。

Description

消息传递方法和***及MOM服务器、接收端

技术领域

本申请涉及数据通信技术领域，特别涉及一种消息传递方法和***及MOM服务器、接收端。

背景技术

在数据通信技术领域中，对象之间往往利用消息进行交互作用和通信。消息通信的基本方式包括一种同步方式。同步方式中，两个通信的对象之间必须要进行同步。这就意味着每个对象的服务必须都是正常运行的。这样，发送对象中的发送程序（一种服务）和接收对象中的接收程序（同样是一种服务）都一直处于运行状态，并且随时做好相互通信的准备。发送程序向接收程序发起一个消息后，发送程序就会堵塞发送对象当前的进程。因此，发送对象不能与其它应用（也称为应用程序）进行任何的通信以及交互，只能等待接收程序的响应。发送对象得到接收程序返回的消息之后，发送对象才会继续向下运行，进行下一步的业务处理。消息通信的基本方式还包括一种异步方式。在异步方式中，两个通信的对象之间可以不用同时在线等待，任何一方只需处理自己的业务。例如发送对象发送消息之后不必仅等待接收方的响应，而是还可以接着处理其他的任务。消息的接收方也不用立即对接收到的消息进行处理。

随着技术的发展，出现了中间件（Middleware）技术。作为异步通信技术的一种，中间件典型的情况是基于分布式处理环境，最突出的特点是其数据通信功能。也可认为中间件是位于平台和应用之间的通用服务，这些服务具有标准的程序接口和协议。

消息中间件（Message Oriented Middleware，MOM，也称为面向消息的中间件）技术，提供了以松散耦合的灵活方式进行消息传递的一种中间件机制。图1示出了一种利用消息中间件技术进行消息传递的原理图。如图1所示，应用程序A与应用程序B通过使用MOM的应用程序编程接口（Application Programming Interface,API）发送消息进行通信。这样，MOM能够实现在不同平台之间的通信，它常被用来屏蔽掉各种平台及协议之间的特性，实现应用程序之间的协同。目前主流的消息中间件产品包括国际商业机器公司（InternationalBusiness Machines Corporation，IBM）的MQSeries，东亚银行（Bank of East Asia，BEA）的MessageQ和太阳公司（Sun）的Java消息服务（Java Message Service，JMS）等。

MOM包括基于存储和转发的应用之间的异步消息传递或同步消息传递。在异步消息传递中，应用之间彼此不直接通信，而是与作为中介的MOM服务器通信。异步中间件技术又包括广播方式和发布-订阅方式两类。

图2示出了发布-订阅方式的***原理图。如图2中所示，采用发布-订阅模型的MOM利用称为主题（topic）的内容来完成消息的发送和接收。发送应用程序（以下称为发布者）发布自己的消息，指出消息描述的是有关某topic（一般对应该发布者）的信息。希望接收这些消息的应用程序（以下称为订阅者）订阅了这个topic。订阅该topic的订阅者可以接收关于该主题的消息。MOM服务器起着代理的作用，将一个主题已发布的消息路由给该主题的所有订阅者。

对于上述采用异步发布的方式，需要将当前还没有发送完的消息存储在MOM服务器中，在消息发送成功后才将消息从MOM服务器上删除。具体的，发送者可以将消息发送给MOM服务器，MOM服务器将消息存放在某个或某些队列中，在合适的时候再将消息转发给接收者。不同的订阅者一般对应MOM服务器上不同的队列。

现有技术中一种利用MOM进行消息传递的***模型如图3所示。如图3中，包括一个发布者，一个MOM服务器，三个订阅者。前述提到，不同的订阅者一般对应MOM服务器上不同的队列。因此，这里例如存在如图3中三个订阅者的情况下，MOM服务器中包括分别与之对应的三个不同的队列。其具体过程包括：S1，发布者发布消息；S2，MOM服务器接收所述发布者发布的消息，并将该消息复制3份，将每一份置于一个队列中；S3，各订阅者监听所述MOM服务器上各自对应的队列，在监听到对应的队列上有消息后，订阅者发出取回请求；S4，MOM服务器在接收到订阅者的取回请求后，将该订阅者对应的队列上的所述消息路由至所述发出取回请求的订阅者。

在实现本申请过程中，发明人发现现有技术中至少存在如下问题：

发布-订阅模型的MOM实际应用中，不同的订阅者往往对应不同的应用。进一步的，这些不同的应用，往往对应不同的业务***。在某些综合业务***中，存在大量不同的业务***。对于存在大量业务***的情况，按照上述现有技术的实现方式，需要在MOM服务器中配置与之对应的大量的队列，例如对于M个业务***，就需要配置M个队列。MOM服务器接收所述发布者发布的消息后，将该消息复制，将复制的每一份消息置于一个队列中。这样，对于M个队列，就需要复制M份，并将复制的每一份置于一个队列中。进而，在订阅者请求获取订阅的消息后，MOM服务器将队列中的消息路由至请求的订阅者。对于M数值比较大的情况，即存在大量业务***的情况下，MOM服务器中需要设置较多队列。较多的队列将占据MOM服务器较大的存储空间，从而增加MOM服务器的压力。

发明内容

本申请实施例的目的是提供一种消息传递方法和***及MOM服务器、接收端，以降低MOM服务器的压力。

为解决上述技术问题，本申请实施例提供一种消息传递方法和***及MOM服务、接收端是这样实现的：

一种消息传递方法，包括：

发布者发布消息到消息中间件服务器；

消息中间件服务器接收所述发布者发布的消息，并将该接收的消息置于队列中；

消息接收器监听所述消息中间件服务器上的队列，并在监听到所述队列上有消息后，将所述队列上的消息取回，并通知消息拆分器；

消息拆分器收到所述通知后获取消息关注者列表，并通知关注者列表中的关注者；

被通知的关注者将消息发送至该关注者对应的消息处理器。

一种消息传递***，包括发布者，消息中间件服务器，消息接收器，消息拆分器，至少两个关注者，其中，

发布者，用于发布消息到消息中间件服务器；

消息中间件服务器，用于接收所述发布者发布的消息，并将该接收的消息置于队列中；

消息接收器，用于监听所述消息中间件服务器上的队列，并在监听到所述队列上有消息后，将所述队列上的消息取回，并通知消息拆分器；

消息拆分器，用于收到消息接收器发来的通知后获取消息关注者列表，并通知关注者列表中的关注者；

关注者，用于在接到消息拆分器发来的通知后将消息发送至该关注者对应的消息处理器。

一种消息传递***，包括发布者，消息中间件服务器，消息接收器，消息拆分器，至少两个关注者，其中，

发布者，用于发布消息到消息中间件服务器；

消息中间件服务器，用于接收所述发布者发布的消息，并将该接收的消息置于队列中；

消息接收器，用于监听所述消息中间件服务器上的队列，并在监听到所述队列上有消息后，将所述队列上的消息取回，并通知消息拆分器；

消息拆分器，用于收到消息接收器发来的通知后获取消息关注者列表，并通知关注者列表中的关注者；

关注者，用于在接到消息拆分器发来的通知后将消息添加上关注者标识后发送至数据库；

数据库，用于存储发来的消息；

任务调度器，用于轮询数据库上的消息，并将消息发送至对应的消息处理器。

一种接收端，包括：消息接收器，消息拆分器，至少两个关注者，其中，

消息接收器，用于监听所述消息中间件服务器上的队列，并在监听到所述队列上有消息后，将所述队列上的消息取回，并通知消息拆分器；

消息拆分器，用于收到消息接收器发来的通知后获取消息关注者列表，并通知关注者列表中的关注者；

关注者，用于在接到消息拆分器发来的通知后将消息发送至该关注者对应的消息处理器。

一种接收端，包括：消息接收器，消息拆分器，至少两个关注者，其中，

消息接收器，用于监听所述消息中间件服务器上的队列，并在监听到所述队列上有消息后，将所述队列上的消息取回，并通知消息拆分器；

消息拆分器，用于收到消息接收器发来的通知后获取消息关注者列表，并通知关注者列表中的关注者；

关注者，用于在接到消息拆分器发来的通知后将消息添加上关注者标识后发送至数据库；

数据库，用于存储发来的消息；

任务调度器，用于轮询数据库上的消息，并将消息发送至对应的消息处理器。

由以上本申请实施例提供的技术方案可见，由于并不对该消息进行多份复制，而是仅将接收的消息存储到MOM服务器的队列中，因此相对于现有技术将占用MOM服务器极少的存储空间，从而大大减轻了MOM服务器的压力。或者，在本申请实施例中，MOM服务器对接收到的消息复制明显低于订阅者数量的份数，并存储到队列中。这样，相对于现有技术将占用MOM服务器较少的存储空间，从而较现有技术也减轻了MOM服务器的压力。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为一种利用消息中间件技术进行消息传递的原理图；

图2为发布-订阅方式的中间件***原理图；

图3为现有技术中一种利用MOM进行消息传递的***模型如图；

图4为本申请消息传递***一个实施例的一个模块图；

图5为本申请消息传递***一个实施例的另一模块图；

图6为本申请消息传递方法一个实施例的流程图；

图7为本申请消息传递***另一实施例的一个模块图；

图8为本申请消息传递***另一实施例的另一模块图；

图9为本申请消息传递方法另一实施例的流程图；

图10为本申请消息传递***的一个实施场景模块图；

图11为本申请消息传递***的另一实施场景模块图。

具体实施方式

本申请实施例提供一种消息传递方法和***及MOM服务器、接收端。

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

首先介绍本申请消息传递***的一个实施例。

图4示出了本申请消息传递***一个实施例的模块图。如图4所示，该***包括发布者410，MOM服务器420，消息接收器430，消息拆分器440，至少两个关注者（依次编号为451，452，…），至少两个消息处理器（依次编号为461，462，…）。每个消息处理器与一个关注者对应。

发布者410，用于发布消息到MOM服务器。

MOM服务器420，用于接收所述发布者发布的消息，并将该接收的消息置于队列中。

消息接收器430，用于监听所述MOM服务器上的队列，并在监听到所述队列上有消息后，将所述队列上的消息取回，并通知消息拆分器。

消息拆分器440，用于收到消息接收器430发来的通知后获取消息关注者列表，并通知关注者列表中的关注者。

关注者，用于在接到消息拆分器发来的通知后将消息发送至该关注者对应的消息处理器。

所述关注者可以理解为对订阅者在关注事件层面的逻辑划分，可以以软件模块的形式存在，也可以以专用硬件的形式存在，或者以专门的软件+硬件的形式存在。

类似的，所述消息接收器430，消息拆分器440，消息处理器也可以是以软件模块的形式存在，也可以以专用硬件的形式存在，或者以专门的软件+硬件的形式存在。

经过上述处理，消息处理器可以对关注者发来的消息执行相应处理。

所述消息接收器430，消息拆分器440，关注者和消息处理器可以位于同一***中。具体的，例如位于同一***级/应用级软件当中，或者位于同一台实体服务器中，或者位于具有同一功能的服务器群中。当然，也可以灵活设置消息接收器430，消息拆分器440，关注者和消息处理器位于不同的逻辑单元或实体上。后续实施例在未特别声明的情况下，与此类似。

所述MOM服务器，可以是一实体服务器，也可以是执行软件程序的逻辑体，而不必为一单独的实体，再或者可以是集群计算机中的执行特定软件程序的逻辑体。对此本申请并不做限定。

所述关注者列表可以存储于关注者管理器上，例如存在于由关注者管理器维护的关注者管理器列表中。关注者列表中的关注者，可以是关注者在***启动时到关注者管理器注册时，关注者管理器将注册的关注者记录在关注者列表中。后续实施例在未特别声明的情况下，此处与此类似。

所述消息拆分器，可以如图4中的连接关系。该图中，消息拆分器接收的消息接收器发来的通知，可以包括所述消息。相应地，消息拆分器发送至关注者的通知，也可以包括该消息。这样，由于关注者从消息拆分器接收的通知中包括消息，因此关注者下一步可以将该消息直接发送至该关注者对应的消息处理器。

消息接收器通知给消息拆分器的内容中可以包括消息接收器接收到的消息的事件类型。

消息拆分器440通知的关注者列表中的关注者，可以是关注者列表中的与消息的事件类型对应的关注者，而不必包括关注者列表中的与通知中消息事件类型不相关的关注者。这样，后续被通知的关注者将消息发送至关注者对应的消息处理器进行处理。显然的，这样的方式避免了不必要的通知过程，例如不必要对某些关注者的通知，这样可以节省程序，还可以节省资源。

消息拆分器440通知的关注者列表中的关注者，也可以是关注者列表中的所有关注者，即除了通知关注者列表中的与消息拆分器收到通知中消息的事件类型对应的关注者，还通知关注者列表中的与通知中消息事件类型不相关的关注者。该情况下，消息接收器通知给消息拆分器的内容中也可以不包括消息接收器接收到的消息的事件类型。这样，被通知的每个关注者可以分别分析消息内容，例如确定收到的消息的事件类型。进而，如果某个关注者决定需要关注该消息，则该关注者也可以实现将该需要关注的消息发送至该关注者对应的消息处理器进行处理。当然，消息接收器通知给消息拆分器的内容中仍然可以包括消息接收器接收到的消息的事件类型。被通知的每个关注者可以分别分析消息内容，例如确定收到的消息的事件类型，并以关注者自己分析得到的消息事件类型为决定是否关注该消息的依据。进而，如果某个关注者决定需要关注该消息，则该关注者也可以实现将该需要关注的消息发送至该关注者对应的消息处理器进行处理。

前面提到，所述消息接收器430，消息拆分器440，关注者和消息处理器可以位于同一***中，该***在本申请书实施例中可以是以上述消息传递角度看所处的接收端，这样也可以与图4所示的整体***相区别。

需要指明的是，所述消息拆分器，也可以如图5中的连接关系。该图中，消息拆分器接收的消息接收器发来的通知，可以不包括所述消息，而只是简短的通知。相应地，消息拆分器发送至关注者的通知，也可以不包括消息（如图5中虚线所示）。这样，关注者可以在接到消息拆分器发来的通知后到消息接收器上获取消息，并将该获取的消息发送至该关注者对应的消息处理器。所述简短通知中，可以包括事件类型，也可以不包括事件类型。如果所述简短通知包括事件类型，则在上述过程中，消息拆分器440通知的关注者列表中的关注者，可以是关注者列表中的与消息的事件类型对应的关注者，而不必包括关注者列表中的与通知中消息事件类型不相关的关注者。收到通知的关注者可以从消息接收器430上获取消息，并将该消息发送至关注者对应的消息处理器，从而执行后续处理。如果所述简短通知不包括事件类型，则在上述过程中，消息拆分器440通知的关注者列表中的关注者，可以是关注者列表中的全部关注者。关注者可以从消息接收器430上获取消息，进而分析消息内容，例如确定收到的消息的事件类型，并以关注者自己分析得到的消息事件类型为决定是否关注该消息的依据。进一步的，如果某个关注者决定需要关注该消息，则该关注者也可以实现将该需要关注的消息发送至该关注者对应的消息处理器进行处理。该诸类情况不再另用单独的附图加以表述。

以下介绍本申请消息传递方法的一个实施例。

图6示出了本申请消息传递方法的一个实施例的流程图。如图6所示，该实施例包括如下步骤：

S600：发布者发布消息到MOM服务器。

S610：MOM服务器接收所述发布者发布的消息，并将该接收的消息置于队列中。

S620：消息接收器监听所述MOM服务器上的队列，并在监听到所述队列上有消息后，将所述队列上的消息取回，并通知消息拆分器。

S630：消息拆分器收到所述通知后获取消息关注者列表，并通知关注者列表中的关注者。

具体的，关注者列表可以存储在关注者管理器中。相应的，消息拆分器可以从关注者管理器中获取关注者列表。

关注者列表中的关注者，可以是关注者在***启动时到关注者管理器注册时，关注者管理器将注册的关注者记录在关注者列表中。

S620中消息拆分器接收的消息接收器发来的通知，可以包括所述消息。相应地，消息拆分器发送至关注者的通知，也可以包括该消息。这样，由于关注者从消息拆分器接收的通知中包括消息，因此关注者下一步在S640中可以将该消息直接发送至该关注者对应的消息处理器。上述过程可以参考图4对应的***实施例。

S620中所述消息接收器通知消息拆分器，具体的，通知的内容中可以包括消息接收器接收到的消息的事件类型。

S630中所述通知关注者列表中的关注者，具体的，可以是通知关注者列表中的与消息的事件类型对应的关注者，而不必通知关注者列表中的与通知中消息事件类型不相关的关注者。这样，后续被通知的关注者将消息发送至关注者对应的消息处理器进行处理。显然的，这样的方式避免了不必要的通知过程，例如不必要对某些关注者的通知，这样可以节省程序，还可以节省资源。

S630中消息拆分器通知的关注者列表中的关注者，也可以是关注者列表中的所有关注者，即实际上除了通知关注者列表中的与消息拆分器收到通知中消息的事件类型对应的关注者，还通知关注者列表中的与通知中消息事件类型不相关的关注者。该情况下，消息接收器通知给消息拆分器的内容中也可以不包括消息接收器接收到的消息的事件类型。这样，被通知的每个关注者可以分别分析消息内容，例如确定收到的消息的事件类型。进而，如果某个关注者决定需要关注该消息，则该关注者也可以实现将该需要关注的消息发送至该关注者对应的消息处理器进行处理。当然，消息接收器通知给消息拆分器的内容中仍然可以包括消息接收器接收到的消息的事件类型。被通知的每个关注者可以分别分析消息内容，例如确定收到的消息的事件类型，并以关注者自己分析得到的消息事件类型为决定是否关注该消息的依据。进而，如果某个关注者决定需要关注该消息，则该关注者也可以实现将该需要关注的消息发送至该关注者对应的消息处理器进行处理。

需要指明的是，消息拆分器接收的消息接收器发来的通知，也可以不包括所述消息，而只是简短的通知。相应地，消息拆分器发送至关注者的通知，也可以不包括消息。这样，关注者可以在接到消息拆分器发来的通知后到消息接收器上获取消息，并将该获取的消息发送至该关注者对应的消息处理器。所述简短通知中，可以包括事件类型，也可以不包括事件类型。如果所述简短通知包括事件类型，则在上述过程中，消息拆分器通知的关注者列表中的关注者，可以是关注者列表中的与消息的事件类型对应的关注者，而不必包括关注者列表中的与通知中消息事件类型不相关的关注者。收到通知的关注者可以从消息接收器430上获取消息，并将该消息发送至关注者对应的消息处理器，从而执行后续处理。如果所述简短通知不包括事件类型，则在上述过程中，消息拆分器440通知的关注者列表中的关注者，可以是关注者列表中的全部关注者。关注者可以从消息接收器上获取消息，进而分析消息内容，例如确定收到的消息的事件类型，并以关注者自己分析得到的消息事件类型为决定是否关注该消息的依据。进一步的，如果某个关注者决定需要关注该消息，则该关注者也可以实现将该需要关注的消息发送至该关注者对应的消息处理器进行处理。该诸类情况不再另用单独的附图加以表述。

S640：被通知的关注者将消息发送至该关注者对应的消息处理器。

这样，消息处理器可以对关注者发来的消息执行相应处理。

如果S630中消息拆分器通知关注者列表中的与消息的事件类型对应的关注者，而并未通知关注者列表中的与通知中消息事件类型不相关的关注者，则S640中，被通知的关注者将消息发送至关注者对应的消息处理器进行处理。

如果S630中消息拆分器通知关注者列表中的所有关注者，即除了通知关注者列表中的与消息拆分器收到通知中消息的事件类型对应的关注者，还通知关注者列表中的与通知中消息事件类型不相关的关注者，则S640中，被通知的每个关注者可以分别分析消息内容，如果某个关注者决定需要关注该消息，则该关注者将该需要关注的消息发送至该关注者对应的消息处理器进行处理。

所述某个关注者决定需要关注该消息，可以由关注者依据所属订阅者所需处理的事务逻辑来确定。这一点将在后续结合具体场景的例子加以介绍。

以下结合具体场景说明上述本申请方法实施例的实现过程。可以结合图10加以理解。

在线交易服务提供商，有的还在在线交易***中设置了针对交易的保险业务。该保险业务的特点在于与在线交易的各个交易环节相交叉。此类在线交易中的保险也称为交叉类保险。如前所述，交叉类保险的操作和商品交易环节密切相关。特别是在交易流程进行到不同的节点，例如进行到买家拍下商品、买家付款、***创建订单、卖家发货、买家确认收货、交易成功、买家要求退款、交易关闭等不同节点时，不同种类的保险产品会有各自的业务流程进行响应。例如，运费类的保险在卖家发货这一节点上出保单，在交易成功或交易关闭节点使保单失效。在例如，而手机/电子类商品的延保险是在交易成功后才出保单，到保险期满使保单失效。

现有的在线交易服务提供商提供的保险种类多达十几种至几十种，而且还不断有新的险种加入，这对***的可扩展性、可维护性、团队开发效率等提出了很大的挑战。

这里，结合上述图5所示的流程，发布者例如可以是交易服务器，在交易进行到不同节点时发布相应消息至MOM服务器。这里S600具体例如是某一交易服务器发布一条关于创建订单的消息至MOM服务器。对应S610，MOM服务器接收该交易服务器发布的创建订单消息，并将该消息置于队列中。与现有技术相区别的，MOM服务器不必将该消息复制多份，并将每一份置于一个与订阅者对应的队列中。相反的，本申请实施例中，MOM服务器可以将该消息置于一个队列中，或者复制并置于明显小于订阅者数量的队列中。具体的，所述队列的个数可以为1个；或者，所述队列的个数可以大于1同时小于订阅者个数。本申请的其它各实施例中，涉及的队列个数均可以依此设定。

这样，由于并不对该消息进行多份复制，而是仅将接收的消息存储到MOM服务器的队列中，因此相对于现有技术将占用MOM服务器极少的存储空间，从而大大减轻了MOM服务器的压力。

或者在本申请实施例中，MOM服务器对接收到的消息复制明显低于订阅者数量的份数，并存储到队列中。这样，相对于现有技术将占用MOM服务器较少的存储空间，从而较现有技术也减轻了MOM服务器的压力。本申请实施例可以针对订阅者大于1的情况。相应地，存储到的队列数将为1或大于1，但是小于订阅者数。

进一步的，对应S620，保险***（对应接收端）中的消息接收器监听所述MOM服务器上的队列，并在监听到所述队列上有消息后，将所述队列上的消息取回到消息接收器中。之后，对应S630，保险***中的消息拆分器获取消息关注者列表，并通知关注者列表中的关注者。

所述关注者是关于订阅者关注事件的划分。例如订阅者包括3个，分别是订阅者1、订阅者2和订阅者3的情况。这三个订阅者例如分别对应保险***的险种1、险种2和险种3。再例如，可供关注的事件包括创建订单、付款和发货三个事件。则险种1至险种3负责关注的每一事件的逻辑单元称为一个关注者。这样，险种1包括三个关注者，分别是对应创建订单事件的关注者，付款事件的关注者和发货事件的关注者。可以为险种1的这三个关注者分别加以ID标识，例如依次分别为11，12和13。类似的，险种2对应创建订单事件的关注者21，付款事件的关注者22和发货事件的关注者23；险种3对应创建订单事件的关注者31，付款事件的关注者32和发货事件的关注者33。

如前所述，所述消息关注者列表可以存储在关注者管理器中。关注者列表中的关注者名单，可以是关注者在***启动时注册到关注者管理中。例如创建订单事件的关注者11，在保险***启动时到关注者管理器上执行注册，从而在关注者管理器的管理者列表中存有创建订单事件的关注者11。其余关注者类似，不再赘述。

对应S640，被通知的每个关注者将消息发送至该关注者对应的消息处理器，以执行消息处理。

具体的，如果保险***中的消息拆分器接收的通知中包括消息和事件类型，消息拆分器可以将该包含的消息和事件类型通知至关注者列表中的所有关注者，也可以发送至列表中的部分关注者。对于发送至的部分关注者，可以是与消息的事件类型对应的关注者。例如，消息拆分器接收的消息是创建订单消息，事件类型是创建订单。而各个关注者中，ID号第二位为1的才是与关注创建订单的关注者，即与消息的事件类型对应的关注者。因此，消息拆分器可以将包含消息和事件类型的通知发送至这些对应的关注者。对于消息拆分器将该包含的消息和事件类型发送至关注者列表中的所有关注者的情况，被通知的每个关注者，可以将消息的事件类型与自身关注的事件类型进行比对，比对结果一致的关注者将消息发送至对应的消息处理器。

如果保险***中的消息拆分器接收的通知中包括消息，消息拆分器可以将该包含的消息通知至关注者列表中的所有关注者，也可以发送至列表中的部分关注者。对于发送至的部分关注者，可以是与消息的事件类型对应的关注者。例如，消息拆分器接收的消息是创建订单消息，消息拆分器可以对该消息进行分析，从而得到该消息的事件类型。例如通过分析其是否包含特定函数名，或者分析该消息的事件类型字段而得到。例如分析得到的事件类型是创建订单。如前所述，各个关注者中，ID号第二位为1的才是与关注创建订单的关注者，即与消息的事件类型对应的关注者。因此，消息拆分器可以将包含消息和事件类型的通知发送至这些对应的关注者。对于消息拆分器将该包含的消息发送至关注者列表中的所有关注者的情况，被通知的每个关注者，可以分析得到消息的事件类型，例如通过分析该消息是否包含特定的函数名，或者提取该消息的事件类型字段而得到其事件类型，并将该消息的事件类型与自身关注的事件类型进行比对，比对结果一致的关注者将消息发送至对应的消息处理器。

如果保险***中的消息拆分器接收的通知中包括事件类型，消息拆分器可以将该包含的消息通知至关注者列表中的所有关注者，也可以发送至列表中的部分关注者。对于发送至的部分关注者，可以是与消息的事件类型对应的关注者。此情况比较明确，不再赘述。对于消息拆分器将该包含的事件类型发送至关注者列表中的所有关注者的情况，被通知的每个关注者，可以将该消息的事件类型与自身关注的事件类型进行比对，比对结果一致的关注者将消息发送至对应的消息处理器。

如果保险***中的消息拆分器接收的通知中不包括事件类型和消息，消息拆分器可以将该不包含消息和事件类型的通知发送至关注者列表中的所有关注者。关注者可以从消息接收器上获取消息，进而分析消息内容，例如确定收到的消息的事件类型，并以关注者自己分析得到的消息事件类型为决定是否关注该消息的依据。进一步的，如果某个关注者决定需要关注该消息，则该关注者也可以实现将该需要关注的消息发送至该关注者对应的消息处理器进行处理。该诸类情况不再另用单独的附图加以表述。

其它具体实现过程中的细节，可以结合前述***和方法施例得到，在此不再赘述。

对于实际当中类似保险***那样，保险***内保险种类增多的情况，现有技术的维护会越来越复杂，开发效率降低。这是因为，现有技术中每个险种都需要单读配置消息监听队列，同时还要避免接收其他险种的消息队列。如果某条消息被不对应它的险种错误接收，则真正需要处理该消息的险种可能将无法收到该消息。这样，会造成***的错误，影响交易的顺利进行。采用本申请上述实施例的方式，在消息处理过程中，MOM服务器只需发送一条消息，而且，MOM服务器并不需关心该消息的接收者。可以由消息拆分器或者由关注者实现对消息由哪个关注者及其对应的消息处理器处理的确认，降低MOM服务器压力。在有新的险种产生，可以根据险种自身业务逻辑，增加对应的关注者和消息处理器就可以实现对该消息的监听处理，非常容易扩展，开发效率也显著提高。或者有险种的关注关系需要变更时，根据险种变更后的自身业务逻辑，修正对应的关注者和消息处理器，就可以实现对消息的正确监听处理，也非常容易扩展，开发效率也显著提高。

以下介绍本申请消息传递***的另一实施例。

图7示出了本申请消息传递***另一实施例的模块图。如图7所示，该***包括发布者410，MOM服务器420，消息接收器430，消息拆分器440，至少两个关注者（依次编号为451，452，…），至少两个消息处理器（依次编号为461，462，…）。每个消息处理器与一个关注者对应。

发布者410，用于发布消息到MOM服务器。

MOM服务器420，用于接收所述发布者发布的消息，并将该接收的消息置于队列中。

消息接收器430，用于监听所述MOM服务器上的队列，并在监听到所述队列上有消息后，将所述队列上的消息取回，并通知消息拆分器。

消息拆分器440，用于收到消息接收器430发来的通知后获取消息关注者列表，并通知关注者列表中的关注者。

关注者，用于在接到消息拆分器发来的通知后将需要关注的消息添加上关注者ID后发送至数据库470。

数据库470，用于存储发来的消息。

该数据库可以是为***的缓存级存储单元，例如CPU中的一级缓存、二级缓存甚至三级缓存，也可以是软件级别的缓存单元，也可以是软件级别的数据库，还可以是具有专门存储功能的软件和/或硬件的单元，在此并不限定。

任务调度器480，用于轮询数据库470上的消息，并将消息发送至对应的消息处理器进行处理。

经过上述处理，消息处理器可以对关注者发来的消息执行相应处理。

所述消息接收器430，消息拆分器440，关注者和消息处理器可以位于同一***中。具体的，例如位于同一***级/应用级软件当中，或者位于同一台实体服务器中，或者位于具有同一功能的服务器群中。当然，也可以灵活设置消息接收器430，例如消息拆分器440，关注者、数据库470，任务调度器480和消息处理器中的部分位于同一逻辑单元或实体上。后续实施例在未特别声明的情况下，与此类似。

所述MOM服务器，可以是一实体服务器，也可以是执行软件程序的逻辑体，而不必为一单独的实体，再或者可以是集群计算机中的执行特定软件程序的逻辑体。对此本申请并不做限定。

所述关注者列表可以存储于关注者管理器上，例如存在于由关注者管理器维护的关注者管理器列表中。关注者列表中的关注者，可以是关注者在***启动时到关注者管理器注册时，关注者管理器将注册的关注者记录在关注者列表中。后续实施例在未特别声明的情况下，此处与此类似。

所述消息拆分器，可以如图4中的连接关系。该图中，消息拆分器接收的消息接收器发来的通知，可以包括所述消息。相应地，消息拆分器发送至关注者的通知，也可以包括消息。这样，由于关注者从消息拆分器接收的通知中包括消息，因此关注者下一步可以将该消息直接发送至该关注者对应的消息处理器。

消息接收器通知给消息拆分器的内容中可以包括消息接收器接收到的消息的事件类型。相应地，消息拆分器440通知的关注者列表中的关注者，可以是关注者列表中的与消息拆分器收到通知中消息的事件类型对应的关注者，而不必包括关注者列表中的与通知中消息事件类型不相关的关注者。这样，后续被通知的关注者将消息发送至关注者对应的消息处理器进行处理。显然的，这样的方式避免了不必要的通知过程，例如不必要对某些关注者的通知，这样可以节省程序，还可以节省资源。

消息拆分器440通知的关注者列表中的关注者，也可以是关注者列表中的所有关注者，即除了通知关注者列表中的与消息拆分器收到通知中消息的事件类型对应的关注者，还通知关注者列表中的与通知中消息事件类型不相关的关注者。该情况下，消息接收器通知给消息拆分器的内容中也可以不包括消息接收器接收到的消息的事件类型。这样，被通知的每个关注者可以分别分析消息内容，例如确定收到的消息的事件类型。进而，如果某个关注者决定需要关注该消息，则该关注者也可以实现将该需要关注的消息发送至该关注者对应的消息处理器进行处理。当然，消息接收器通知给消息拆分器的内容中仍然可以包括消息接收器接收到的消息的事件类型。被通知的每个关注者可以分别分析消息内容，例如确定收到的消息的事件类型，并以关注者自己分析得到的消息事件类型为决定是否关注该消息的依据。进而，如果某个关注者决定需要关注该消息，则该关注者也可以实现将该需要关注的消息发送至该关注者对应的消息处理器进行处理。

前面提到，所述消息接收器430，消息拆分器440，关注者和消息处理器可以位于同一***中，该***在本申请书实施例中可以是以上述消息传递角度看所处的接收端，这样也可以与图4所示的整体***相区别。

上述***中，可以由关注者接收消息拆分器发来的消息，并由关注者在需要关注的消息上添加关注者ID，并将该添加者ID后的消息发送至数据库470。该方式可以如图7所示的联系关系实现。

也可以如图8中的连接关系，关注者并不接收消息，而是由消息拆分器将消息发送至数据库。该情况下，关注者可以将关注者ID发送至消息拆分器，并指明需要添加的消息。由消息拆分器在对应的消息上添加上关注者ID。

需要指明的是，本***实施例尽管示出了图7、图8两种情况，但所述消息拆分器与消息接收器之间也可以如图5中那样连接关系。该情况下，消息拆分器接收的消息接收器发来的通知，可以不包括所述消息，而只是简短的通知。相应地，消息拆分器发送至关注者的通知，也可以不包括消息。这样，关注者可以在接到消息拆分器发来的通知后到消息接收器上获取消息，并将该获取的消息发送至数据库。

图9示出了本申请消息传递方法的另一实施例的流程图。如图9所示，该实施例包括如下步骤：

S900：发布者发布消息。

S910：MOM服务器接收所述发布者发布的消息，并将该接收的消息置于队列中。

S920：消息接收器监听所述MOM服务器上的队列，并在监听到所述队列上有消息后，将所述队列上的消息取回，并通知消息拆分器。

S930：消息拆分器收到所述通知后获取消息关注者列表，并通知关注者列表中的关注者。

具体的，关注者列表可以存储在关注者管理器中。相应的，消息拆分器可以从关注者管理器中获取关注者列表。

关注者列表中的关注者，可以是关注者在***启动时到关注者管理器注册时，关注者管理器将注册的关注者记录在关注者列表中。

S920中消息拆分器接收的消息接收器发来的通知，可以包括所述消息。相应地，消息拆分器发送至关注者的通知，也可以包括该消息。这样，由于关注者从消息拆分器接收的通知中包括消息，因此关注者下一步在S940中可以将需要关注的消息标记上关注者ID并存储于数据库中。上述过程可以参考图7对应的***实施例。

S920中所述消息接收器通知消息拆分器，具体的，通知的内容中可以包括消息接收器接收到的消息的事件类型。

S930中所述通知关注者列表中的关注者，具体的，可以是通知关注者列表中的与消息的事件类型对应的关注者，而不必通知关注者列表中的与通知中消息事件类型不相关的关注者。这样，后续被通知的关注者将需要关注的消息标记上关注者ID并存储于数据库中。显然的，这样的方式避免了不必要的通知过程，例如不必要对某些关注者的通知，这样可以节省程序，还可以节省资源。

S930中消息拆分器通知的关注者列表中的关注者，也可以是关注者列表中的所有关注者，即实际上除了通知关注者列表中的与消息拆分器收到通知中消息的事件类型对应的关注者，还通知关注者列表中的与通知中消息事件类型不相关的关注者。该情况下，消息接收器通知给消息拆分器的内容中也可以不包括消息接收器接收到的消息的事件类型。这样，被通知的每个关注者可以分别分析消息内容，例如确定收到的消息的事件类型。进而，如果某个关注者决定需要关注该消息，则该关注者也可以将需要关注的消息标记上关注者ID并存储于数据库中。当然，消息接收器通知给消息拆分器的内容中仍然可以包括消息接收器接收到的消息的事件类型。被通知的每个关注者可以分别分析消息内容，例如确定收到的消息的事件类型，并以关注者自己分析得到的消息事件类型为决定是否关注该消息的依据。进而，如果某个关注者决定需要关注该消息，则该关注者也可以实现将需要关注的消息标记上关注者ID并存储于数据库中。

需要指明的是，消息拆分器接收的消息接收器发来的通知，也可以不包括所述消息，而只是简短的通知。相应地，消息拆分器发送至关注者的通知，也可以不包括消息。这样，关注者可以在接到消息拆分器发来的通知后到消息接收器上获取消息，并将需要关注的消息标记上关注者ID并存储于数据库中。所述简短通知中，可以包括事件类型，也可以不包括事件类型。如果所述简短通知包括事件类型，则在上述过程中，消息拆分器通知的关注者列表中的关注者，可以是关注者列表中的与消息的事件类型对应的关注者，而不必包括关注者列表中的与通知中消息事件类型不相关的关注者。收到通知的关注者可以从消息接收器430上获取消息，并将该消息发送至关注者对应的消息处理器，从而执行后续处理。如果所述简短通知不包括事件类型，则在上述过程中，消息拆分器440通知的关注者列表中的关注者，可以是关注者列表中的全部关注者。关注者可以从消息接收器上获取消息，进而分析消息内容，例如确定收到的消息的事件类型，并以关注者自己分析得到的消息事件类型为决定是否关注该消息的依据。进一步的，如果某个关注者决定需要关注该消息，则该关注者也可以实现将需要关注的消息标记上关注者ID并存储于数据库中。该诸类情况不再另用单独的附图加以表述。

S940：被通知的关注者将该需要关注的消息添加上关注者ID后发送至数据库中。

如果S930中消息拆分器通知关注者列表中的与消息的事件类型对应的关注者，而并未通知关注者列表中的与通知中消息事件类型不相关的关注者，则S940中，被通知的关注者添加上关注者ID后发送至数据库中。

如果S930中消息拆分器通知关注者列表中的所有关注者，即除了通知关注者列表中的与消息的事件类型对应的关注者，还通知关注者列表中的不相关的关注者，则S940中，被通知的每个关注者可以分别分析消息内容，如果某个关注者决定需要关注该消息，则该关注者将该需要关注的消息发送至该关注者对应的消息处理器进行处理。

所述某个关注者决定需要关注该消息，可以由关注者依据所属订阅者所需处理的事务逻辑来确定。这一点在前述部分已给出介绍，不再赘述。

S950：任务调度器定时到数据库中轮询，如果有存储的消息，则读取该消息上标记的关注者ID，并按照该消息上标注的关注者ID查找并通知对应的消息处理器。

事实上，关注者ID与消息处理器有一一对应关系。也就是说，某一消息处理器，专用于处理某一关注者关注的消息。为了实现该对应关系，可以为每个消息处理器也添加一个ID，该消息处理器的ID与对应的关注者的ID相同。

S960：收到通知的消息处理器处理数据库中对应的标注有关注者ID的消息。

S970：如果所述消息处理器执行消息处理成功，则将数据库中的该消息的处理状态更新为成功；如果所述消息处理器执行消息处理失败，则将数据库中的该消息的处理状态更新为失败，设置下次重试处理的时间，并累计该消息的重试次数。

需要说明的是，S970中两种如果的情况，可以不是必须同时具备的。也就是说，可以选择其中的一种执行。

S980：数据库定时查询每个消息的处理状态，对于处理状态为成功的消息执行删除处理，对于重试次数达到或超过预定值的消息则发出***报警。

需要说明的是，S980中数据库定时查询每个消息的处理状态，对于处理状态为成功的消息执行删除处理，与对重试次数达到或超过预定值的消息则发出***报警，可以不是必须同时具备的。也就是说，可以选择其中的一种执行。而且，S980不依赖于S970的执行而执行。

以下结合具体场景说明上述本申请方法实施例的实现过程，并且主要介绍不同于前一结合具体场景的具体过程，相同或相类似部分不再描述或不再做具体描述。可以结合图11加以理解。

仍然是对于在线交易***中设置了针对交易的保险业务，这里结合上述图9所示的流程加以说明。与前述例子类似的，MOM服务器不必将该消息复制多份，并将每一份置于一个与订阅者对应的队列中。相反的，MOM服务器可以将该消息置于一个队列中，或者复制并置于明显小于订阅者数量的队列中。这样，由于并不对该消息进行多份复制，而是仅将接收的消息存储到MOM服务器的队列中，因此相对于现有技术将占用MOM服务器极少的存储空间，从而大大减轻了MOM服务器的压力。或者在本申请实施例中，MOM服务器对接收到的消息复制明显低于订阅者数量的份数，并存储到队列中。这样，相对于现有技术将占用MOM服务器较少的存储空间，从而较现有技术也减轻了MOM服务器的压力。本申请实施例可以针对订阅者大于1的情况。相应地，存储到的队列数将为1或大于1，但是小于订阅者数。

进一步的，对应S920，保险***（对应接收端）中的消息接收器监听所述MOM服务器上的队列，并在监听到所述队列上有消息后，将所述队列上的消息取回到消息接收器中。之后，对应S930，保险***中的消息拆分器获取消息关注者列表，并通知关注者列表中的关注者。

如前所述，所述消息关注者列表可以存储在关注者管理器中。关注者列表中的关注者名单，可以是关注者在***启动时注册到关注者管理中。例如创建订单事件的关注者11，在保险***启动时到关注者管理器上执行注册，从而在关注者管理器的管理者列表中存有创建订单事件的关注者11。其余关注者类似，不再赘述。

对应S940，被通知的每个关注者将该需要关注的消息添加上关注者ID后发送至数据库中。

具体的，如果保险***中的消息拆分器接收的通知中包括消息和事件类型，消息拆分器可以将该包含的消息和事件类型通知至关注者列表中的所有关注者，也可以发送至列表中的部分关注者。对于发送至的部分关注者，可以是与消息的事件类型对应的关注者。例如，消息拆分器接收的消息是创建订单消息，事件类型是创建订单。而各个关注者中，ID号第二位为1的才是与关注创建订单的关注者，即与消息的事件类型对应的关注者。因此，消息拆分器可以将包含消息和事件类型的通知发送至这些对应的关注者。对于消息拆分器将该包含的消息和事件类型发送至关注者列表中的所有关注者的情况，被通知的每个关注者，可以将消息的事件类型与自身关注的事件类型进行比对，比对结果一致的关注者将该需要关注的消息添加上关注者ID后发送至数据库中。

如果保险***中的消息拆分器接收的通知中包括消息，消息拆分器可以将该包含的消息通知至关注者列表中的所有关注者，也可以发送至列表中的部分关注者。对于发送至的部分关注者，可以是与消息的事件类型对应的关注者。例如，消息拆分器接收的消息是创建订单消息，消息拆分器可以对该消息进行分析，从而得到该消息的事件类型。例如通过分析其是否包含特定函数名，或者分析该消息的事件类型字段而得到。例如分析得到的事件类型是创建订单。如前所述，各个关注者中，ID号第二位为1的才是与关注创建订单的关注者，即与消息的事件类型对应的关注者。因此，消息拆分器可以将包含消息和事件类型的通知发送至这些对应的关注者。对于消息拆分器将该包含的消息发送至关注者列表中的所有关注者的情况，被通知的每个关注者，可以分析得到消息的事件类型，例如通过分析该消息是否包含特定的函数名，或者提取该消息的事件类型字段而得到其事件类型，并将该消息的事件类型与自身关注的事件类型进行比对，比对结果一致的关注者将该需要关注的消息添加上关注者ID后发送至数据库中。

如果保险***中的消息拆分器接收的通知中包括事件类型，消息拆分器可以将该包含的消息通知至关注者列表中的所有关注者，也可以发送至列表中的部分关注者。对于发送至的部分关注者，可以是与消息的事件类型对应的关注者。此情况比较明确，不再赘述。对于消息拆分器将该包含的事件类型发送至关注者列表中的所有关注者的情况，被通知的每个关注者，可以将该消息的事件类型与自身关注的事件类型进行比对，比对结果一致的关注者将该需要关注的消息添加上关注者ID后发送至数据库中。

如果保险***中的消息拆分器接收的通知中不包括事件类型和消息，消息拆分器可以将该不包含消息和事件类型的通知发送至关注者列表中的所有关注者。关注者可以从消息接收器上获取消息，进而分析消息内容，例如确定收到的消息的事件类型，并以关注者自己分析得到的消息事件类型为决定是否关注该消息的依据。进一步的，如果某个关注者决定需要关注该消息，则该关注者也可以实现将该需要关注的消息添加上关注者ID后发送至数据库中。该诸类情况不再另用单独的附图加以表述。

其它具体实现过程中的细节，可以结合前述***和方法施例得到，在此不再赘述。

对于实际当中类似保险***那样，保险***内保险种类增多的情况，现有技术的维护会越来越复杂，开发效率降低。这是因为，现有技术中每个险种都需要单读配置消息监听队列，同时还要避免接收其他险种的消息队列。如果某条消息被不对应它的险种错误接收，则真正需要处理该消息的险种可能将无法收到该消息。这样，会造成***的错误，影响交易的顺利进行。采用本申请上述实施例的方式，在消息处理过程中，MOM服务器只需发送一条消息，而且，MOM服务器并不需关心该消息的接收者。可以由消息拆分器或者由关注者实现对消息由哪个关注者及其对应的消息处理器处理的确认，降低MOM服务器压力。在有新的险种产生，可以根据险种自身业务逻辑，增加对应的关注者和消息处理器就可以实现对该消息的监听处理，非常容易扩展，开发效率也显著提高。或者有险种的关注关系需要变更时，根据险种变更后的自身业务逻辑，修正对应的关注者和消息处理器，就可以实现对消息的正确监听处理，也非常容易扩展，开发效率也显著提高。

后续，可以采用异步处理的方式，即使得关注者不必在得知有消息到来时立即做出响应，而是可以在其它时刻再对到达的消息做出响应。这种异步处理方式的好处显而易见。具体的，可以通过将到达的消息存储于数据库中，例如前述对应S940的步骤；之后，执行对应S950、S960的步骤。

此外，后续还可以执行对应S970、S980的处理，这类处理可以保障消息处理的成功率，并对暂时没有成功处理的消息提供报警，从而利于***后续采取进一步的措施。而且，对成功处理的消息，在确认成功处理之后从数据库中删除，利于保持数据库存储空间的利用率。

上述实施例阐明的***、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于***实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本申请可用于众多通用或专用的计算***环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器***、基于微处理器的***、置顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何***或设备的分布式计算环境等等。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

虽然通过实施例描绘了本申请，本领域普通技术人员知道，本申请有许多变形和变化而不脱离本申请的精神，希望所附的权利要求包括这些变形和变化而不脱离本申请的精神。

Claims (18)

1.一种消息传递方法，其特征在于，包括：

发布者发布消息到消息中间件服务器；

消息中间件服务器接收所述发布者发布的消息，并将该接收的消息置于队列中；

消息接收器监听所述消息中间件服务器上的队列，并在监听到所述队列上有消息后，将所述队列上的消息取回，并通知消息拆分器；

消息拆分器收到所述通知后获取消息关注者列表，并通知关注者列表中的关注者；

被通知的关注者将消息发送至该关注者对应的消息处理器；

如果所述消息处理器执行消息处理成功，则将数据库中的该消息的处理状态更新为成功；或，

如果所述消息处理器执行消息处理失败，则将数据库中的该消息的处理状态更新为失败，设置下次重试处理的时间，并累计该消息的重试次数。

2.如权利要求1所述的方法，其特征在于，所述消息拆分器接收消息接收器发来的通知，具体包括：

消息拆分器接收消息接收器发来的包括消息的通知；或，

消息拆分器接收消息接收器发来的包括消息和事件类型的通知；或，

消息拆分器接收消息接收器发来的包括事件类型的通知；或

消息拆分器接收消息接收器发来的不包括消息和事件类型的通知。

3.如权利要求1或2所述的方法，其特征在于，所述消息拆分器通知关注者列表中的关注者，具体包括：

消息拆分器通知关注者列表中的与消息的事件类型对应的关注者；或，

消息拆分器通知关注者列表中的全部关注者。

4.如权利要求1所述的方法，其特征在于，所述被通知的关注者将消息发送至该关注者对应的消息处理器，具体包括：

被通知的关注者将需要关注的消息添加上关注者标识后发送至数据库中；

任务调度器定时到数据库中轮询，如果有存储的消息，则读取该消息上标记的关注者标识，并按照该消息上标注的关注者标识查找并通知对应的消息处理器。

5.如权利要求1所述的方法，其特征在于，所述方法还包括：

数据库定时查询每个消息的处理状态，对于处理状态为成功的消息执行删除处理；或，

对于重试次数达到或超过预定值的消息发出***报警。

6.如权利要求1所述的方法，其特征在于：

所述队列的个数为1个；或，

所述队列的个数大于1，小于订阅者个数。

7.一种消息传递***，其特征在于，包括发布者，消息中间件服务器，消息接收器，消息拆分器，至少两个关注者，其中，

发布者，用于发布消息到消息中间件服务器；

消息中间件服务器，用于接收所述发布者发布的消息，并将该接收的消息置于队列中，所述队列的个数为1个；或，所述队列的个数大于1，小于订阅者个数；

消息接收器，用于监听所述消息中间件服务器上的队列，并在监听到所述队列上有消息后，将所述队列上的消息取回，并通知消息拆分器；

消息拆分器，用于收到消息接收器发来的通知后获取消息关注者列表，并通知关注者列表中的关注者；

关注者，用于在接到消息拆分器发来的通知后将消息发送至该关注者对应的消息处理器。

8.如权利要求7所述的***，其特征在于，所述消息拆分器接收的消息接收器发来的通知，具体包括：

包括消息的通知；或，

包括消息和事件类型的通知；或，

包括事件类型的通知；或

不包括消息和事件类型的通知。

9.如权利要求7-8中任一项所述的***，其特征在于，所述消息拆分器通知关注者列表中的关注者，具体包括：

与消息的事件类型对应的关注者；或，

关注者列表中的全部关注者。

10.一种消息传递***，其特征在于，包括发布者，消息中间件服务器，消息接收器，消息拆分器，至少两个关注者，其中，

发布者，用于发布消息到消息中间件服务器；

消息中间件服务器，用于接收所述发布者发布的消息，并将该接收的消息置于队列中，所述队列的个数为1个；或，所述队列的个数大于1，小于订阅者个数；

消息接收器，用于监听所述消息中间件服务器上的队列，并在监听到所述队列上有消息后，将所述队列上的消息取回，并通知消息拆分器；

消息拆分器，用于收到消息接收器发来的通知后获取消息关注者列表，并通知关注者列表中的关注者；

关注者，用于在接到消息拆分器发来的通知后将消息添加上关注者标识后发送至数据库；

数据库，用于存储发来的消息；

任务调度器，用于轮询数据库上的消息，并将消息发送至对应的消息处理器。

11.如权利要求10所述的***，其特征在于，所述消息拆分器接收的消息接收器发来的通知，具体包括：

包括消息的通知；或，

包括消息和事件类型的通知；或，

包括事件类型的通知；或

不包括消息和事件类型的通知。

12.如权利要求10-11中任一项所述的***，其特征在于，所述消息拆分器通知关注者列表中的关注者，具体包括：

与消息的事件类型对应的关注者；或，

关注者列表中的全部关注者。

13.一种接收端，其特征在于，包括：消息接收器，消息拆分器，至少两个关注者，其中，

消息接收器，用于监听所述消息中间件服务器上的队列，并在监听到所述队列上有消息后，将所述队列上的消息取回，并通知消息拆分器，所述队列的个数为1个；或，所述队列的个数大于1，小于订阅者个数；

消息拆分器，用于收到消息接收器发来的通知后获取消息关注者列表，并通知关注者列表中的关注者；

关注者，用于在接到消息拆分器发来的通知后将消息发送至该关注者对应的消息处理器。

14.如权利要求13所述的接收端，其特征在于，所述消息拆分器接收的消息接收器发来的通知，具体包括：

包括消息的通知；或，

包括消息和事件类型的通知；或，

包括事件类型的通知；或

不包括消息和事件类型的通知。

15.如权利要求13-14中任一项所述的接收端，其特征在于，所述消息拆分器通知关注者列表中的关注者，具体包括：

与消息的事件类型对应的关注者；或，

关注者列表中的全部关注者。

16.一种接收端，其特征在于，包括：消息接收器，消息拆分器，至少两个关注者，其中，

消息接收器，用于监听所述消息中间件服务器上的队列，并在监听到所述队列上有消息后，将所述队列上的消息取回，并通知消息拆分器，所述队列的个数为1个；或，所述队列的个数大于1，小于订阅者个数；

消息拆分器，用于收到消息接收器发来的通知后获取消息关注者列表，并通知关注者列表中的关注者；

关注者，用于在接到消息拆分器发来的通知后将消息添加上关注者标识后发送至数据库；

数据库，用于存储发来的消息；

任务调度器，用于轮询数据库上的消息，并将消息发送至对应的消息处理器。

17.如权利要求16所述的接收端，其特征在于，所述消息拆分器接收的消息接收器发来的通知，具体包括：

包括消息的通知；或，

包括消息和事件类型的通知；或，

包括事件类型的通知；或

不包括消息和事件类型的通知。

18.如权利要求16-17中任一项所述的接收端，其特征在于，所述消息拆分器通知关注者列表中的关注者，具体包括：

与消息的事件类型对应的关注者；或，

关注者列表中的全部关注者。