CN108009028A - 消息处理方法、装置、设备及计算机可读存储介质 - Google Patents

Abstract

本发明提供一种消息处理方法，该方法包括：在接收到客户端发送的业务消息时，对所述业务消息进行解析，以确定所述业务消息的业务类型；根据所述业务消息的业务类型查询对应的业务系统，并将所述业务消息存入所述业务系统对应的消息队列；向所述业务系统发送消息处理指令，以供所述业务系统根据所述消息处理指令从所述消息队列获取所述业务消息。本发明还提供一种消息处理装置、设备及计算机可读存储介质。本发明提出部署消息平台，客户端可与消息平台进行对接，将消息发送至该消息平台，再由该平台对处理消息转至业务系统，有效缓解了业务系统的并发压力。

Description

消息处理方法、装置、设备及计算机可读存储介质

技术领域

本发明涉及数据处理领域，尤其涉及一种消息处理方法、装置、设备及计算机可读存储介质。

背景技术

随着互联网的快速发展，客户端会与业务系统进行频繁的数据交互，而目前客户端与业务系统的数据交互往往是两者直接对接进行，客户端调用业务系统的接口向业务系统发送消息或传输数据。但是，一个网络中往往会存在多个客户端，当客户端的数量很大时，业务系统将面临较大压力。例如，客户端搜集用户行为数据时，需要调用业务系统的接口，以将搜集的数据传回到业务系统，而由于客户端的数量较多，此时业务系统就面临着较大的数据处理压力，其性能就受到了影响；如果这些发送数据还要落地(保存)到数据库中，那数据库更是无法承受该并发压力。

发明内容

本发明的主要目的在于提供一种消息处理方法、装置、设备及计算机可读存储介质，旨在解决高并发场景下业务系统处理压力大的技术问题。

为实现上述目的，本发明提供一种消息处理方法，所述消息处理方法应用于消息平台，所述消息处理方法包括以下步骤：

在接收到客户端发送的业务消息时，对所述业务消息进行解析，以确定所述业务消息的业务类型；

根据所述业务消息的业务类型查询对应的业务系统，并将所述业务消息存入所述业务系统对应的消息队列；

向所述业务系统发送消息处理指令，以供所述业务系统根据所述消息处理指令从所述消息队列获取所述业务消息。

可选地，所述业务系统至少包括两个业务端，所述消息队列至少包括两个子队列，

所述根据所述业务消息的业务类型查询对应的业务系统，并将所述业务消息存入所述业务系统对应的消息队列的步骤包括：

根据所述业务消息的业务类型查询对应的业务系统，并分别获取所述业务系统中各业务端对应的子队列的消息存放记录；

根据预设顺序轮询规则和所述消息存放记录在各子队列中确定目标子队列，并将所述业务消息存入所述目标子队列；

所述向所述业务系统发送消息处理指令，以供所述业务系统根据所述消息处理指令从所述消息队列获取所述业务消息的步骤包括：

向所述目标子队列对应的目标业务端发送消息处理指令，以供所述目标业务端根据所述消息处理指令从所述目标子队列获取所述业务消息。

可选地，所述业务系统至少包括两个业务端，所述消息队列至少包括两个子队列，

所述根据所述业务消息的业务类型查询对应的业务系统，并将所述业务消息存入所述业务系统对应的消息队列的步骤包括：

根据所述业务消息的业务类型查询对应的业务系统，并分别获取所述业务系统中各业务端对应的子队列的消息存放记录和加权因子；

根据预设加权轮询规则、所述消息存放记录和加权因子在各子队列中确定目标子队列，并将所述业务消息存入所述目标子队列；

所述向所述业务系统发送消息处理指令，以供所述业务系统根据所述消息处理指令从所述消息队列获取所述业务消息的步骤包括：

向所述目标子队列对应的目标业务端发送消息处理指令，以供所述目标业务端根据所述消息处理指令从所述目标子队列获取所述业务消息。

可选地，所述业务系统至少包括两个业务端，所述消息队列至少包括两个子队列，

所述根据所述业务消息的业务类型查询对应的业务系统，并将所述业务消息存入所述业务系统对应的消息队列的步骤包括：

根据所述业务消息的业务类型查询对应的业务系统，并分别获取所述业务系统中各业务端对应的子队列的待处理消息数；

根据预设均衡分配规则和所述待处理消息数在各子队列中确定目标子队列，并将所述业务消息存入所述目标子队列；

所述向所述业务系统发送消息处理指令，以供所述业务系统根据所述消息处理指令从所述消息队列获取所述业务消息的步骤包括：

向所述目标子队列对应的目标业务端发送消息处理指令，以供所述目标业务端根据所述消息处理指令从所述目标子队列获取所述业务消息。

可选地，所述向所述业务系统发送消息处理指令，以供所述业务系统根据所述消息处理指令从所述消息队列获取所述业务消息的步骤之后，还包括：

