基于消息中间件的请求处理方法和装置

摘要

本发明公开了一种基于消息中间件的请求处理方法和装置，涉及计算机技术领域。该请求处理方法的一具体实施方式包括：根据客户端发送的请求报文，查询业务数据库中是否存在与所述请求报文相关的业务数据；若业务数据库中存在与所述请求报文相关的业务数据，则向所述客户端发送响应报文，所述响应报文携带有所述业务数据；否则，将所述请求报文加入消息队列中。该实施方式通过引入消息中间件，减少了服务端轮询数据库的无效开销，节省了网络流量，可以避免客户端轮询服务端带来的运维压力以及服务端因长轮询连接请求挂起导致的资源浪费。

说明书

技术领域

本发明涉及计算机技术领域，尤其涉及一种基于消息中间件的请求处理方法和装置。

背景技术

随着互联网、分布式、组件化等信息系统构架的发展，系统之间交互也越来越多。不同系统进行交互时，多采用长轮询或短轮询方式来处理请求。其中在短轮询场景下，服务端一般会即时响应请求。在长轮询场景下，服务端在一定时间内(设定的超时时间)通过轮询业务数据库或第三方以便于及时地获取业务数据。但是，以上方式均会造成轮询数据库的无效开销，浪费网络流量。

发明内容

有鉴于此，本发明实施例提供一种基于消息中间件的请求处理方法和装置，能够解决现有请求处理方式所存在的轮询数据库无效开销问题。

为实现上述目的，根据本发明实施例的一个方面，提供了一种基于消息中间件的请求处理方法。

本发明实施例的基于消息中间件的请求处理方法包括：

根据客户端发送的请求报文，查询业务数据库中是否存在与所述请求报文相关的业务数据；

若业务数据库中存在与所述请求报文相关的业务数据，则向所述客户端发送响应报文，所述响应报文携带有所述业务数据；

否则，将所述请求报文加入消息队列中。

可选地，所述请求报文至少包括：请求数据域和公共域；其中所述请求数据域用于指示每次请求的请求报文的请求信息，所述公共域用于指示服务框架控制信息。

可选地，根据客户端发送的请求报文，查询业务数据库中是否存在与所述请求报文相关的业务数据包括：

从客户端发送的请求报文中获取请求信息；

根据获取到的请求信息，查询业务数据库中是否存在与所述请求报文相关的业务数据。

可选地，所述请求信息至少包括：渠道代码；将所述请求报文加入消息队列中包括：

从所述请求信息中获取渠道代码；其中所述渠道代码用于表示渠道的标识信息，每个渠道对应设置有一个消息队列；

将所述请求报文按照所述渠道代码加入对应的消息队列中。

可选地，所述公共域至少包括以下一项或多项信息：全局跟踪号、服务编码、服务版本号和报文加密信息。

可选地，从客户端发送的请求报文中获取请求信息包括：

从所述请求报文的公共域中获取报文加密信息；

根据所述报文加密信息，对所述请求报文进行解密处理；

从解密后的请求报文的请求数据域中获取请求信息。

可选地，所述消息队列的设计参数包括：

每个渠道对应设置有一个消息队列；

渠道代码为路由关键字；

业务数据处理程序为生产者；

请求处理程序为消费者；

超时时间。

可选地，在将所述请求报文加入消息队列中的步骤之后，所述方法还包括：

判断是否在预设的超时时间内产生所述业务数据；

若是，则将所述业务数据保存至所述业务数据库中并更新预设的业务表；将所述业务数据按照预设格式包装后发送给消息队列后发送给消息队列；

否则，向客户端返回超时报文，所述超时报文用于表示所述请求报文等待超时。

可选地，所述业务表包括以下一项或多项信息：业务类型、渠道代码、渠道名称、业务数据、处理状态和处理结果。

为实现上述目的，根据本发明实施例的另一个方面，提供了一种基于消息中间件的请求处理装置。

本发明实施例的基于消息中间件的请求处理装置包括：

查询模块，用于根据客户端发送的请求报文，查询业务数据库中是否存在与所述请求报文相关的业务数据；

发送模块，用于若业务数据库中存在与所述请求报文相关的业务数据，则向所述客户端发送响应报文，所述响应报文携带有所述业务数据；

