CN106953884A - 中间件消息处理方法、装置及中间件平台 - Google Patents

Abstract

本发明实施例公开了一种中间件消息处理方法、装置及中间件平台，所述方法包括：将请求消息存储在消息队列中；将请求消息分发给处理节点进行处理；接收所述处理节点返回的处理结果；在接收到处理结果后，根据所述处理结果删除消息队列中的所述请求消息。

Description

中间件消息处理方法、装置及中间件平台

技术领域

本发明涉及信息技术领域，尤其涉及一种中间件消息处理方法、装置及中间件平台。

背景技术

在现有的中间件消息处理过程中，若从客户端接收到一个消息后直接进行处理，若处理节点在负载繁重的情况下出现消息丢弃时，就直接会导致客户端的请求无法响应的现象，从而导致响应成功率差及用户使用满意度低的问题。

发明内容

有鉴于此，本发明实施例期望提供一种中间件消息处理方法、装置及中间件平台，至少部分解决请求消息响应成功率低的现象。

为达到上述目的，本发明的技术方案是这样实现的：

本发明实施例第一方面提供的一种中间件消息处理方法，所述方法包括：

将请求消息存储在消息队列中；

将请求消息分发给处理节点进行处理；

接收所述处理节点返回的处理结果；

在接收到处理结果后，根据所述处理结果删除消息队列中的所述请求消息。

基于上述方案，所述方法还包括：

在将所述请求消息分发给处理节点后，形成分发标识；所述分发标识用于指示所述请求消息的分发状态

所述将请求消息分发给处理节点进行处理，包括：

根据所述分发标识，将未分发给处理节点的所述请求消息分发给所述处理节点。

基于上述方案，所述方法还包括：

在将所述请求消息分发给处理节点之后，启动计时形成计时结果；

所述将请求消息分发给处理节点进行处理，包括：

若所述计时结果表明在指定时间内未接收到所述处理结果，则将所述请求消息重新分发给所述处理节点。

基于上述方案，已分发给处理节点的请求消息由分发标识进行指示；

所述方法还包括：

若所述及时结果表明在指定时间内未接收到所述处理结果，清除所述请求消息对应的分发标识。

基于上述方案，所述将请求消息分发给处理节点进行处理，包括：

采用轮询机制将所述请求消息分发给所述处理节点。

本发明实施例第二方面提供一种中间件消息处理装置，所述装置包括：

存储单元，用于将请求消息存储在消息队列中；

分发单元，用于将请求消息分发给处理节点进行处理；

接收单元，用于接收所述处理节点返回的处理结果；

所述存储单元，还用于在接收到处理结果后，根据所述处理结果删除消息队列中的所述请求消息。

基于上述方案，所述装置还包括：

形成单元，用于在将所述请求消息分发给处理节点后，形成分发标识；所述分发标识用于指示所述请求消息的分发状态

所述分发单元，具体用于根据所述分发标识，将未分发给处理节点的所述请求消息分发给所述处理节点。

基于上述方案，所述装置还包括：

计时单元，用于在将所述请求消息分发给处理节点之后，启动计时形成计时结果；

所述分发单元，具体用于若所述计时结果表明在指定时间内未接收到所述处理结果，则将所述请求消息重新分发给所述处理节点。

基于上述方案，已分发给处理节点的请求消息由分发标识进行指示；

所述形成单元，还用于若所述及时结果表明在指定时间内未接收到所述处理结果，清除所述请求消息对应的分发标识。

基于上述方案，所述分发单元，具体用于采用轮询机制将所述请求消息分发给所述处理节点。

本发明实施例第三方面提供一种中间件平台，所述系统包括分发节点和处理节点：

所述处理节点，用于对请求消息进行处理，形成处理结果；

分发节点，用于将请求消息存储在消息队列中，将所述消息队列中的请求消息分发给所述处理节点，接收所述处理节点返回的的处理结果；根据所述处理结果删除所述消息队列中的所述请求消息。

本发明实施例提供的中间件消息处理方法、装置及中间件平台，将在消息队列中存储请求消息，将请求消息分发给处理节点，在接收到处理结果之后在删除请求消息，可以减少现有技术中直接将请求消息分发给处理节点，处理节点丢弃该请求消息导致的请求无法响应，请求响应成功率低等问题。

附图说明

图1为本发明实施例提供的第一种中间件消息处理方法的流程示意图；

图2为本发明实施例提供的第二种中间件消息处理方法的流程示意图；

图3为本发明实施例提供的中间件消息分发装置的结构示意图；