对所述消息队列的消息获取状况进行监控；

若在预设处理时间内未监控到所述业务系统从所述消息队列获取所述业务消息，则向备用业务系统发送二次处理指令，以供所述备用业务系统根据所述二次处理指令从所述消息队列获取所述业务消息。

可选地，所述在接收到客户端发送的业务消息时，对所述业务消息进行解析，以确定所述业务消息的业务类型的步骤包括：

在接收到客户端通过发送的业务消息时，获取所述客户端的发送路径，并对所述业务消息进行解析，以确定所述业务消息的业务类型；

所述向所述业务系统发送消息处理指令，以供所述业务系统根据所述消息处理指令从所述消息队列获取所述业务消息的步骤之后，还包括：

接收所述业务系统返回的业务结果消息，并根据所述发送路径将所述业务结果消息发送至所述客户端。

可选地，所述消息处理方法还包括：

在接收到新增业务系统发送的服务上线请求时，获取所述新增业务系统的新增业务类型信息，并创建与所述新增业务系统对应的新增消息队列。

此外，为实现上述目的，本发明还提供一种消息处理装置，所述消息处理装置包括：

类型确定模块，用于在接收到客户端发送的业务消息时，对所述业务消息进行解析，以确定所述业务消息的业务类型；

消息存入模块，用于根据所述业务消息的业务类型查询对应的业务系统，并将所述业务消息存入所述业务系统对应的消息队列；

指令发送模块，用于向所述业务系统发送消息处理指令，以供所述业务系统根据所述消息处理指令从所述消息队列获取所述业务消息。

此外，为实现上述目的，本发明还提供一种消息处理设备，所述消息处理设备包括处理器、存储器、以及存储在所述存储器上并可被所述处理器执行的消息处理程序，其中所述消息处理程序被所述处理器执行时，实现上述的消息处理方法的步骤。

此外，为实现上述目的，本发明还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有消息处理程序，其中所述消息处理程序被处理器执行时，实现如上述的消息处理方法的步骤。

本发明的消息平台在接收到客户端发送的业务消息时，对所述业务消息进行解析，以确定所述业务消息的业务类型；根据所述业务消息的业务类型查询对应的业务系统，并将所述业务消息存入所述业务系统对应的消息队列；向所述业务系统发送消息处理指令，以供所述业务系统根据所述消息处理指令从所述消息队列获取所述业务消息。通过以上方式，本发明提出部署消息平台，客户端可与消息平台进行对接，将消息发送至该消息平台，再由该平台对处理消息转至业务系统，经过了一个高并发的发送和低并发的收回后，有效缓解了业务系统的并发压力；同时消息平台还可看作是中间件，即在应对业务系统高并发压力时引入了生产者/消费者模式的处理思想，解决生产者和消费者的强耦合问题，平衡了生产者(客户端)和消费者(业务系统)的处理能力；此外，单独消息平台更有利于工作人员进行维护，能更方便的对平台进行横向扩展以适配更高的性能需求，也有利于对消息进行监控，提高业务系统的安全性。

附图说明

图1是本发明实施例方案涉及的终端硬件运行环境的终端结构示意图；

图2为本发明消息处理方法第一实施例的流程示意图；

图3为图2所示实施例涉及的消息平台架构示意图；

图4为图2所述根据所述业务消息的业务类型查询对应的业务系统，并将所述业务消息存入所述业务系统对应的消息队列的细化流程示意图；

图5为图4所示实施例涉及的消息存放示意图；

图6为图2所述根据所述业务消息的业务类型查询对应的业务系统，并将所述业务消息存入所述业务系统对应的消息队列的细化流程示意图；

图7为图6所示实施例涉及的消息存放示意图；

图8为图2所述根据所述业务消息的业务类型查询对应的业务系统，并将所述业务消息存入所述业务系统对应的消息队列的细化流程示意图；

图9为本发明消息处理方法第二实施例的流程示意图；

图10为本发明消息处理装置第一实施例的功能模块示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明消息处理方法实施例的实现终端可以是PC，也可以是智能手机、平板电脑、便携计算机等具有显示功能的可移动式终端设备。

如图1所示，图1是本发明实施例方案涉及的终端硬件运行环境的终端结构示意图。本发明实施例中，该终端可以包括处理器1001(例如CPU)，通信总线1002，用户接口1003，网络接口1004，存储器1005。其中，通信总线1002用于实现这些组件之间的连接通信；用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)；网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)；存储器1005可以是高速RAM存储器，也可以是稳定的存储器(non-volatile memory)，例如磁盘存储器，存储器1005可选的还可以是独立于前述处理器1001的存储装置。

本领域技术人员可以理解，图1中示出的硬件结构并不构成对本发明的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

继续参照图1，图1中作为一种计算机可读存储介质的存储器1005可以包括操作系统、网络通信模块以及消息处理程序。

