一种消息处理方法及装置与流程

本申请涉及数据处理领域，特别是涉及一种消息处理方法，以及一种消息处理装置。

背景技术：

目前，服务器集群针对大规模消息通常采用异步处理的方式。这种方式主要存在以下问题：

一方面，由于集群中各虚拟机的处理能力有差异，以相同速度从messagebroker上拉取消息时，很容易在处理能力低下的虚拟机上已经开始出现缓慢堆积，但处理性能卓越的虚拟机又处于闲置状态，因此存在消息分配不合理，资源利用不充分的问题。

另一方面，在异步消息的处理架构中，经常出现消息处理能力落后于消息产生能力的情况，从而会在存储并分发消息的消息中间件messagebroker上出现消息堆积，甚至会使得messagebroker为了保证其自身运作正常，主动进行消息丢弃，导致消息漏掉未处理。

技术实现要素：

鉴于上述问题，提出了本申请实施例以便提供一种克服上述问题或者至少部分地解决上述问题的消息处理方法和装置。

为了解决上述问题，本申请公开了一种消息处理方法，包括：

对虚拟机的未处理消息进行监控；

当检测到未处理消息超出所述虚拟机的负载上限时，切断消息拉取。

优选地，在所述对虚拟机的未处理消息进行监控之前，所述方法还包括：

从分发消息的消息中间件拉取消息。

优选地，在所述从分发消息的消息中间件拉取消息之前，所述方法还包括：

订阅所述消息中间件的消息缓存主队列；

所述从分发消息的消息中间件拉取消息包括：

在接收到所述消息缓存主队列的消息通知后，从所述消息缓存主队列中拉取消息。

优选地，所述切断消息拉取包括：

切断对所述消息缓存主队列的消息订阅，以切断消息拉取。

优选地，所述方法还包括：

当检测到所述未处理消息低于所述虚拟机的负载下限时，恢复消息拉取。

优选地，所述恢复消息拉取包括：

恢复对所述消息缓存主队列的消息订阅，以恢复消息拉取。

优选地，所述检测到所述未处理消息超出所述虚拟机的负载上限包括：

检测到所述未处理消息所占用缓存超出第一配置值；

所述检测到所述未处理消息低于所述虚拟机的负载下限包括：

检测到所述未处理消息所占用缓存低于第二配置值。

优选地，在所述从分发消息的消息中间件拉取消息之后，所述方法还包括：

将拉取的多个消息存储至预先构建的消息缓存子队列中。

优选地，所述方法还包括：

采用多个异步线程进行消息处理。

优选地，在所述从分发消息的消息中间件拉取消息之后，所述方法还包括：

通知所述消息中间件删除已拉取的未处理消息；

或，通知所述消息中间件对已拉取的未处理消息添加已处理标识。

优选地，所述方法还包括：

检测所述虚拟机的各项资源参数，并根据检测结果对所述虚拟机设置第一配置值和第二配置值。

本申请还提供了一种消息处理装置，包括：

消息监控模块，用于对虚拟机的未处理消息进行监控。

消息拉取控制模块，用于当检测到未处理消息超出所述虚拟机的负载上限时，切断消息拉取。

优选地，所述装置还包括：

消息拉取模块，用于在所述对虚拟机的未处理消息进行监控之前，从分发消息的消息中间件拉取消息；

优选地，所述装置还包括：

消息订阅模块，用于在所述从分发消息的消息中间件拉取消息之前，订阅所述消息中间件的消息缓存主队列；

所述消息拉取模块，具体用于在接收到所述消息缓存主队列的消息通知后，从所述消息缓存主队列中拉取消息。

优选地，所述消息拉取控制模块包括：

订阅切断子模块，用于切断对所述消息缓存主队列的消息订阅，以切断消息拉取。

优选地，所述消息拉取控制模块，还用于当检测到所述未处理消息低于所述虚拟机的负载下限时，恢复消息拉取。

优选地，所述消息拉取控制模块还包括：

订阅恢复子模块，用于恢复对所述消息缓存主队列的消息订阅，以恢复消息拉取。

优选地，所述消息拉取控制模块，具体用于当检测到所述未处理消息所占用缓存超出第一配置值时，切断消息拉取；当检测到所述未处理消息所占用缓存低于第二配置值时，恢复消息拉取。