图4为本发明实施例提供的一种中间件平台的结构示意图；

图5为本发明实施例提供的另一种中间件平台的结构示意图。

具体实施方式

以下结合说明书附图及具体实施例对本发明的技术方案做进一步的详细阐述。

实施例一：

如图1所示，本实施例提供一种中间件消息处理方法，所述方法包括：

步骤S110：将请求消息存储在消息队列中；

步骤S120：将请求消息分发给处理节点进行处理；

步骤S130：接收所述处理节点返回的处理结果；

步骤S140：在接收到处理结果后，根据所述处理结果删除消息队列中的所述请求消息。

在本实施例中所述中间件在接收到请求消息之后，首先将请求消息存储在消息队列中，而不是直接将请求消息发送给处理节点。在步骤S120中将请求消息分发给处理节点进行处理，在步骤S130中将接收处理节点返回的处理结果。这里的处理结果可包括响应成功结果或响应失败结果。在步骤S140中将在接收到处理结果之后，根据处理结果删除消息队列中的请求消息，这样的话，若处理成功直接删除消息队列中对应的消息，若不成功，可以根据处理策略进行对应的处理。这里的可包括，将该请求消息分发给其他处理节点，由其他处理节点进行处理，看其他处理节点能够成功响应。当然也包括可以根据响应失败结果删除所述请求消息。

显然本实施例中所述中间件消息处理方法，可以避免一个处理节点接收到请求消息之后，由于操作失误或负载过重直接丢弃了该请求消息，而在整个中间件平台中就再也找不到该请求消息导致的请求不能响应或响应成功率低的现象。

在步骤S110之前所述方法还可包括接收用户请求，将用户请求转换为中间件内部格式的所述请求消息。在本实施例所述步骤S110中可以利用新消息输入输出(New Input Output，NIO)缓存机制对所述请求消息进行缓存。利用NIO缓存机制进行请求消息的存储时，在处理节点中划分了一个缓存区，对该请求消息存储和分发处理，这样的话，能够大大的提升请求消息的存储和分发机制，减少因请求消息存储和分发导致的请求消息的响应时延。

在步骤S120中可以根据所述请求消息进入队列时间顺序按照时间先后，优先分发先进入队列的请求消息，以避免有的请求消息因为得不到分发导致的响应时间长的问题。在具体的实现过程中，还可以提取请求消息的消息属性，确定该请求消息的时延性要求，根据时延性要求来分发所述请求消息。总之，在本实施例步骤S120中分发节点可以根据分发策略来分发所述请求消息，以尽可能的确保请求消息的整体时延性，可确保要求时延要求高的请求消息尽可能的被优先处理，时延要求较低的请求消息可以适当的调整响应顺序。显然本实施例所述的消息处理方法，不仅能够减少请求消息还未被响应就丢失导致的无法响应或响应不成功的现象，同时还能够利用消息队列分发请求消息的策略，提升请求消息的响应速率。

当然在具体实现时，所述步骤S120还可以根据各个所述处理节点的当前负载状况及处理能力，确定将所述请求消息分发给哪一个处理节点，以实现处理节点的负载均衡。

作为本实施例的进一步改进，如图2所示，所述方法还包括：

步骤S121：在将所述请求消息分发给处理节点后，形成分发标识；所述分发标识用于指示所述请求消息的分发状态

所述步骤S120可包括：根据所述分发标识，将未分发给处理节点的所述请求消息分发给所述处理节点。

消息队列中的消息可包括已分发的请求消息和未分发的请求消息，在本实施例中会形成一个分发标识，来指示当前对应的请求消息是否已经分发给了处理节点。例如，开辟一个或多个比特表示该请求消息是否已经分发。若已经分发了则将该比特的内容置为1，否则置为0。该本比特的内容即对应于所述分发标识，这样分发节点根据该分发标识确定出哪些请求消息已经分发给了处理节点在进行处理，而哪些请求消息为待分发消息。在本实施例中步骤S120分发给处理节点的为未分发给处理节点的请求消息。

在具体的实现过程中，所述消息队列可不止一个；例如，所述消息队列包括第一队列和第二队列；所述第一队列存储分发的消息，第二队列存储已分发的消息。所述第二队列对应有一个或多个标识比特，与所述第一队列进行区分，该一个或多个标识比特即可为所述分发标识的一种。

这样通过分发标识的形成，可以避免一个请求消息的重复分发。