在图1中，网络通信模块主要用于连接客户端和业务系统，分别与客户端、业务系统进行数据通信；而处理器1001可以调用存储器1005中存储的消息处理程序，并执行以下操作：

在接收到客户端发送的业务消息时，对所述业务消息进行解析，以确定所述业务消息的业务类型；

根据所述业务消息的业务类型查询对应的业务系统，并将所述业务消息存入所述业务系统对应的消息队列；

向所述业务系统发送消息处理指令，以供所述业务系统根据所述消息处理指令从所述消息队列获取所述业务消息。

进一步的，所述业务系统至少包括两个业务端，所述消息队列至少包括两个子队列，

所述根据所述业务消息的业务类型查询对应的业务系统，并将所述业务消息存入所述业务系统对应的消息队列的步骤包括：

根据所述业务消息的业务类型查询对应的业务系统，并分别获取所述业务系统中各业务端对应的子队列的消息存放记录；

根据预设顺序轮询规则和所述消息存放记录在各子队列中确定目标子队列，并将所述业务消息存入所述目标子队列；

所述向所述业务系统发送消息处理指令，以供所述业务系统根据所述消息处理指令从所述消息队列获取所述业务消息的步骤包括：

向所述目标子队列对应的目标业务端发送消息处理指令，以供所述目标业务端根据所述消息处理指令从所述目标子队列获取所述业务消息。

进一步的，所述业务系统至少包括两个业务端，所述消息队列至少包括两个子队列，

所述根据所述业务消息的业务类型查询对应的业务系统，并将所述业务消息存入所述业务系统对应的消息队列的步骤包括：

根据所述业务消息的业务类型查询对应的业务系统，并分别获取所述业务系统中各业务端对应的子队列的消息存放记录和加权因子；

根据预设加权轮询规则、所述消息存放记录和加权因子在各子队列中确定目标子队列，并将所述业务消息存入所述目标子队列；

所述向所述业务系统发送消息处理指令，以供所述业务系统根据所述消息处理指令从所述消息队列获取所述业务消息的步骤包括：

向所述目标子队列对应的目标业务端发送消息处理指令，以供所述目标业务端根据所述消息处理指令从所述目标子队列获取所述业务消息。

进一步的，所述业务系统至少包括两个业务端，所述消息队列至少包括两个子队列，

所述根据所述业务消息的业务类型查询对应的业务系统，并将所述业务消息存入所述业务系统对应的消息队列的步骤包括：

根据所述业务消息的业务类型查询对应的业务系统，并分别获取所述业务系统中各业务端对应的子队列的待处理消息数；

根据预设均衡分配规则和所述待处理消息数在各子队列中确定目标子队列，并将所述业务消息存入所述目标子队列；

所述向所述业务系统发送消息处理指令，以供所述业务系统根据所述消息处理指令从所述消息队列获取所述业务消息的步骤包括：

向所述目标子队列对应的目标业务端发送消息处理指令，以供所述目标业务端根据所述消息处理指令从所述目标子队列获取所述业务消息。

进一步的，处理器1001还可以调用存储器1005中存储的消息处理程序，并执行以下操作：

对所述消息队列的消息获取状况进行监控；

若在预设处理时间内未监控到所述业务系统从所述消息队列获取所述业务消息，则向备用业务系统发送二次处理指令，以供所述备用业务系统根据所述二次处理指令从所述消息队列获取所述业务消息。

进一步的，所述在接收到客户端发送的业务消息时，对所述业务消息进行解析，以确定所述业务消息的业务类型的步骤包括：

在接收到客户端通过发送的业务消息时，获取所述客户端的发送路径，并对所述业务消息进行解析，以确定所述业务消息的业务类型；

处理器1001还可以调用存储器1005中存储的消息处理程序，并执行以下操作：

接收所述业务系统返回的业务结果消息，并根据所述发送路径将所述业务结果消息发送至所述客户端。

进一步的，处理器1001还可以调用存储器1005中存储的消息处理程序，并执行以下操作：

在接收到新增业务系统发送的服务上线请求时，获取所述新增业务系统的新增业务类型信息，并创建与所述新增业务系统对应的新增消息队列。

基于上述的终端硬件结构，提出本发明消息处理方法的各个实施例。

本发明提供一种消息处理方法。

参照图2，图2为本发明消息处理方法第一实施例的流程示意图。

本实施例中，所述消息处理方法包括以下步骤：

步骤S10，在接收到客户端发送的业务消息时，对所述业务消息进行解析，以确定所述业务消息的业务类型；

考虑到若将业务系统直接与客户端通信连接，则在高并发场景下(例如收集用户的行为数据)业务系统可能会面临较大的业务压力。基于上述考虑，本实施例提出在业务系统和客户端之间构建一个消息平台，其不具有具体的业务处理功能，而专门负责处理客户端发送至业务系统的交互消息，以缓解了业务系统的高并发压力；同时单独的消息平台能更方便进行横向扩展，以适配更高的性能需求。