优选地，所述装置还包括：

消息存储模块，用于在所述从分发消息的消息中间件拉取消息之后，将拉取的多个消息存储至预先构建的消息缓存子队列中。

优选地，所述装置还包括：

消息处理模块，用于采用多个异步线程进行消息处理。

本申请实施例包括以下优点：

依据本申请实施例，实时统计虚拟机的未处理消息，若检测到未处理消 息超出虚拟机的负载上限，则切换消息拉取，避免在虚拟机上出现消息堆积。相应的，若检测到未处理消息低于虚拟机的负载下限，则恢复消息拉取，以实现对虚拟机处理资源的充分利用。通过上述方案可以根据服务器集群中各虚拟机的实际负载能力进行消息拉取，可以将消息更多的分配到负载能力较好的虚拟机，在充分有效利用处理资源的同时，可以提高消息的整体处理效率。

并且，本申请实施例中，还可以采用消息缓存子队列缓存从消息中间件的消息缓存主队列中拉取的消息，并在拉取消息之后，通知消息中间件删除已拉取的消息，或是标记为已处理，从而有效缓解了消息中间件的存储压力，避免消息中间件上出现消息堆积以及消息漏掉未处理的问题。

附图说明

图1是本申请的一种消息处理方法实施例1的步骤流程图；

图2是本申请的一种消息处理方法实施例2的步骤流程图；

图3是背景技术的异步消息处理架构图；

图4是应用本申请实施例的异步消息处理架构图；

图5是本申请实施例中切断消息订阅的示意图；

图6是本申请实施例中恢复消息订阅的示意图；

图7是本申请的一种消息处理装置实施例的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

实施例1

参照图1，示出了本申请的一种消息处理方法实施例1的步骤流程图，具体可以包括如下步骤：

步骤101，对虚拟机的未处理消息进行监控。

本申请实施例可以应用于服务器集群中执行异步消息处理的各个虚拟机，服务器集群中部署有多个虚拟机，用于对待处理的大规模消息进行异步 处理。本申请实施例针对各个虚拟机的未处理消息进行监控，以用于进一步的判断。

步骤102，当检测到未处理消息超出所述虚拟机的负载上限时，切断消息拉取。

此处虚拟机的负载上限可以表征虚拟机的平均负载能力或是最大负载能力，可以是根据虚拟机当前负载能力来配置，例如根据对虚拟机当前各项资源参数的检测结果配置该负载上限；也可以根据虚拟机的历史正常负载能力来配置，具体可以通过消息对历史负载数据统计得到该负载上限，例如取历史负载数据的均值或是最大值；可以是根据经验设定的期望值，还可以采用其他任意适用的方式配置。

负载上限可以有多种表示形式。例如，采用消息的个数表示，或是采用消息的资源占用量来表示，例如消息所占用的cpu资源、存储资源(例如缓存资源)、带宽资源等至少一种。还可以是其他任意适用的表示形式，本申请对此并不做限制。

采用消息个数表示时，可以直接将未处理消息与负载上限进行比较。

采用资源占用量表示时，具体根据未处理消息进行比较时，可以计算未处理消息实际的资源占用量或是预估的资源占用量，并将计算结果与负载上限进行比较，计算结果高于该负载上限，也即是未处理消息高于负载上限；或是根据负载上限计算相应的消息个数，将未处理消息的个数与计算的消息个数进行比较，未处理消息的个数高于计算的消息个数，也即是未处理消息高于负载上限。

若检测到未处理消息超出虚拟机的负载上限，则切断消息拉取，以避免在虚拟机上出现消息堆积。切断消息拉取可以有多种实现方式，例如切断对消息中间件的订阅，或是拦截或通过设置限制对消息拉取动作等。

在本申请的优选实施例中，还可以当检测到未处理消息低于所述虚拟机的负载下限时，恢复消息拉取。

此处虚拟机的负载下限可以表征虚拟机的平均负载能力或是最小负载能力，需要保证其小于负载上限。具体可以是根据虚拟机当前负载能力来配 置，例如根据对虚拟机当前各项资源参数的检测结果配置该负载下限；也可以根据虚拟机的历史正常负载能力来配置，具体可以通过消息对历史负载数据统计得到该负载下限，例如取历史负载数据的均值或是最小值；可以是根据经验设定的期望值，还可以采用其他任意适用的方式配置。