进一步地，所述方法还包括：在将所述请求消息分发给处理节点之后，启动计时形成计时结果。所述步骤S120可包括：若所述计时结果表明在指定时间内未接收到所述处理结果，则将所述请求消息重新分发给所述处理节点。

在本实施例中还引入了计时操作。若将一个请求消息发送给一个处理节点进行处理，若该处理节点能够进行处理或能够及时进行处理，则会在指定时间内返回处理结果。故在本实施例中分发节点将根据计时结果，在指定时间内未接收到处理结果时，将会重新分发所述请求消息，避免请求消息分发失败或处理节点丢弃了该请求消息导致的请求消息不能响应的问题，同时通过计时操作的引入，也可以防止一个请求消息迟迟得不到响应的问题。

在具体的实现过程中，所述方法还可包括：记录每个处理节点未能在指定时间内返回处理结果的频次，根据该频次启动检测处理。这里的检测处理包括：检测导致未能按时返回处理结果的异常原因，根据该异常原因确定排除异常，以确保请求消息的响应速度。这里的异常原因可包括请求消息分发不成功或处理节点主动丢弃请求消息或处理节点负载过大等异常。若分发不成功，则排查是否分发的消息通道异常，排除异常。若处理节点负载过大，则调整分发策略；总之，通过异常排除以尽可能的保证中间件平台的正常运行，以保证请求消息的响应速率。

已分发给处理节点的请求消息由分发标识进行指示。当在指定时间内未接收到所述处理结果时，所述方法还包括：若所述及时结果表明在指定时间内未接收到所述处理结果，清除所述请求消息对应的分发标识。这样的话，在步骤S120中将会将对应的请求消息视为未分发过的请求消息，重新进行分发。这里的删除所述分发标识，可包括更改所述分发标识对应的标识位的内容，或将请求消息从第二队列变更存储到第一队列等操作。总之，这里的删除所述分发标识，实质上去除标识对应的请求消息为已分发消息的标识信息。

进一步地，所述步骤S120可包括：采用轮询机制将所述请求消息分发给所述处理节点。在本实施例中可采用轮询机制来分发所述请求消息。例如，在该中间件平台中包括M个处理节点，分发节点可以依次向每一个节点分发请求消息，若第一时刻向处理节点A分发了一个请求消息，则在第一时刻的下一时刻向处理节点A以外的处理节点B分发请求消息，这样可以避免所有请求消息都分发到一个处理节点上，导致的负载不均衡、有的请求消息迟迟得不到响应，有的处理节点的处理资源得不到充分利用的现象。这里的轮询机制即为前述的分发策略的一种，当然在具体实现时，所述分发策略不仅限于伦旭机制等上述实施例提到的策略。

总之，本实施例提供了一种中间件消息处理方法，该中间件消息处理方法是一种异步处理方法，接收到用户请求之后，将请求消息存储在消息队列中，通过请求消息的分发等处理，减少请求消息的丢弃导致的请求无法响应及响应成功率低的现象；同时可通过分发策略的引入，实现处理节点的负载均衡。

实施例二：

如图3所示，本实施例提供一种中间件消息处理装置，所述装置包括：

存储单元110，用于将请求消息存储在消息队列中；

分发单元120，用于将请求消息分发给处理节点进行处理；

接收单元130，用于接收所述处理节点返回的处理结果；

所述存储单元110，还用于在接收到处理结果后，根据所述处理结果删除消息队列中的所述请求消息。

本实施例所述中间件消息处理装置可为各种运行在请求消息响应的服务器上的装盒子。所述存储单元110可对应于存储介质，能够利用消息队列存储请求消息。

所述分发单元120可对应于处理器或处理电路及通信接口，所述处理器可包括中央处理器、微处理器、数字信号处理器或可编程阵列等，能够利用通信接口将请求消息分发给对应的处理节点。所述接收单元130同样可对应于通信接口，能够接收处理节点返回的处理结果。这里的处理接口可以以消息的形式存储。所述分发到哪元120和接收单元120对应的通信接口，可为一个电子设备，如服务器内部的通信接口，例如数据总线等。所述存储单元110将会在接收到处理结果之后，并根据处理结果来删除所述请求消息，可以避免现有技术中请求消息被处理节点丢弃就导致整个中间件平台中就不再有请求消息的现象，能够减少请求消息不能响应的现象，提升请求消息的响应成功率。

进一步地，所述装置还包括：

形成单元，用于在将所述请求消息分发给处理节点后，形成分发标识；所述分发标识用于指示所述请求消息的分发状态；