具体的，本实施中消息平台提供有客户接口(例如http接口)，客户端可通过该接口与消息平台进行对接；同时消息平台还与创建有与业务系统对应的消息队列。值得说明的是，本实施例中的消息平台中可与两个以上(“以上”包括本数，下同)的不同业务类型的业务系统对接，从而对多个类型的业务消息进行处理。本实施例中，在客户端需要向业务系统发送业务消息(或是发送交互数据)时，即调用该接口，向消息平台发送业务消息；在发送完成时，客户接口调用即完成，此时客户端并不需要等待消息平台对处理消息进行处理，这是由于当前客户端并不是直接与业务系统通信的，而因为消息平台并不具有业务处理功能，因此客户端将直接返回去进行自身的其它操作。消息平台在接收到客户端发送的业务消息时，将会对业务消息进行解析，读取其中的内容，确定该业务消息的业务类型。

进一步的，在对业务消息进行解析时，为了加快解析的速度，可以对业务消息的报文格式进行限定，要求客户端将业务消息的消息头添加消息主题(topic)；在这样的情况下，消息平台在对业务消息进行解析时，可直接访问消息头并进行解析，从而无需对整条业务消息进行处理，提高了解析的效率；在对消息头解析完成时，即可根据其中的消息主题确定业务消息的业务类型。

步骤S20，根据所述业务消息的业务类型查询对应的业务系统，并将所述业务消息存入所述业务系统对应的消息队列；

本实施例中，在确定业务消息的业务类型时，消息平台将查询内置数据库，以确定到该业务类型的业务消息是由哪一个业务系统进行消费和处理。在确定该业务消息对应的业务系统时，消息平台将该业务消息存入到与该业务系统对应的消息队列中。

步骤S30，向所述业务系统发送消息处理指令，以供所述业务系统根据所述消息处理指令从所述消息队列获取所述业务消息。

本实施例中，当有新的业务消息存入到消息队列时，消息平台将向该消息队列对应的业务系统发送消息处理指令，以通知业务系统有新的任务需要进行处理；同时消息平台还可提供相应的业务接口(例如http、tcp等)，以供业务系统调用此接口从消息平台中取走业务消息并对其进行处理。

业务系统在对业务消息处理完成时，若需要向客户端返回业务结果，也可以是通过消息平台进行。具体的，消息平台在接收到客户端发送的业务消息并对业务消息进行解析的同时，还将获取客户端的发送路径，以供后续回复业务结果时使用；然后消息平台将会把业务消息存入到消息队列中，以供业务系统获取。当业务系统获取该业务消息并处理得到业务结果时，会向消息平台返回对应的业务结果消息。消息平台在接收到该业务结果消息时，即可根据客户端发送业务消息时的发送路径，将该业务结果消息返回至客户端。当然，消息平台也可以将该发送路径添加进业务消息中，再将业务消息存入消息队列；这样业务系统在获取该业务消息并处理得到业务结果时，可根据业务消息中的发送路径，直接将业务结果消息返回至客户端，而无需通过消息平台。

本实施例中的消息平台，可采用lvs+nginx的模式，以进一步实现负载均衡，如图3所示，图3为消息平台的架构示意图；这样其对于客户端client有lvs(Linux虚拟服务器，开源)的高性能，对于服务(业务系统)又有nginx(一个高性能的HTTP和反向代理服务器，开源)的多功能，以实现更优的调度；其中lvs可与Keepalived配合使用(Keepalived是分布式部署系统解决系统高可用的软件)。具体的，客户端向消息平台发送业务消息时，消息平台中的lvs将会接收到该业务消息；此时lvs会将该业务消息发送至内核空间的PREROUTING链；PREROUTING链在接收到该业务消息时，将对该请求中的业务消息的目标IP进行确认(判断是不是由本平台对接的业务系统)；确认完成时，PREROUTING链将把该消息发送到INPUT链；INPUT链在接收到该请求时，会将该消息和已定义好的业务系统(或服务集群)进行比对，如果该请求的就是定义的业务系统，那么此时IPVS会修改请求中的数据包里的目标IP地址及端口，并将新的数据包发往POSTROUTING链；POSTROUTING链接收数据包后发现新修改的目标IP地址刚好是自己的后端消息队列，则此时通过选路(即上述消息队列的选择)。而对于选路的过程，为nginx执行，其中nginx还可以根据结合相关的负载均衡算法进行选路，以提高业务系统的处理效率。

进一步的，消息平台中的消息队列，是与业务系统对应创建的；在有新的业务系统上线时，消息平台还可新建对应的消息队列。具体的，当新增业务系统上线时，将向消息平台发送服务上线请求，该服务上线请求中包括了新增业务系统的业务类型信息，还可以包括业务设备的端口号、主机标识等信息。消息平台在接收到该服务上线请求时，将根据该新增业务类型信息创建对应的消息队列，并将该新增消息队列与新增业务系统进行关联，通过以上方式，新增业务系统就可通过消息平台接收客户端的业务消息了。