负载下限可以有多种表示形式，例如，采用消息的个数表示，或是采用消息的资源占用量来表示，例如消息所占用的cpu资源、存储资源(例如缓存资源)、带宽资源等至少一种。还可以是其他任意适用的表示形式，本申请对此并不做限制。

采用消息个数表示时，可以直接将未处理消息与负载下限进行比较。

采用资源占用量表示时，具体根据未处理消息进行比较时，可以计算未处理消息实际的资源占用量或是预估的资源占用量，并将计算结果与负载下限进行比较，计算结果低于该负载下限，也即是未处理消息低于负载下限；或是根据负载下限计算相应的消息个数，将未处理消息的个数与计算的消息个数进行比较，未处理消息的个数低于计算的消息个数，也即是未处理消息低于负载下限。

依据本申请实施例，若检测到未处理消息低于所述虚拟机的负载下限，则恢复消息拉取，以实现对虚拟机处理资源的充分利用。

其中，恢复消息拉取可以有多种实现方式，例如恢复对消息中间件的订阅，或是解除对消息拉取动作的拦截或限制等。

通过上述方案可以根据服务器集群中各虚拟机的实际负载能力进行消息拉取，可以将消息更多的分配到负载能力较好的虚拟机，在充分有效利用处理资源的同时，可以提高消息的整体处理效率。

本申请实施例中，优选的，虚拟机处理的消息可以来源于消息中间件，该消息中间件用于向服务器集群中的各个虚拟机分发消息。具体可以从分发消息的消息中间件拉取消息。

待处理的消息在生成后即存储至消息中间件，由消息中间件分发至各个虚拟机。其中，消息可以从对虚拟机上程序服务的访问请求中抽取，或是有其他的来源，本申请对此并不做限制。

本申请实施例中，各个虚拟机从消息中间件拉取消息，拉取的消息可以是消息中间件分配给该虚拟机处理的消息，具体的分配方式本申请并不做限制，例如，可以按照各个虚拟机的编号或是预先排定各个虚拟机的优先级，将待处理的任务按序分配给各个虚拟机，或是按照预先设定的消息类型与虚拟机的对应关系进行分配，还可以按照预设的算法进行分配；拉取的消息也可以是按照虚拟机拉取消息的请求，实行先到先得，将待处理的消息分配给先发送请求的虚拟机。

虚拟机拉取消息后便可以进一步执行对消息的处理，针对大规模消息处理的场景，拉取的消息较多，优选处理的方式是采用异步线程池中多个异步线程进行消息处理，相比于同步处理的方式可以大大提高消息处理的效率。

其中，消息中间件可以是messagebroker，也可以是其他任意适用的、实现消息分发功能的消息中间件，例如activemessenger。

实施例2

参照图2，示出了本申请的一种消息处理方法实施例2的步骤流程图，应用于服务器集群中执行异步消息处理的各个虚拟机，具体可以包括如下步骤：

步骤201，订阅消息中间件的消息缓存主队列。

消息中间件可以采用消息缓存主队列保存待处理的所有消息，可以通过订阅该消息缓存主队列以获知新消息。

订阅是消息的一种传递机制，包括一个消息的发布者和多个订阅者，应用到本申请实施例，也即是消息发布者也即是消息中间件，消息订阅者也即是各个虚拟机。优选地，在订阅消息时，还可以订阅具体优选处理的消息类型，以使消息中间件在检测到该类型的消息时通知对应的虚拟机。

步骤202，在接收到所述消息缓存主队列的消息通知后，从所述消息缓存主队列中拉取消息，将拉取的多个消息存储至预先构建的消息缓存子队列中。

订阅所述消息中间件的消息缓存主队列后，消息缓存队列进行新消息的 通知，在接收到所述消息缓存主队列的消息通知后，再从所述消息缓存主队列中拉取消息。

本申请实施例中，采用分层缓存的方式，从消息中间件的消息缓存主队列中拉取的消息缓存至虚拟机本地的消息缓存子队列。