消息队列模块，用于否则，将所述请求报文加入消息队列中。

为实现上述目的，根据本发明实施例的另一个方面，提供了一种服务端。

本发明实施例的服务端包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如上所述的方法。

为实现上述目的，根据本发明实施例的另一个方面，提供了一种计算机可读介质。

本发明实施例的计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现如上所述的方法。

上述发明中的一个实施例具有如下优点或有益效果：

在本发明实施例中，通过引入消息中间件，减少了服务端轮询数据库的无效开销，节省了网络流量，可以避免客户端轮询服务端带来的运维压力以及服务端因长轮询连接请求挂起导致的资源浪费。

上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。

附图说明

附图用于更好地理解本发明，不构成对本发明的不当限定。其中：

图1是本发明第一实施例的基于消息中间件的请求处理方法的流程示意图；

图2是本发明第二实施例的基于消息中间件的请求处理方法的流程示意图；

图3是本发明实施例的基于消息中间件的请求处理装置的模块示意图；

图4是本发明实施例可以应用于其中的示例性系统架构图；

图5是适于用来实现本发明实施例的客户端设备或服务端的计算机系统的结构示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

一般地，为了提升客户体验，满足业务准实时处理需求，客户端可以通过短轮询方式和服务端交互，获取服务端待处理的业务数据。如果服务端未查询到相关的数据，将会立即返回响应。但是，在大量的客户端并发请求时，一方面由于业务量小造成了大量网络及计算资源的浪费，另一方面也因此对应用服务端系统的稳定性和可维护性造成影响。

可以理解的是，短轮询情况下，由于系统产生的业务量并不大，大量的客户端并不会轮询到需要处理的业务数据，大部分时间处于一种空转的状态，消耗了网络和服务端资源，也影响应用系统稳定性。

另外，服务端在处理请求时，为了降低客户端频繁轮询带来的压力，可以采用长轮询处理请求。即将请求挂起一定时间，如果挂起时间内接收或产生了相关业务数据，则通过查询返回响应。此时，如果有业务数据才会立即返回结果，而没有的话，则不会再立即给客户端返回结果，直到超时为止。这样一来，客户端的请求次数将会大量减少。这就意味着节省了网络流量，毕竟每次发请求，都会占用客户端的上传流量和服务端的下载流量，而且也解决了服务端一直疲于接受请求的窘境。由于长轮询会把请求挂起同样会导致资源的浪费。假设有100个客户端请求，服务端很有可能需要挂着100个线程，在不停轮询数据库，会造成资源浪费。

为了解决以上问题，可以在服务端处理请求时，通过使用业务数据库和消息中间件的消息队列，同步查询和异步接收相结合获取业务数据。该实施方式可以满足业务时效性需要，同时节约服务端的计算资源，可以提高服务端的处理能力和服务稳定性。

基于以上分析，本发明实施例提供了一种基于消息中间件的请求处理方法，该方法可以在服务端引入消息中间件，通过消息队列间接响应请求，可以节省服务端的计算资源，也可以提升服务端的并发请求处理效果。图1是本发明实施例的基于消息中间件的请求处理方法的流程示意图，如图1所示，该请求处理方法包括如下的步骤S101至步骤S103。

步骤S101：根据客户端发送的请求报文，查询业务数据库中是否存在与所述请求报文相关的业务数据。

在步骤S101之前，服务端接收客户端发送的通讯请求，所述通信请求中携带有请求报文，所述请求报文至少包括：请求数据域和公共域；其中所述请求数据域用于指示每次请求的请求报文的请求信息，所述公共域用于指示服务框架控制信息。进一步地，所述公共域至少包括以下一项或多项信息：全局跟踪号、服务编码、服务版本号和报文加密信息。其中，请求报文示例如下：

{

"data":{

"ChannelId":"03"

"CustId":""

"ProductId":""

"AccountNo":""

},

"com":{

"version":"1.0","globalReqNumber":"uuid",

"txCode":"queryBizInf",

"sysIsEncrypted":"0",

"sysEncryptType":""

}

}