再进一步的，本实施例中的客户端和业务系统，都是可以通过接口的方式与消息平台对接的；而为了提高系统的安全性，还可以对不同的接口设置不同的权限；例如对于客户接口，仅允许客户端通过客户接口发送业务消息(或交互数据)；对于业务接口，仅允许业务系统通过业务接口获取特定消息队列的业务消息，从而实现权限控制。

在具体实施中，消息平台在接收到处理消息时，除了将消息转至业务系统外，还可以是将其直接落地(保存)到日志文件、pg库(PostgreSQL，是一个自由的对象-关系数据库服务器，或称数据库管理系统)、大数据平台kafka等，实现数据收集，通过这样的方式，还可以缓解数据库的并发压力。

本实施例中，消息平台在接收到客户端发送的业务消息时，对所述业务消息进行解析，以确定所述业务消息的业务类型；根据所述业务消息的业务类型查询对应的业务系统，并将所述业务消息存入所述业务系统对应的消息队列；向所述业务系统发送消息处理指令，以供所述业务系统根据所述消息处理指令从所述消息队列获取所述业务消息。通过以上方式，本实施例提出部署消息平台，客户端可与消息平台进行对接，将消息发送至该消息平台，再由该平台对处理消息转至业务系统，经过了一个高并发的发送和低并发的收回后，有效缓解了业务系统的并发压力；同时消息平台还可看作是中间件，即在应对业务系统高并发压力时引入了生产者/消费者模式的处理思想，解决生产者和消费者的强耦合问题，平衡了生产者(客户端)和消费者(业务系统)的处理能力；此外，单独消息平台更有利于工作人员进行维护，能更方便的对平台进行横向扩展以适配更高的性能需求，也有利于对消息进行监控，提高业务系统的安全性。

参照图4，图4为图2所述根据所述业务消息的业务类型查询对应的业务系统，并将所述业务消息存入所述业务系统对应的消息队列的细化流程示意图。

基于上述图2所示实施例，本实施例中，所述业务系统至少包括两个业务端，所述消息队列至少包括两个子队列，所述步骤S20包括：

步骤S21，根据所述业务消息的业务类型查询对应的业务系统，并分别获取所述业务系统中各业务端对应的子队列的消息存放记录；

步骤S22，根据预设顺序轮询规则和所述消息存放记录在各子队列中确定目标子队列，并将所述业务消息存入所述目标子队列。

本实施例中的业务系统，可以分布式架构业务系统，其至少包括两个处理具体业务的业务端，这些业务端可以是分布在不同的区域。消息平台为了与分布式的业务系统进行适配，对每个业务端都设置有不同的消息队列。消息在根据业务消息的业务类型确定业务消息是由哪一个业务系统进行消费和处理，还需要进一步确定由该业务系统中的哪一个业务端进行消费和处理的。本实施例中，为了实现均衡负载，可根据顺序轮询规则确定实际处理的业务端；其中顺序轮询是指将各业务端的实际处理能力和各业务消息的处理时间都看作是相同的，以轮询的方式依次将业务消息分配给不同业务端进行处理，即每次调度执行i＝(i+1)mod n。具体的，本实施例中，消息平台在确定对应的业务系统时，将会查询该业务系统的各个业务端对应子队列的消息存放记录，然后根据消息存放记录确定本次要存入的目标子队列(即确定目标业务端)，并将该业务消息存入到目标子队列。例如，业务系统中有A、B、C三个业务端，所对应的子队列依次为a、b、c，其顺序编号为1a、2b、3c；那么，在接收到业务消息时，应该是以“1a、2b、3c、1a、2b、3c...”这样的方式将业务消息存入到对应的子队列中；在接收到第i条业务消息时，消息平台将获取3条子队列的消息存放记录，确定上一条i-1消息是存入了3c子队列，则此时的目标子队列为1a(消息存放示意图可参见图5)；消息平台则将新业务消息存入到1a子队列中，并向1a子队列对应的A业务端发送消息处理指令，以供A业务端根据所述消息处理指令1a子队列获取该业务消息。

参照图6，图6为图2所述根据所述业务消息的业务类型查询对应的业务系统，并将所述业务消息存入所述业务系统对应的消息队列的细化流程示意图。

基于上述图2所示实施例，本实施例中，所述业务系统至少包括两个业务端，所述消息队列至少包括两个子队列，所述步骤S20包括：

步骤S23，根据所述业务消息的业务类型查询对应的业务系统，并分别获取所述业务系统中各业务端对应的子队列的消息存放记录和加权因子；

步骤S24，根据预设加权轮询规则、所述消息存放记录和加权因子在各子队列中确定目标子队列，并将所述业务消息存入所述目标子队列。

