消息处理方法及系统技术方案

本申请实施例公开了一种消息处理方法，所述方法包括：通过目标消息队列存储与多个消息对应的多个队列节点，所述多个队列节点包括多个可压缩节点；压缩所述多个可压缩节点，以得到压缩后的目标消息队列；及消费所述压缩后的目标消息队列中的各个队列节点。本申请实施例可以压缩目标消息队列内部的消息(对应于相应的队列节点)的数量，从而可以提高处理消息的吞吐量，提高消息的处理效率，避免消息过多导致的消息挤压和系统阻塞。致的消息挤压和系统阻塞。致的消息挤压和系统阻塞。

【技术实现步骤摘要】
消息处理方法及系统


[0001]本申请涉及数据处理
，尤其涉及一种消息处理方法、系统、计算机设备和计算机可读存储介质。

技术介绍

[0002]系统内部的数据或消息的生产与消费，通常是基于某一队列线程或线程池消费实现。系统之间则通过专业的消息中间件(如，Kafka)解耦系统间的消息生产与消费，消息中间件会增加系统复杂度和开销，不适用于作为系统内部的消息组件。
[0003]当前，系统内部的生产与消费，容易因为消息过多导致消息积压，造成系统阻塞。

技术实现思路

[0004]本申请实施例的目的是提供一种消息处理方法、系统、计算机设备及计算机可读存储介质，用于解决系统内部的生产与消费，易因消息过多导致消息积压，造成系统阻塞的问题。
[0005]本申请实施例的一个方面提供了一种消息处理方法，所述方法包括：通过目标消息队列存储与多个消息对应的多个队列节点，所述多个队列节点包括多个可压缩节点；压缩所述多个可压缩节点，以得到压缩后的目标消息队列；及消费所述压缩后的目标消息队列中的各个队列节点。
[0006]可选的，所述目标消息队列为多个消息队列之一，所述方法还包括：接收一个或多个消息；根据各个消息的消息标识进行哈希运算，以得到所述各个消息的哈希值；根据所述各个消息的哈希值，将所述各个消息路由到所述多个消息队列中相应的消息队列。
[0007]可选的，通过目标消息队列存储多个队列节点，包括：检测是否有待入队的消息；当有所述待入队的消息，则确定所述待入队的消息是否可压缩；当所述待入队的消息可压缩，则根据所述待入队的消息得到携带有相应Key的可压缩节点；当所述待入队的消息不可压缩，则根据所述待入队的消息得到相应的不可压缩节点；及将所述携带有相应Key的可压缩节点或所述相应的不可压缩节点加入到所述目标消息队列中。
[0008]可选的，还包括：确定所述目标消息队列的工作模式，以根据所述工作模式确定是否对所述目标消息队列进行压缩；其中，所述工作模式包括普通模式和压缩模式，所述普通模式不对所述目标消息队列进行压缩，所述压缩模式为对所述目标消息队列中的所述多个可压缩节点进行压缩。
[0009]可选的，确定所述目标消息队列的工作模式，包括：判断所述目标消息队列中的所有队列节点的节点数量是否超过预设阈值；如果所述节点数量超过所述预设阈值，则将所述目标消息队列的工作模式切换到所述压缩模式。
[0010]可选的，当所述目标消息队列处于所述压缩模式时；确定所述目标消息队列的工作模式，包括：判断所述目标消息队列中的所有队列节点的节点数量是否超过预设阈值；如果所述节点数量不超过所述预设阈值，则由所述压缩模式切换为所述普通模式。
[0011]可选的，所述多个可压缩节点中的各个可压缩节点分别携带有相应的Key；对所述目标消息队列中的所述多个可压缩节点进行压缩，包括：根据所述各个可压缩节点的Key，将所述多个可压缩节点分为一个或多个分组；及分别将各个分组中的所有可压缩节点压缩为一个单一队列节点。
[0012]可选的，还包括：当所述目标消息队列中的一个队列节点被消费之后，则将这个队列节点进行重置；及将这个重置后的队列节点存储到节点工厂中，以用于封装待入队的后续消息。
[0013]本申请实施例的一个方面又提供了一种消息处理系统，包括：存储模块，用于通过目标消息队列存储多个队列节点，所述多个队列节点包括多个可压缩节点；压缩模块，用于对所述目标消息队列中的所述多个可压缩节点进行压缩，以得到压缩后的目标消息队列；及消费模块，用于消费所述压缩后的目标消息队列中的各个队列节点。
[0014]本申请实施例的一个方面又提供了一种计算机设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述消息处理方法的步骤。
[0015]本申请实施例的一个方面又提供了一种计算机可读存储介质，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述消息处理方法的步骤。
[0016]本申请实施例提供的消息处理方法、系统、设备及计算机可读存储介质，可以压缩目标消息队列内部的消息(对应于相应的队列节点)的数量，从而可以提高处理消息的吞吐量，提高消息的处理效率，避免消息过多导致的消息挤压和系统阻塞。
附图说明
[0017]图1示意性示出了根据本申请实施例一的消息处理方法的流程图；
[0018]图2为图1中步骤S100的子步骤图；
[0019]图3为图1中步骤S102的子步骤图；
[0020]图4为示意性示出了根据本申请实施例一的消息处理方法的新增步骤流程图；
[0021]图5为示意性示出了根据本申请实施例一的消息处理方法的另一新增步骤流程图；
[0022]图6示意性示出了根据本申请实施例二的消息处理方法的流程图；
[0023]图7为图6中步骤S602的子步骤图；
[0024]图8为图6中步骤S602的另一子步骤图；
[0025]图9为示意性示出了实现本申请实施例的结构图；
[0026]图10示意性示出了目标消息队列的压缩前后对比图；
[0027]图11示意性示出了根据本申请实施例三的消息处理系统的框图；及
[0028]图12示意性示出了根据本申请实施例四的适于实现消息处理方法的计算机设备的硬件架构示意图。
具体实施方式
[0029]为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对
本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
[0030]需要说明的是，在本申请实施例中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。
[0031]系统内部数据或消息的生产与异步消费，通常是基于某一队列线程或线程池消费实现。系统之间则通过专业的消息中间件(如，kafka)解耦系统间的消息生产与消费，消息中间件会增加系统复杂度和开销，不适用于作为系统内部的消息组件。
[0032]专利技术人发现，基于现有技术的系统内部的生产与消费，通常都是单一队列线程或线程池方案，不具备路由、压缩、消费顺序性等功能，消息过多容易积压，造成系统阻塞。有鉴于此，本申请旨在一种轻量级、可自定义路由、可以按顺序消费、可以自动压缩、高吞吐、线程安全的智能数据处理技术，以解决上述问题。
[0033本文档来自技高网...

【技术保护点】

【技术特征摘要】
1.一种消息处理方法，其特征在于，所述方法包括：通过目标消息队列存储与多个消息对应的多个队列节点，所述多个队列节点包括多个可压缩节点；压缩所述多个可压缩节点，以得到压缩后的目标消息队列；及消费所述压缩后的目标消息队列中的各个队列节点。2.根据权利要求1所述的消息处理方法，其特征在于，所述目标消息队列为多个消息队列之一，所述方法还包括：接收一个或多个消息；根据各个消息的消息标识进行哈希运算，以得到所述各个消息的哈希值；根据所述各个消息的哈希值，将所述各个消息路由到所述多个消息队列中相应的消息队列。3.根据权利要求1所述的消息处理方法，其特征在于，通过目标消息队列存储多个队列节点，包括：检测是否有待入队的消息；当有所述待入队的消息，则确定所述待入队的消息是否可压缩；当所述待入队的消息可压缩，则根据所述待入队的消息得到携带有相应Key的可压缩节点；当所述待入队的消息不可压缩，则根据所述待入队的消息得到相应的不可压缩节点；及将所述携带有相应Key的可压缩节点或所述相应的不可压缩节点加入到所述目标消息队列中。4.根据权利要求1所述的消息处理方法，其特征在于，还包括：确定所述目标消息队列的工作模式，以根据所述工作模式确定是否对所述目标消息队列进行压缩；其中，所述工作模式包括普通模式和压缩模式，所述普通模式不对所述目标消息队列进行压缩，所述压缩模式为对所述目标消息队列中的所述多个可压缩节点进行压缩。5.根据权利要求4所述的消息处理方法，其特征在于，确定所述目标消息队列的工作模式，包括：判断所述目标消息队列中的所有队列节点的节点数量是否超过预设阈值；如果所述节点数量超过所述预设阈值，则将所述目标消息队列的工作模式切换到所述压缩模式。6.根据权利要求4所述的消息处理方...

【专利技术属性】
技术研发人员：韩志华，
申请(专利权)人：上海哔哩哔哩科技有限公司，
类型：发明
国别省市：