需要说明的是，所述请求报文是客户端采用http/https协议发送给服务端的，其中http(Hyper Text Transfer Protocol，超文件传输协定)/https(Hypertext TransferProtocol Secure，超文本传输安全协议)协议为网络传输协议。所述客户端可以通过GET方法向服务端发送所述请求报文，其中Get方法是指在客户端通过URL(Uniform ResourceLocator，统一资源定位符)提交数据。所述请求报文可以为JSON格式，且可以采用UTF-8字符集格式的BASE64编码编译。其中UTF-8是一种用于将宽字符值转换为字节流的统一码的标准机制。BASE64编码是一种用于传输8Bit字节代码的编码方式。

在步骤S101中，在服务端接收到客户端发送的请求报文之后，首先可以从所述请求报文中获取请求信息，所述请求信息可以理解为每次请求的具体参数。然后根据获取到的请求信息，查询业务数据库中是否存在与所述请求报文相关的业务数据。

为了查询所述业务数据库中是否存在与所述请求报文相关的业务数据，可以首先从客户端发送的请求报文中获取请求信息。然后再根据获取到的请求信息，查询业务数据库中是否存在与所述请求报文相关的业务数据。具体地，在获取请求信息时可以首先从所述请求报文的公共域中获取报文加密信息。然后根据所述报文加密信息，对所述请求报文进行解密处理。最终从解密后的请求报文的请求数据域中获取请求信息。

步骤S102：若业务数据库中存在与所述请求报文相关的业务数据，则向所述客户端发送响应报文，所述响应报文携带有所述业务数据。

在步骤S102中，所述响应报文除了携带有业务数据，所述响应报文还携带有请求数据域和公共域等。例如：渠道代码、全局跟踪号、服务编码、服务版本号和报文加密信息等。其中响应报文的格式示例：

步骤S103：若业务数据库中未存在与所述请求报文相关的业务数据，将所述请求报文加入消息队列中。

步骤S103中，所述请求信息是指与客户端的通讯请求相关的信息，所述请求信息至少包括：渠道代码。在将所述请求报文加入消息队列时，可以从所述请求信息中获取渠道代码；其中所述渠道代码用于表示渠道的标识信息，每个渠道对应设置有一个消息队列。再将所述请求报文按照所述渠道代码加入对应的消息队列中。

需要说明的是，所述消息队列的设计参数包括：

1)每个渠道对应设置有一个消息队列，例如：渠道为Q001-Q010；

2)渠道代码(ChannelId)为路由关键字(RouteKey)；

3)业务数据处理程序为生产者(Producer)；

4)请求处理程序为消费者(Consumer)；

5)超时时间，例如：TTL＝30s。

在步骤S103之后，为了解决消息积压的问题，所述方法还包括：判断是否在预设的超时时间内产生所述业务数据；若是，则将所述业务数据保存至所述业务数据库中并更新预设的业务表；将所述业务数据按照预设格式包装后发送给消息队列；否则，向客户端返回超时报文，所述超时报文用于表示所述请求报文等待超时。其中，所述业务表包括以下一项或多项信息：业务类型、渠道代码、渠道名称、业务数据、处理状态和处理结果等。通过业务表的数据结构和消息队列可以做到数据精准投递并消费，使得请求处理更加高效。

可以理解的是，客户端首次请求查询业务数据库，若在业务数据库中有该客户端所请求的业务数据，则向客户端返回该业务数据；否则，将该客户端的请求加入请求消息队列等待。若在响应设定的超时时间内，服务端产生了相关的业务数据时，同步更新业务数据库及消息队列。此时，请求从消息队列获取业务数据，并更新业务数据库，之后将业务数据返回给客户端。如超时业务数据库没有对应的业务数据，则亦直接返回。即通过设置合理的请求等待时间，客户端每次轮询请求获取到有效业务数据的概率大幅增加，很好地提升了业务响应和操作体验。

在根据业务数据更新业务数据库时，可以将服务端接收或产生的业务数据储存至该业务表。该业务表包括以下一项或多项信息：业务类型、渠道代码、渠道名称、业务数据、处理状态和处理结果等。其中业务类型可以由两位数字构成的代码组成；渠道代码(ChannelId)可以由三位数字构成的代码，001开始表示该业务要发往的渠道；渠道名称为字符串；业务数据有JSON格式的字符串构成，业务数据包括与渠道端约定的数据项及数据信息。处理状态用于表示该条业务信息处理的状态，两位数字代码组成，00-未处理，01-已消费，02-已处理。处理结果用于保存最新处理情况。