本实施例中，本实施例中的业务系统在采用分布式架构业务系统时，其至少包括两个处理具体业务的业务端，这些业务端可以是分布在不同的区域。消息平台为了与分布式的业务系统进行适配，对每个业务端都设置有不同的消息队列。消息在根据业务消息的业务类型确定业务消息是由哪一个业务系统进行消费和处理，还需要进一步确定由该业务系统中的哪一个业务端进行消费和处理的。本实施例中，为了实现均衡负载，还可根据加权轮询规则确定实际处理的业务端；其中加权轮询是指将各业务消息的处理时间都看作是相同的，同时还将根据各业务端的实际处理能力为其设定对应的加权因子，然后在该加权因子的基础上以轮询的方式将业务消息分配给不同业务端进行处理。具体的，本实施例中，消息平台在确定对应的业务系统时，将会查询该业务系统的各个业务端对应子队列的消息存放记录，并确定各子队列的加权因子；然后根据消息存放记录和加权因子确定本次要存入的目标子队列(即确定目标业务端)，并将该业务消息存入到目标子队列。例如，业务系统中有A、B两个业务端，A业务端的处理能力可看作是B业务端的两倍(如A为32g运存，B为16g运存，其它性能参数均一致)；A和B所对应的子队列依次为a、b，其顺序编号为1a、2b；根据A和B的处理能力，1a的加权因子为2，2b的加权因子为1；那么，在接收到业务消息时，应该是以“1a、1a、2b、1a、1a、2b...”这样的方式将业务消息存入到对应的子队列中；当接收第i条业务消息时，消息平台将获取2条子队列的消息存放记录，确定前两条消息中，i-2消息是存入了2b子队列，i-1消息是存入了1a消息，则此时目标子队列为1a(消息存放示意图可参见图7)；消息平台则将新业务消息存入到1a子队列中，并向1a子队列对应的A业务端发送消息处理指令，以供A业务端根据所述消息处理指令1a子队列获取该业务消息。

参照图8，图8为图2所述根据所述业务消息的业务类型查询对应的业务系统，并将所述业务消息存入所述业务系统对应的消息队列的细化流程示意图。

基于上述图2所示实施例，本实施例中，所述业务系统至少包括两个业务端，所述消息队列至少包括两个子队列，所述步骤S20包括：

步骤S25，根据所述业务消息的业务类型查询对应的业务系统，并分别获取所述业务系统中各业务端对应的子队列的待处理消息数；

步骤S26，根据预设平均分配规则和所述待处理消息数在各子队列中确定目标子队列，并将所述业务消息存入所述目标子队列。

本实施例中的业务系统在采用分布式架构业务系统时，其至少包括两个处理具体业务的业务端，这些业务端可以是分布在不同的区域。消息平台为了与分布式的业务系统进行适配，对每个业务端都设置有不同的消息队列。消息在根据业务消息的业务类型确定业务消息是由哪一个业务系统进行消费和处理，还需要进一步确定由该业务系统中的哪一个业务端进行消费和处理的。本实施例中，为了实现均衡负载，还可根据均衡分配规则确定实际处理的业务端；其中均衡分配指根据各业务端的实际任务剩余数(即对应的子队列的待处理消息数)确定新消息的实际处理业务端。具体的，本实施例中，消息平台在确定对应的业务系统时，将会查询该业务系统的各个业务端对应子队列的待处理消息数，根据各子队列的待处理消息数确定本次要存入的目标子队列(即确定目标业务端)，并将该业务消息存入到目标子队列。例如，业务系统中有A、B、C三个业务端，其所对应的子队列依次为a、b、c；在接收到业务消息时，消息平台将获取3条子队列的待处理消息数，确定a队列中有3条待处理消息，b队列有4条待处理消息，c队列有2条待处理消息；此时为了均衡各业务端的处理压力，可将c队列确定为目标子队列，并将新业务消息存入到c子队列中，同时向c子队列对应的C业务端发送消息处理指令，以供C业务端根据所述消息处理指令c子队列获取该业务消息。

值得说明的是，关于本发明中的均衡算法以及目标子队列(目标业务端)的选择过程，还可以根据实际情况设置其它的规则，例如还可以结合业务端与客户端之间的地理距离和业务端的实际处理能力来确定目标子队列，又或者是同一客户端的业务消息由同一个(或同一批)业务端进行处理，以充分利用同一客户端的相关缓存信息等，从而满足适配不同的业务处理需求，缓解业务系统的高并发处理场景下处理压力。

参照图9，图9为本发明消息处理方法第二实施例的流程示意图。

基于上述图2所述实施例，本实施例中，步骤S30之后，还包括：

步骤S40，对所述消息队列的消息获取状况进行监控；

步骤S50，若在预设处理时间内未监控到所述业务系统从所述消息队列获取所述业务消息，则向备用业务系统发送二次处理指令，以供所述备用业务系统根据所述二次处理指令从所述消息队列获取所述业务消息。