所述分发单元120，具体用于根据所述分发标识，将未分发给处理节点的所述请求消息分发给所述处理节点。

所述形成单元可对应于各种处理器或处理电路，能够生成所述分发标识，这里的分发标识用于指示请求消息的分发状态。这里的分发状态包括已分发和未分发。为了避免重复分发和重复响应，所述分发单元120将根据所述分发标识，将未分发的请求消息发送给处理节点。

进一步地，所述装置还包括：

计时单元，用于在将所述请求消息分发给处理节点之后，启动计时形成计时结果；

所述分发单元120，具体用于若所述计时结果表明在指定时间内未接收到所述处理结果，则将所述请求消息重新分发给所述处理节点。

这里的计时单元可对应于计时器，当一个请求消息分发之后，将启动计时形成计时结果，这里的计时结果包括已分发时间。所述分发单元120将在计时结果表明一个请求消息的已分发时间达到指定时间的时间长度时，还未收到处理结果，将会重新分发该请求消息，以提高请求消息的响应成功率且降低响应时延。

进一步地，已分发给处理节点的请求消息由分发标识进行指示；所述形成单元，还用于若所述及时结果表明在指定时间内未接收到所述处理结果，清除所述请求消息对应的分发标识。在本实施例中所述形成单元还用于清除所述分发标识，这样需要重新分发的请求消息的分发标识清除之后，将会被视为未分发的请求消息重新分发，具有重新分发实现简便的特点。

可选地，所述分发单元120，具体用于采用轮询机制将所述请求消息分发给所述处理节点。

所述分发单元120可根据各种分发策略进行请求消息的分发，所述分发策略可为预先存储在所述分发单元中的，也可以是根据当前的分发负载及分发策略的形成机制形成的，总之在本实施例中所述分发策略可包括轮询机制。所述分发单元120采用轮询机制分发所述请求消息，可以确保每一个处理节点都接收到请求消息，同时也能够实现处理节点的处理均衡。

本实施例所述中间件消息处理装置，能够用于为实施例一所述中间件消息处理方法提供实现硬件，具有请求消息响应成功率高的特点。

实施例三：

如图4所示，本实施例提供一种中间件平台，所述系统包括分发节点MR和处理节点MP：

所述处理节点MP，用于对请求消息进行处理，形成处理结果；

分发节点MR，用于将请求消息存储在消息队列中，将所述消息队列中的请求消息分发给所述处理节点，接收所述处理节点返回的的处理结果；根据所述处理结果删除所述消息队列中的所述请求消息。

在本实施例所述的中间件平台中包括了分发节点MR和处理节点MP。这里的分发节点MR和处理节点MP可以通过消息总线连接。所述分发节点将从客户端接收用户请求，将用户请求转化成中间件内部消息格式的请求消息存储在消息队列中，向各个处理节点分发请求消息，接收处理节点返回的处理结果，根据处理结果来删除所述请求消息，从而可以避免处理节点丢弃请求消息，导致中间件平台中再也没有该请求消息造成的请求消息不能响应或不能及时响应的现象。

在本实施例中所述处理节点可包括实施例二中所述的中间件消息处理装置，能够在指定时间内未接收到处理结果时，重新分发请求消息，将根据轮询机制等分发策略进行请求消息的分发处理等。

总之本实施例所述的中间平台中引入了分发节点，该分发节点与中间件平台中的至少1个处理节点通过消息通道进行连接，进行请求消息的存储、分发和删除处理，避免请求消息被丢弃导致的无法响应的现象。在具体的实现过程中，所述分发节点可以采用NIO缓存机制存储并处理所述请求消息，以尽可能减少因分发节点导致的响应延时。

当然本实施例所述的分发节点MR和处理节点MP都可为设置在服务器上的逻辑节点。

值得注意的是在图4中显示有3个处理节点，但是在实际中间件平台中包括的处理节点不局限于3个，可能是1个、2个或4个等个数。

以下结合具体实施例提供一个具体示例：

本示例提供一种中间件消息处理方法，包括：

第一步：客户端发起消息请求，如浏览器访问或者是接口调用等请求。

第二步：客户端发起请求后，ClusterGap接收到用户请求，将用户请求数据转化为内部消息格式的请求消息，将请求消息存储与ClusterGap的消息队列中，等待业务任务消费该队列中的数据。这里的ClusterGap为本示例提供的中间件平台的名称。通常一个请求消息可能对应有多个处理任务。