步骤203，通知所述消息中间件删除已拉取的未处理消息；或，通知所述消息中间件对已拉取的未处理消息添加已处理标识。

将消息缓存至虚拟机本地的消息缓存子队列后，可以进一步通知消息中间件删除已拉取的消息，或是标记为已处理，从而有效缓解了消息中间件的存储压力，避免消息中间件上出现消息堆积以及消息漏掉未处理的问题。

在本申请的另一种优选实施例中，本步骤也可以在由消息中间件主动执行，根据虚拟机拉取消息的请求将消息分配至虚拟机后，可以从消息缓存主队中删除已分配的消息，或是对已分配的消息添加已分配标识。

步骤204，执行消息处理。

步骤205，对所述虚拟机的未处理消息进行监控。

具体可以是对消息缓存子队列中的未处理消息进行监控，具体可以是监控未处理消息的个数，也可以是监控未处理消息的资源占用量，具体可以与负载上限或负载下限的表示方式可以一致，也可以不一致。进行比较时，可以换算为对应消息的个数进行比较，也可以换算为对应的资源占用量进行比较。

步骤206，当检测到所述消息缓存子队列中所述未处理消息所占用缓存超出第一配置值时，切断对所述消息缓存主队列的消息订阅，以切断消息拉取。

本实施例中，负载上限表示为消息占用的缓存大小，记为第一配置值，相应的，所述检测到未处理消息超出虚拟机的负载上限可以包括：检测到所述消息缓存子队列中所述未处理消息所占用缓存超出第一配置值。

本实施例中，切断消息拉取通过切断对消息缓存主队列的订阅实现。

步骤207，当检测到所述消息缓存子队列中所述未处理消息所占用缓存低于第二配置值时，恢复对所述消息缓存主队列的消息订阅，以恢复消息拉 取。

本实施例中，负载下限表示为消息占用的缓存大小，记为第二配置值，相应的，所述检测到未处理消息低于所述虚拟机的负载下限可以包括：检测到所述消息缓存子队列中所述未处理消息所占用缓存低于第二配置值。

本实施例中，恢复消息拉取通过恢复对消息缓存主队列的订阅实现。

进一步优选地，可以通过检测所述虚拟机的各项资源参数，例如cpu、存储空间(例如缓存空间)、带宽等至少一种。进一步根据检测结果对所述虚拟机设置第一配置值和第二配置值，具体的设置方式可以根据实际需求选择，例如第一配置值设置为资源参数的80％，第二配置值设置为资源参数的30％。例如，检测到虚拟机的缓存空间为100m，则对应第一配置值设置为80m，第二配置值设置为30m。

依据本申请实施例，实时统计虚拟机的未处理消息，若检测到未处理消息超出虚拟机的负载上限，则切换消息拉取，避免在虚拟机上出现消息堆积。相应的，若检测到未处理消息低于所述虚拟机的负载下限，则恢复消息拉取，以实现对虚拟机处理资源的充分利用。通过上述方案可以根据服务器集群中各虚拟机的实际负载能力进行消息拉取，可以将消息更多的分配到负载能力较好的虚拟机，在充分有效利用处理资源的同时，可以提高消息的整体处理效率。

并且，本申请实施例中，还可以采用消息缓存子队列缓存从消息中间件的消息缓存主队列中拉取的消息，并在拉取消息之后，通知消息中间件删除已拉取的消息，或是标记为已处理，从而有效缓解了消息中间件的存储压力，避免消息中间件上出现消息堆积以及消息漏掉未处理的问题。

为更好地说明本申请实施例，以下对本申请与背景技术的方案进行对比。如图3示出了背景技术的异步消息处理架构图。通过messagebroker向多个虚拟机(vm_1～vm_n)分发消息，messagebroker采用集中缓存存储未处理的所有消息。这种方案存在消息分配不合理、资源利用不充分、消息堆积以及可能的消息漏掉未处理的问题。

如图4示出了应用本申请实施例的异步消息处理架构图。一方面，通过 分层缓存队列的设计，在消费端构建本地缓存队列，messagebroker的集中缓存移至本地，从而有效缓解了消息中间件的存储压力，避免消息中间件上出现消息堆积以及消息漏掉未处理的问题。