本实施例中，消息平台在将业务消息存入到消息队列后，还将对消息队列的消息获取状况进行监控，以记录该业务消息的处理情况。而如果在预设处理时间内都没有监控到业务系统从消息队列取走该业务消息，则可认为业务系统可能出现了较大的业务压力，无法及时处理该业务消息；此时，消息平台可向其它备用的业务系统发送二次处理指令，以供备用的业务系统根据该二次处理指令从消息队列获取业务消息，从而及时处理该业务消息。

进一步的，当业务系统是采用分布式架构，具有两个以上的业务端时，若在预设处理时间内都没有监控到目标业务从目标子队列取走该业务消息，还可以是重新在各子队列中确定二次子队列，并将该业务消息从原目标子队列中取出，并存入到该二次子队列中，以更换该业务消息的实际处理业务端。

此外，本发明还提供一种消息处理装置。

参照图10，图10为本发明消息处理装置第一实施例的功能模块示意图。

本实施例中，所述消息处理装置包括：

类型确定模块10，用于在接收到客户端发送的业务消息时，对所述业务消息进行解析，以确定所述业务消息的业务类型；

消息存入模块20，用于根据所述业务消息的业务类型查询对应的业务系统，并将所述业务消息存入所述业务系统对应的消息队列；

指令发送模块30，用于向所述业务系统发送消息处理指令，以供所述业务系统根据所述消息处理指令从所述消息队列获取所述业务消息。

进一步的，所述业务系统至少包括两个业务端，所述消息队列至少包括两个子队列，所述消息存入模块20包括：

第一获取单元，用于根据所述业务消息的业务类型查询对应的业务系统，并分别获取所述业务系统中各业务端对应的子队列的消息存放记录；

第一存入单元，用于根据预设顺序轮询规则和所述消息存放记录在各子队列中确定目标子队列，并将所述业务消息存入所述目标子队列；

所述指令发送模块30，还用于向所述目标子队列对应的目标业务端发送消息处理指令，以供所述目标业务端根据所述消息处理指令从所述目标子队列获取所述业务消息。

进一步的，所述业务系统至少包括两个业务端，所述消息队列至少包括两个子队列，所述消息存入模块20包括：

第二获取单元，用于根据所述业务消息的业务类型查询对应的业务系统，并分别获取所述业务系统中各业务端对应的子队列的消息存放记录和加权因子；

第二存入单元，用于根据预设加权轮询规则、所述消息存放记录和加权因子在各子队列中确定目标子队列，并将所述业务消息存入所述目标子队列；

所述指令发送模块30，还用于向所述目标子队列对应的目标业务端发送消息处理指令，以供所述目标业务端根据所述消息处理指令从所述目标子队列获取所述业务消息。

进一步的，所述业务系统至少包括两个业务端，所述消息队列至少包括两个子队列，所述消息存入模块20包括：

第三获取单元，用于根据所述业务消息的业务类型查询对应的业务系统，并分别获取所述业务系统中各业务端对应的子队列的待处理消息数；

第三存入单元，用于根据预设均衡分配规则和所述待处理消息数在各子队列中确定目标子队列，并将所述业务消息存入所述目标子队列；

所述指令发送模块30，还用于向所述目标子队列对应的目标业务端发送消息处理指令，以供所述目标业务端根据所述消息处理指令从所述目标子队列获取所述业务消息。

进一步的，所述消息处理装置还包括：

队列监控模块，用于对所述消息队列的消息获取状况进行监控；

二次发送模块，用于若在预设处理时间内未监控到所述业务系统从所述消息队列获取所述业务消息，则向备用业务系统发送二次处理指令，以供所述备用业务系统根据所述二次处理指令从所述消息队列获取所述业务消息。

进一步的，所述类型确定模块10，还用于在接收到客户端发送的业务消息时，对所述业务消息进行解析，以确定所述业务消息的业务类型；

所述消息处理装置还包括：

消息返回模块，用于接收所述业务系统返回的业务结果消息，并根据所述发送路径将所述业务结果消息发送至所述客户端。

进一步的，所述消息处理装置还包括：

队列创建模块，用于在接收到新增业务系统发送的服务上线请求时，获取所述新增业务系统的新增业务类型信息，并创建与所述新增业务系统对应的新增消息队列。

其中，上述消息处理装置中各个模块与上述消息处理方法实施例中各步骤相对应，其功能和实现过程在此处不再赘述。

此外，本发明还提供一种计算机可读存储介质。

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

其中，消息处理程序被执行时所实现的方法可参照本发明消息处理方法的各个实施例，此处不再赘述。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上所述的一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种消息处理方法，其特征在于，所述消息处理方法应用于消息平台，所述消息处理方法包括以下步骤：

在接收到客户端发送的业务消息时，对所述业务消息进行解析，以确定所述业务消息的业务类型；

根据所述业务消息的业务类型查询对应的业务系统，并将所述业务消息存入所述业务系统对应的消息队列；