第三步：各业务任务获取消息队列中的数据(这里的数据即对应着所述请求消息中的数据)，进行对应的业务处理。在处理结束后，将向消息队列返回一个消息，该消息至少包括处理结果。这样的话，其他处理节点会处理该请求消息中的其他业务任务了。

第四步：在该请求消息对应的所有任务处理结束后，基于处理结果形成响应消息，这里的响应消息可包括基于超文本连接http响应消息。

第五步：将该响应消息发送给客户端，这样的客户端收到浏览器访问结果或接口调用结果。

总之，请求消息在进入ClusterGap，缓存于消息队列，任务进程(对应于前述的处理节点)通过轮询机制，获取队列中的请求消息，在处理结束后将处理结果消息再转入消息队列，再由其他的任务进程获取该请求消息的其他业务任务进行处理，从而实现请求消息的异步处理和处理，并利用NIO缓存机制缓存所述请求消息以提高请求消息的处理性能。

图5所示的为本示例提供的中间件平台ClusterGap，包括管理中心及服务器，在图5中显示有服务器1、服务器2及服务器3，在具体实现时，服务器的个数可以更多，不局限于上述个数。前述的分发节点和处理节点可为设置在每一个服务器上的逻辑节点。所述管理中心对每一个服务器进行管理。这里的服务器提供各种中间件服务。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元，即可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本发明各实施例中的各功能单元可以全部集成在一个处理模块中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (11)

1.一种中间件消息处理方法，其特征在于，所述方法包括：

将请求消息存储在消息队列中；

将请求消息分发给处理节点进行处理；

接收所述处理节点返回的处理结果；

在接收到处理结果后，根据所述处理结果删除消息队列中的所述请求消息。

2.根据权利要求1所述的方法，其特征在于，

所述方法还包括：

在将所述请求消息分发给处理节点后，形成分发标识；所述分发标识用于指示所述请求消息的分发状态

所述将请求消息分发给处理节点进行处理，包括：

根据所述分发标识，将未分发给处理节点的所述请求消息分发给所述处理节点。

3.根据权利要求1或2所述的方法，其特征在于，

所述方法还包括：

在将所述请求消息分发给处理节点之后，启动计时形成计时结果；

所述将请求消息分发给处理节点进行处理，包括：

若所述计时结果表明在指定时间内未接收到所述处理结果，则将所述请求消息重新分发给所述处理节点。

4.根据权利要求3所述的方法，其特征在于，

已分发给处理节点的请求消息由分发标识进行指示；

所述方法还包括：

若所述及时结果表明在指定时间内未接收到所述处理结果，清除所述请求消息对应的分发标识。

5.根据权利要求1或2所述的方法，其特征在于，

所述将请求消息分发给处理节点进行处理，包括：

采用轮询机制将所述请求消息分发给所述处理节点。

6.一种中间件消息处理装置，其特征在于，所述装置包括：

存储单元，用于将请求消息存储在消息队列中；

分发单元，用于将请求消息分发给处理节点进行处理；

接收单元，用于接收所述处理节点返回的处理结果；

所述存储单元，还用于在接收到处理结果后，根据所述处理结果删除消息队列中的所述请求消息。

7.根据权利要求6所述的装置，其特征在于，

所述装置还包括：

形成单元，用于在将所述请求消息分发给处理节点后，形成分发标识；所述分发标识用于指示所述请求消息的分发状态

所述分发单元，具体用于根据所述分发标识，将未分发给处理节点的所述请求消息分发给所述处理节点。

8.根据权利要求7或8所述的装置，其特征在于，

所述装置还包括：

计时单元，用于在将所述请求消息分发给处理节点之后，启动计时形成计时结果；

所述分发单元，具体用于若所述计时结果表明在指定时间内未接收到所述处理结果，则将所述请求消息重新分发给所述处理节点。

9.根据权利要求8所述的装置，其特征在于，

已分发给处理节点的请求消息由分发标识进行指示；

所述形成单元，还用于若所述及时结果表明在指定时间内未接收到所述处理结果，清除所述请求消息对应的分发标识。

10.根据权利要求6或7所述的装置，其特征在于，

所述分发单元，具体用于采用轮询机制将所述请求消息分发给所述处理节点。

11.一种中间件平台，其特征在于，所述系统包括分发节点和处理节点：

所述处理节点，用于对请求消息进行处理，形成处理结果；

分发节点，用于将请求消息存储在消息队列中，将所述消息队列中的请求消息分发给所述处理节点，接收所述处理节点返回的的处理结果；根据所述处理结果删除所述消息队列中的所述请求消息。