在本发明实施例中，在客户端的请求接入后，服务端的业务处理逻辑不是先走消息服务装置，而是先走业务处理装置查询业务数据库是否存在待处理业务数据。若存在，则直接返回，不再进入消息队列；若不存，才会进入消息队列等待。消息服务装置作为业务处理的后置逻辑，业务处理装置在前，消息服务装置在后。

上述实施方式通过引入消息中间件，减少了服务端轮询数据库的无效开销，节省了网络流量，可以避免客户端轮询服务端带来的运维压力以及服务端因长轮询连接请求挂起导致的资源浪费。

可以理解的是，上述实施方式解决了分布式和互联网环境下应用服务端因大量客户端http轮询请求所导致的连接资源不够用的问题，也解决了长轮询情况下业务时效性以及客户操作体验不佳的问题。通过上述实施例方式，既可以大幅节约应用和数据库服务端资源，又可以提升业务时效性和客户操作体验。

图2是本发明第二实施例的基于消息中间件的请求处理方法的流程示意图，参见图2，该请求处理方法可以包括如下的步骤S201至步骤S205。

步骤S201：客户端向服务端发送请求报文。

在步骤S201中，客户端组包并发送通讯请求，通讯请求中携带有请求报文。所述请求报文可以采用JSON格式，所述请求报文至少包括：请求数据域和公共域；其中所述请求数据域用于指示每次请求的请求报文的请求信息，例如：请求数据域明文为每次请求的具体参数。所述公共域用于指示服务框架控制信息，服务框架控制信息与业务无关、如全局跟踪号、服务编码、服务版本号和报文加密信息等。

进一步地，客户端可以采用http/https协议，并且可以通过GET方法发起通讯请求。http通讯的请求报文可以采用UTF-8字符集格式的BASE64编码编译。

步骤S202：服务端收到请求报文，根据所述请求报文中的发起渠道查询业务数据库。

在步骤S202中，请求处理模块收到请求报文后，首先根据请求报文的公共域中的报文加解密标识，判断是否需要解密处理；然后从解密后的请求报文的请求数据域中获取渠道标识(ChannelId)等请求信息，根据请求信息查询业务数据库。当在业务数据库中没有查询到业务数据时，将请求报文加入待处理消息请求队列等待。

步骤S203：判断业务数据库中是否存在该渠道对应的待处理业务数据。若存在，则执行步骤S204；否则，执行步骤S205。

可以理解的是，服务端接到客户端请求报文后，根据渠道代码查询本渠道是否有00-未处理的业务数据。如在业务数据库中存在该渠道未处理的业务数据，则将业务数据发送给客户端并更新处理状态为01-已消费；如在业务数据库中不存在该渠道未处理的业务数据，则进入对应的消息队列等待。

步骤S204：服务端向客户端返回待处理的业务数据，并更新业务数据库。

在根据业务数据更新业务数据库时，可以将服务端接收或产生的业务数据储存至该业务表。该业务表包括以下一项或多项信息：业务类型、渠道代码、渠道名称、业务数据、处理状态和处理结果等。其中业务类型可以由两位数字构成的代码组成；渠道代码(ChannelId)可以由三位数字构成的代码，001开始表示该业务要发往的渠道；渠道名称为字符串；业务数据有JSON格式的字符串构成，业务数据包括与渠道端约定的数据项及数据信息。处理状态用于表示该条业务信息处理的状态，两位数字代码组成，00-未处理，01-已消费，02-已处理。处理结果用于保存最新处理情况。

步骤S205：将请求报文加入消息队列。

需要说明的是，所述消息队列的设计参数包括：

1)每个渠道对应设置有一个消息队列，例如：渠道为Q001-Q010；

2)渠道代码(ChannelId)为路由关键字(RouteKey)；

3)业务数据处理程序为生产者(Producer)；

4)请求处理程序为消费者(Consumer)；

5)超时时间，例如：TTL＝30s。