向所述业务系统发送消息处理指令，以供所述业务系统根据所述消息处理指令从所述消息队列获取所述业务消息。

2.如权利要求1所述的消息处理方法，其特征在于，所述业务系统至少包括两个业务端，所述消息队列至少包括两个子队列，

所述根据所述业务消息的业务类型查询对应的业务系统，并将所述业务消息存入所述业务系统对应的消息队列的步骤包括：

根据所述业务消息的业务类型查询对应的业务系统，并分别获取所述业务系统中各业务端对应的子队列的消息存放记录；

根据预设顺序轮询规则和所述消息存放记录在各子队列中确定目标子队列，并将所述业务消息存入所述目标子队列；

所述向所述业务系统发送消息处理指令，以供所述业务系统根据所述消息处理指令从所述消息队列获取所述业务消息的步骤包括：

向所述目标子队列对应的目标业务端发送消息处理指令，以供所述目标业务端根据所述消息处理指令从所述目标子队列获取所述业务消息。

3.如权利要求1所述的消息处理方法，其特征在于，所述业务系统至少包括两个业务端，所述消息队列至少包括两个子队列，

所述根据所述业务消息的业务类型查询对应的业务系统，并将所述业务消息存入所述业务系统对应的消息队列的步骤包括：

根据所述业务消息的业务类型查询对应的业务系统，并分别获取所述业务系统中各业务端对应的子队列的消息存放记录和加权因子；

根据预设加权轮询规则、所述消息存放记录和加权因子在各子队列中确定目标子队列，并将所述业务消息存入所述目标子队列；

所述向所述业务系统发送消息处理指令，以供所述业务系统根据所述消息处理指令从所述消息队列获取所述业务消息的步骤包括：

向所述目标子队列对应的目标业务端发送消息处理指令，以供所述目标业务端根据所述消息处理指令从所述目标子队列获取所述业务消息。

4.如权利要求1所述的消息处理方法，其特征在于，所述业务系统至少包括两个业务端，所述消息队列至少包括两个子队列，

所述根据所述业务消息的业务类型查询对应的业务系统，并将所述业务消息存入所述业务系统对应的消息队列的步骤包括：

根据所述业务消息的业务类型查询对应的业务系统，并分别获取所述业务系统中各业务端对应的子队列的待处理消息数；

根据预设均衡分配规则和所述待处理消息数在各子队列中确定目标子队列，并将所述业务消息存入所述目标子队列；

所述向所述业务系统发送消息处理指令，以供所述业务系统根据所述消息处理指令从所述消息队列获取所述业务消息的步骤包括：

向所述目标子队列对应的目标业务端发送消息处理指令，以供所述目标业务端根据所述消息处理指令从所述目标子队列获取所述业务消息。

5.如权利要求1所述的消息处理方法，其特征在于，所述向所述业务系统发送消息处理指令，以供所述业务系统根据所述消息处理指令从所述消息队列获取所述业务消息的步骤之后，还包括：

对所述消息队列的消息获取状况进行监控；

若在预设处理时间内未监控到所述业务系统从所述消息队列获取所述业务消息，则向备用业务系统发送二次处理指令，以供所述备用业务系统根据所述二次处理指令从所述消息队列获取所述业务消息。

6.如权利要求1所述的消息处理方法，其特征在于，所述在接收到客户端发送的业务消息时，对所述业务消息进行解析，以确定所述业务消息的业务类型的步骤包括：

在接收到客户端通过发送的业务消息时，获取所述客户端的发送路径，并对所述业务消息进行解析，以确定所述业务消息的业务类型；

所述向所述业务系统发送消息处理指令，以供所述业务系统根据所述消息处理指令从所述消息队列获取所述业务消息的步骤之后，还包括：

接收所述业务系统返回的业务结果消息，并根据所述发送路径将所述业务结果消息发送至所述客户端。

7.如权利要求1至6中任一项所述的消息处理方法，其特征在于，所述消息处理方法还包括：

在接收到新增业务系统发送的服务上线请求时，获取所述新增业务系统的新增业务类型信息，并创建与所述新增业务系统对应的新增消息队列。

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

类型确定模块，用于在接收到客户端发送的业务消息时，对所述业务消息进行解析，以确定所述业务消息的业务类型；

消息存入模块，用于根据所述业务消息的业务类型查询对应的业务系统，并将所述业务消息存入所述业务系统对应的消息队列；

指令发送模块，用于向所述业务系统发送消息处理指令，以供所述业务系统根据所述消息处理指令从所述消息队列获取所述业务消息。

9.一种消息处理设备，其特征在于，所述消息处理设备包括处理器、存储器、以及存储在所述存储器上并可被所述处理器执行的消息处理程序，其中所述消息处理程序被所述处理器执行时，实现如权利要求1至7中任一项所述的消息处理方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有消息处理程序，其中所述消息处理程序被处理器执行时，实现如权利要求1至7中任一项所述的消息处理方法的步骤。