图5示出了本申请实施例中切断消息订阅的示意图，当某个虚拟机上出现消息堆积，确定本地已缓存的消息总量，即缓存大小大于配置值1时，则动态切断消息订阅，避免在虚拟机上出现消息堆积。图6示出了本申请实施例中恢复消息订阅的示意图，切断订阅后，不会从messagebroker拉取消息，但会持续处理本地缓存队列的消息，当某个虚拟机上本地已缓存的消息总量，即缓存大小小于预设的配置值2时，则动态恢复消息订阅，见虚线所示，以实现对虚拟机处理资源的充分利用。由此可见，相比于背景技术的方案，本申请可以根据服务器集群中各虚拟机的实际负载能力进行消息拉取，可以将消息更多的分配到负载能力较好的虚拟机，在充分有效利用处理资源的同时，可以提高消息的整体处理效率。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。

实施例3

参照图7，示出了本申请的一种消息处理装置实施例的结构框图，部署于服务器集群中执行异步消息处理的各个虚拟机，具体可以包括如下模块：

消息监控模块301，用于对虚拟机的未处理消息进行监控。

消息拉取控制模块302，用于当检测到未处理消息超出所述虚拟机的负载上限时，切断消息拉取。

本申请实施例中，优选地，所述装置还包括：

消息拉取模块，用于在所述对虚拟机的未处理消息进行监控之前，从分 发消息的消息中间件拉取消息；

本申请实施例中，优选地，所述装置还包括：

消息订阅模块，用于在所述从分发消息的消息中间件拉取消息之前，订阅所述消息中间件的消息缓存主队列；

所述消息拉取模块，具体用于在接收到所述消息缓存主队列的消息通知后，从所述消息缓存主队列中拉取消息。

本申请实施例中，优选地，所述消息拉取控制模块包括：

订阅切断子模块，用于切断对所述消息缓存主队列的消息订阅，以切断消息拉取。

本申请实施例中，优选地，所述消息拉取控制模块，还用于当检测到所述未处理消息低于所述虚拟机的负载下限时，恢复消息拉取。

本申请实施例中，优选地，所述消息拉取控制模块还包括：

订阅恢复子模块，用于恢复对所述消息缓存主队列的消息订阅，以恢复消息拉取。

本申请实施例中，优选地，所述消息拉取控制模块，具体用于当检测到所述未处理消息所占用缓存超出第一配置值时，切断消息拉取；当检测到所述未处理消息所占用缓存低于第二配置值时，恢复消息拉取。

本申请实施例中，优选地，所述装置还包括：

消息存储模块，用于在所述从分发消息的消息中间件拉取消息之后，将拉取的多个消息存储至预先构建的消息缓存子队列中。

本申请实施例中，优选地，所述装置还包括：

消息处理模块，用于采用多个异步线程进行消息处理。

本申请实施例中，优选地，所述装置还包括：

通知模块，用于在所述从消息中间件拉取消息之后，通知所述消息中间件删除已拉取的未处理消息；或，通知所述消息中间件对已拉取的未处理消息添加已处理标识。

本申请实施例中，优选地，所述装置还包括：

参数检测模块，用于检测所述虚拟机的各项资源参数，并根据检测结果 对所述虚拟机设置第一配置值和第二配置值。

依据本申请实施例，实时统计虚拟机的未处理消息，若检测到未处理消息超出虚拟机的负载上限，则切换消息拉取，避免在虚拟机上出现消息堆积。相应的，若检测到未处理消息低于所述虚拟机的负载下限，则恢复消息拉取，以实现对虚拟机处理资源的充分利用。通过上述方案可以根据服务器集群中各虚拟机的实际负载能力进行消息拉取，可以将消息更多的分配到负载能力较好的虚拟机，在充分有效利用处理资源的同时，可以提高消息的整体处理效率。

并且，本申请实施例中，还可以采用消息缓存子队列缓存从消息中间件的消息缓存主队列中拉取的消息，并在拉取消息之后，通知消息中间件删除已拉取的消息，或是标记为已处理，从而有效缓解了消息中间件的存储压力，避免消息中间件上出现消息堆积以及消息漏掉未处理的问题。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

在一个典型的配置中，所述计算机设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示 例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非持续性的电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的一种消息处理方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。