在步骤S205中，在将所述请求报文加入消息队列时，可以从所述请求信息中获取渠道代码；其中所述渠道代码用于表示渠道的标识信息，每个渠道对应设置有一个消息队列。再将所述请求报文按照所述渠道代码加入对应的消息队列中。

在上述实施方式的基础上，且在步骤S205之后，该请求处理方法还包括：接收到后端产生的待处理的业务数据后，将业务数据存储业务数据库中并更新业务表，然后根据业务数据按照预设的格式包装后发送给消息队列。也就是说，若服务端产生业务数据后，可以将业务数据插入业务数据库并设置处理状态为00-未处理；同时，通过指定的路由关键字，将业务消息发送到消息对应的消息队列。

除此之外，为了解决消息积压的问题，所述方法还包括：判断是否在预设的超时时间内产生所述业务数据；若是，则将所述业务数据保存至所述业务数据库中并更新预设的业务表；将所述业务数据按照预设格式包装后发送给消息队列后发送给消息队列；否则，向客户端返回超时报文，所述超时报文用于表示所述请求报文等待超时。其中，所述业务表包括以下一项或多项信息：业务类型、渠道代码、渠道名称、业务数据、处理状态和处理结果。通过业务表的数据结构和消息队列可以做到数据精准投递并消费，使得请求处理更加高效。

例如：可以将超时时间设置为30s。也就是说，若等待的30s内获取到业务数据，则拉取业务数据，并更新业务数据库业务表的处理状态为01-已消费；若超过30s没有接收到业务数据，则向客户端返回响应超时报文。这样消息队列的消息超过设置的失效时间30s未被消费，则消息失效，来解决消息积压问题。

在本发明实施例中，在客户端的请求接入后，服务端的业务处理逻辑不是先走消息服务装置，而是先走业务处理装置查询业务数据库是否存在待处理业务数据。若存在，则直接返回，不再进入消息队列；若不存，才会进入消息队列等待。消息服务装置作为业务处理的后置逻辑，业务处理装置在前，消息服务装置在后。

上述实施方式通过引入消息中间件，减少了服务端轮询数据库的无效开销，节省了网络流量，可以避免客户端轮询服务端带来的运维压力以及服务端因长轮询连接请求挂起导致的资源浪费。

可以理解的是，上述实施方式解决了分布式和互联网环境下应用服务端因大量客户端http轮询请求所导致的连接资源不够用的问题，也解决了长轮询情况下业务时效性以及客户操作体验不佳的问题。通过上述实施例方式，既可以大幅节约应用和数据库服务端资源，又可以提升业务时效性和客户操作体验。另外，通过设置合理的请求等待时间，客户端每次轮询请求获取到有效业务数据的概率大幅增加，很好地提升了业务响应和操作体验。

图3是本发明实施例的基于消息中间件的请求处理装置的模块示意图，参见图3，该基于消息中间件的请求处理装置300包括如下模块：

查询模块301，用于根据客户端发送的请求报文，查询业务数据库中是否存在与所述请求报文相关的业务数据；

发送模块302，用于若业务数据库中存在与所述请求报文相关的业务数据，则向所述客户端发送响应报文，所述响应报文携带有所述业务数据；

消息队列模块303，用于否则，将所述请求报文加入消息队列中。

可选地，所述请求报文至少包括：请求数据域和公共域；其中所述请求数据域用于指示每次请求的请求报文的请求信息，所述公共域用于指示服务框架控制信息。

可选地，所述查询模块301进一步用于：

从客户端发送的请求报文中获取请求信息；

根据获取到的请求信息，查询业务数据库中是否存在与所述请求报文相关的业务数据。

可选地，所述请求信息至少包括：渠道代码；所述消息队列模块303进一步用于：

从所述请求信息中获取渠道代码；其中所述渠道代码用于表示渠道的标识信息，每个渠道对应设置有一个消息队列；

将所述请求报文按照所述渠道代码加入对应的消息队列中。

可选地，所述公共域至少包括以下一项或多项信息：全局跟踪号、服务编码、服务版本号和报文加密信息。

可选地，所述查询模块301进一步用于：

从所述请求报文的公共域中获取报文加密信息；

根据所述报文加密信息，对所述请求报文进行解密处理；

从解密后的请求报文的请求数据域中获取请求信息。

可选地，所述消息队列的设计参数包括：

1)每个渠道对应设置有一个消息队列；

2)渠道代码为路由关键字；

3)业务数据处理程序为生产者；

4)请求处理程序为消费者；

5)超时时间。

可选地，该基于消息中间件的请求处理装置还包括：

判断模块，用于判断是否在预设的超时时间内产生所述业务数据；

第一执行模块，用于若是，则将所述业务数据保存至所述业务数据库中并更新预设的业务表；将所述业务数据按照预设格式包装后发送给消息队列后发送给消息队列；

第二执行模块，用于否则，向客户端返回超时报文，所述超时报文用于表示所述请求报文等待超时。

可选地，所述业务表包括以下一项或多项信息：业务类型、渠道代码、渠道名称、业务数据、处理状态和处理结果。

在本发明实施例中，通过引入消息中间件，减少了服务端轮询数据库的无效开销，节省了网络流量，可以避免客户端轮询服务端带来的运维压力以及服务端因长轮询连接请求挂起导致的资源浪费。

可以理解的是，上述实施方式解决了分布式和互联网环境下应用服务端因大量客户端http轮询请求所导致的连接资源不够用的问题，也解决了长轮询情况下业务时效性以及客户操作体验不佳的问题。通过上述实施例方式，既可以大幅节约应用和数据库服务端资源，又可以提升业务时效性和客户操作体验。

图4示出了可以应用本发明实施例的基于消息中间件的请求处理方法或基于消息中间件的请求处理装置的示例性系统架构400。

如图4所示，系统架构400可以包括客户端设备401、402、403，网络404和服务端405。网络404用以在客户端设备401、402、403和服务端405之间提供通信链路的介质。网络404可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用客户端设备401、402、403通过网络404与服务端405交互，以接收或发送消息等。客户端设备401、402、403上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。

客户端设备401、402、403可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。服务端405可以是提供各种服务的服务端。

需要说明的是，本发明实施例所提供的基于消息中间件的请求处理方法一般由服务端405执行，相应地，基于消息中间件的请求处理装置一般设置于服务端405中。

应该理解，图4中的客户端设备、网络和服务端的数目仅仅是示意性的。根据实现需要，可以具有任意数目的客户端设备、网络和服务端。

下面参考图5，其示出了适于用来实现本发明实施例的客户端设备的计算机系统500的结构示意图。图5示出的客户端设备仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图5所示，计算机系统500包括中央处理单元(CPU)501，其可以根据存储在只读存储器(ROM)502中的程序或者从存储部分508加载到随机访问存储器(RAM)503中的程序而执行各种适当的动作和处理。在RAM 503中，还存储有系统500操作所需的各种程序和数据。CPU 501、ROM 502以及RAM 503通过总线504彼此相连。输入/输出(I/O)接口505也连接至总线504。

以下部件连接至I/O接口505：包括键盘、鼠标等的输入部分506；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分507；包括硬盘等的存储部分508；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分509。通信部分509经由诸如因特网的网络执行通信处理。驱动器510也根据需要连接至I/O接口505。可拆卸介质511，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器510上，以便于从其上读出的计算机程序根据需要被安装入存储部分508。

特别地，根据本发明公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分509从网络上被下载和安装，和/或从可拆卸介质511被安装。在该计算机程序被中央处理单元(CPU)501执行时，执行本发明的系统中限定的上述功能。

需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：根据客户端发送的请求报文，查询业务数据库中是否存在与所述请求报文相关的业务数据；若业务数据库中存在与所述请求报文相关的业务数据，则向所述客户端发送响应报文，所述响应报文携带有所述业务数据；否则，将所述请求报文加入消息队列中。

在本发明实施例中，通过引入消息中间件，减少了服务端轮询数据库的无效开销，节省了网络流量，可以避免客户端轮询服务端带来的运维压力以及服务端因长轮询连接请求挂起导致的资源浪费。

可以理解的是，上述实施方式解决了分布式和互联网环境下应用服务端因大量客户端http轮询请求所导致的连接资源不够用的问题，也解决了长轮询情况下业务时效性以及客户操作体验不佳的问题。通过上述实施例方式，既可以大幅节约应用和数据库服务端资源，又可以提升业务时效性和客户操作体验。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。