CN112422404A - 消息处理方法及系统 - Google Patents
消息处理方法及系统 Download PDFInfo
- Publication number
- CN112422404A CN112422404A CN202011116689.6A CN202011116689A CN112422404A CN 112422404 A CN112422404 A CN 112422404A CN 202011116689 A CN202011116689 A CN 202011116689A CN 112422404 A CN112422404 A CN 112422404A
- Authority
- CN
- China
- Prior art keywords
- queue
- message
- nodes
- compressible
- node
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/07—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail characterised by the inclusion of specific contents
- H04L51/18—Commands or executable codes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/04—Protocols for data compression, e.g. ROHC
Abstract
本申请实施例公开了一种消息处理方法,所述方法包括:通过目标消息队列存储与多个消息对应的多个队列节点,所述多个队列节点包括多个可压缩节点;压缩所述多个可压缩节点,以得到压缩后的目标消息队列;及消费所述压缩后的目标消息队列中的各个队列节点。本申请实施例可以压缩目标消息队列内部的消息(对应于相应的队列节点)的数量,从而可以提高处理消息的吞吐量,提高消息的处理效率,避免消息过多导致的消息挤压和系统阻塞。
Description
技术领域
本申请涉及数据处理技术领域,尤其涉及一种消息处理方法、系统、计算机设备和计算机可读存储介质。
背景技术
系统内部的数据或消息的生产与消费,通常是基于某一队列线程或线程池消费实现。系统之间则通过专业的消息中间件(如,Kafka)解耦系统间的消息生产与消费,消息中间件会增加系统复杂度和开销,不适用于作为系统内部的消息组件。
当前,系统内部的生产与消费,容易因为消息过多导致消息积压,造成系统阻塞。
发明内容
本申请实施例的目的是提供一种消息处理方法、系统、计算机设备及计算机可读存储介质,用于解决系统内部的生产与消费,易因消息过多导致消息积压,造成系统阻塞的问题。
本申请实施例的一个方面提供了一种消息处理方法,所述方法包括:通过目标消息队列存储与多个消息对应的多个队列节点,所述多个队列节点包括多个可压缩节点;压缩所述多个可压缩节点,以得到压缩后的目标消息队列;及消费所述压缩后的目标消息队列中的各个队列节点。
可选的,所述目标消息队列为多个消息队列之一,所述方法还包括:接收一个或多个消息;根据各个消息的消息标识进行哈希运算,以得到所述各个消息的哈希值;根据所述各个消息的哈希值,将所述各个消息路由到所述多个消息队列中相应的消息队列。
可选的,通过目标消息队列存储多个队列节点,包括:检测是否有待入队的消息;当有所述待入队的消息,则确定所述待入队的消息是否可压缩;当所述待入队的消息可压缩,则根据所述待入队的消息得到携带有相应Key的可压缩节点;当所述待入队的消息不可压缩,则根据所述待入队的消息得到相应的不可压缩节点;及将所述携带有相应Key的可压缩节点或所述相应的不可压缩节点加入到所述目标消息队列中。
可选的,还包括:确定所述目标消息队列的工作模式,以根据所述工作模式确定是否对所述目标消息队列进行压缩;其中,所述工作模式包括普通模式和压缩模式,所述普通模式不对所述目标消息队列进行压缩,所述压缩模式为对所述目标消息队列中的所述多个可压缩节点进行压缩。
可选的,确定所述目标消息队列的工作模式,包括:判断所述目标消息队列中的所有队列节点的节点数量是否超过预设阈值;如果所述节点数量超过所述预设阈值,则将所述目标消息队列的工作模式切换到所述压缩模式。
可选的,当所述目标消息队列处于所述压缩模式时;确定所述目标消息队列的工作模式,包括:判断所述目标消息队列中的所有队列节点的节点数量是否超过预设阈值;如果所述节点数量不超过所述预设阈值,则由所述压缩模式切换为所述普通模式。
可选的,所述多个可压缩节点中的各个可压缩节点分别携带有相应的Key;对所述目标消息队列中的所述多个可压缩节点进行压缩,包括:根据所述各个可压缩节点的Key,将所述多个可压缩节点分为一个或多个分组;及分别将各个分组中的所有可压缩节点压缩为一个单一队列节点。
可选的,还包括:当所述目标消息队列中的一个队列节点被消费之后,则将这个队列节点进行重置;及将这个重置后的队列节点存储到节点工厂中,以用于封装待入队的后续消息。
本申请实施例的一个方面又提供了一种消息处理系统,包括:存储模块,用于通过目标消息队列存储多个队列节点,所述多个队列节点包括多个可压缩节点;压缩模块,用于对所述目标消息队列中的所述多个可压缩节点进行压缩,以得到压缩后的目标消息队列;及消费模块,用于消费所述压缩后的目标消息队列中的各个队列节点。
本申请实施例的一个方面又提供了一种计算机设备,包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现如上述消息处理方法的步骤。
本申请实施例的一个方面又提供了一种计算机可读存储介质,包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现如上述消息处理方法的步骤。
本申请实施例提供的消息处理方法、系统、设备及计算机可读存储介质,可以压缩目标消息队列内部的消息(对应于相应的队列节点)的数量,从而可以提高处理消息的吞吐量,提高消息的处理效率,避免消息过多导致的消息挤压和系统阻塞。
附图说明
图1示意性示出了根据本申请实施例一的消息处理方法的流程图;
图2为图1中步骤S100的子步骤图;
图3为图1中步骤S102的子步骤图;
图4为示意性示出了根据本申请实施例一的消息处理方法的新增步骤流程图;
图5为示意性示出了根据本申请实施例一的消息处理方法的另一新增步骤流程图;
图6示意性示出了根据本申请实施例二的消息处理方法的流程图;
图7为图6中步骤S602的子步骤图;
图8为图6中步骤S602的另一子步骤图;
图9为示意性示出了实现本申请实施例的结构图;
图10示意性示出了目标消息队列的压缩前后对比图;
图11示意性示出了根据本申请实施例三的消息处理系统的框图;及
图12示意性示出了根据本申请实施例四的适于实现消息处理方法的计算机设备的硬件架构示意图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本申请进行进一步详细说明。应当理解,此处所描述的具体实施例仅用以解释本申请,并不用于限定本申请。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
需要说明的是,在本申请实施例中涉及“第一”、“第二”等的描述仅用于描述目的,而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外,各个实施例之间的技术方案可以相互结合,但是必须是以本领域普通技术人员能够实现为基础,当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在,也不在本申请要求的保护范围之内。
系统内部数据或消息的生产与异步消费,通常是基于某一队列线程或线程池消费实现。系统之间则通过专业的消息中间件(如,kafka)解耦系统间的消息生产与消费,消息中间件会增加系统复杂度和开销,不适用于作为系统内部的消息组件。
发明人发现,基于现有技术的系统内部的生产与消费,通常都是单一队列线程或线程池方案,不具备路由、压缩、消费顺序性等功能,消息过多容易积压,造成系统阻塞。有鉴于此,本申请旨在一种轻量级、可自定义路由、可以按顺序消费、可以自动压缩、高吞吐、线程安全的智能数据处理技术,以解决上述问题。
下文将提供多个实施例,下文提供的各个实施例可以用于实现本申请。在本申请的描述中,需要理解的是,步骤前的数字标号并不标识执行步骤的前后顺序,仅用于方便描述本申请及区别每一步骤,因此不能理解为对本申请的限制。
以下提供本文可以涉及的一些术语的术语解释。
消息队列(Queue):是一种消息交互机制,用于线程间、进程间消息的发送和接收,支持FIFO(先进先出,First Input First Output),即从尾部添加元素,从头部删除元素。
多线程:多个线程并发执行的技术,可提升整体处理性能。
线程安全:在拥有共享数据的多条线程并行执行的程序中,线程安全的代码会通过同步机制保证各个线程都可以正常且正确的执行,不会出现数据污染等意外情况。
路由:根据收到数据的目的地址进行定向并转发到另一个接口或组件的过程,这里指接收数据后根据一定规则固定到指定处理器处理。
实施例一
图1示意性示出了根据本申请实施例一的消息处理方法的流程图。可以理解,本申请实施例可以被执行在计算机设备12中。如图2所示,该消息处理方法可以包括步骤S100~S104,其中:
步骤S100,通过目标消息队列存储与多个消息对应的多个队列节点,所述多个队列节点包括多个可压缩节点。
作为示例,所述目标消息队列为先进先出队列,供消费者按照队列顺序进行读取和消费。
作为示例,所述多个队列节点可以包括两类节点,其中一类节点为不可压缩节点(NormalNode),另一类节点为可压缩节点(MergeNode)。也就是说,所述目标消息队列可能包括多个不可压缩节点和多个可压缩节点,或者包括多个可压缩节点。
每个队列节点对应一个消息,其为对相应的消息进行封装后得到的封装体,用于系统内部流转。每个队列节点包括相应的消息以及其他相关信息,如压缩、标记(Key)等。
在示例性的实施例中,如图2所示,所述步骤S100可以包括步骤S200~S208,其中:步骤S200,检测是否有待入队的消息;步骤S202,当有所述待入队的消息,则确定所述待入队的消息是否可压缩;步骤S204,当所述待入队的消息可压缩,则根据所述待入队的消息得到携带有相应Key的可压缩节点;步骤S206,当所述待入队的消息不可压缩,则根据所述待入队的消息得到相应的不可压缩节点;步骤S208,将所述携带有相应Key的可压缩节点或所述相应的不可压缩节点加入到所述目标消息队列中。通过上述步骤,本实施例可以得到所述目标消息节点中的各个不可压缩节点和各个可压缩节点,以用于后续压缩步骤。
步骤S102,压缩所述多个可压缩节点,以得到压缩后的目标消息队列。
计算机设备12可以根据用户自定义的压缩规则,对所述多个压缩节点进行压缩。例如:所述目标消息队列中包括用于通知任务A的处理状态的多个可压缩节点,如“任务A处理中”、“任务A处理中”、“任务A处理中”,则可以将这些可压缩节点压缩为一个队列节点“任务A处理中”,将其余的“任务A处理中”进行丢弃。
在示例性的实施例中,所述多个可压缩节点中的各个可压缩节点分别携带有相应的Key(标记)。如图3所示,所述步骤S102可以包括步骤S300~S302,其中:步骤S300,根据所述各个可压缩节点的Key,将所述多个可压缩节点分为一个或多个分组;及步骤S302,分别将各个分组中的所有可压缩节点压缩为一个单一队列节点。在本实施例中,通过各个可压缩节点的Key,可以实现快速正确地分组压缩。
步骤S104,消费所述压缩后的目标消息队列中的各个队列节点。
可以按照顺序从所述压缩后的目标消息队列中读取和消费其内的各个队列节点。
本申请实施例中所述的消息处理方法,可以包括以下技术优势:
(1)本实施例通过目标消息队列存储各个消息(对应于相应的队列节点),实现了对各个消息的按顺序读取和消费,从而确保了系统内部对各个消息的消费顺序性。
(2)本实施例提供智能数据结构(即,目标消息队列)。该目标消息队列可以压缩内部的队列节点,减少内部的待消费的消息(对应于相应的队列节点)的数量,提高处理消息的吞吐量,提高消息的处理效率,避免消息过多导致的消息挤压和系统阻塞。
(3)本实施例还可以提供用于系统内部的路由方案。
在示例性的实施例中,所述目标消息队列为多个消息队列之一。如图4所示,所述消息处理方法还可以包括步骤S400~S404,其中:步骤S400,接收一个或多个消息;步骤S402,根据各个消息的消息标识进行哈希运算,以得到所述各个消息的哈希值;步骤S404,根据所述各个消息的哈希值,将所述各个消息路由到所述多个消息队列中相应的消息队列。
需要说明的是,所述各个消息可以根据自定义的路由规则路由到指定消费线程中。所述消息标识可以是设备标识(ID,Identity document)以及其它标识。
需要说明的是,通过上述步骤还实现了系统内部的消息并发和异步消费,进一步提高消息吞吐量。
(4)本实施例还可以进一步提供存储优化,以提升性能和吞吐量。
在示例性的实施例中,如图5所示,所述消息处理方法还可以包括步骤S500~S502,其中:步骤S500,当所述目标消息队列中的一个队列节点被消费之后,则将这个队列节点进行重置;步骤S502,将这个重置后的队列节点存储到节点工厂(NodeFactory)中,以用于封装待入队的后续消息。在本实施例中,考虑到消息生产与消费频繁,因此对于队列节点(Node)进行重复利用。当所述目标消息队列中的一个消息(封装在一个队列节点中)消费后,则将这个消息对应的这个队列节点重置放回节点工厂中。当检测到有待入队的一个消息时,则向节点工厂申请一个队列节点。节点工厂会优先返回重置的队列节点,若没有,则创建一个新的队列节点。通过将消费后的队列节点的重置和存储到节点工厂以实现高效重复利用,避免频繁创建队列节点,有效提高性能和吞吐量。
实施例二
本实施例在于提供智能自动压缩方案,可以实时监测消息队列以智能决定是否进行压缩,从而及时减少消息堆积,或恢复全量消费,进而取得消费处理效率和处理量之间的平衡。
如图6所示,该消息处理方法可以包括步骤S600~S604,其中:
步骤S600,通过目标消息队列存储多个队列节点,所述多个队列节点包括多个可压缩节点。
步骤S602,确定所述目标消息队列的工作模式,以根据所述工作模式确定是否对所述目标消息队列进行压缩。
在本实施例中,为所述目标消费队列提供至少两种工作模式:普通模式和压缩模式。
所述普通模式,不对所述目标消息队列进行压缩。
所述压缩模式,为对所述目标消息队列中的所述多个可压缩节点进行压缩。
(1)所述目标消息队列的初始工作模式可以被设置为所述普通模式。
(2)所述目标消息队列可以基于以下步骤从所述普通模式进入到所述压缩模式。
作为示例,如图7所示,所述步骤S602可以包括步骤S700~S702,其中:步骤S700,判断所述目标消息队列中的所有队列节点的节点数量是否超过预设阈值;步骤S702,如果所述节点数量超过所述预设阈值,则将所述目标消息队列的工作模式切换到所述压缩模式。本实施例可以实现将所述目标消息队列智能切换会所述压缩模式,从而减小所述目标消息队列中的队列节点的数量,以减少消息堆积。
(3)所述目标消息队列可以基于以下步骤从所述压缩模式进入到所述普通模式。
作为示例,当所述目标消息队列处于所述压缩模式时,如图8所示,所述步骤S602可以包括步骤S800~S802,其中:步骤S800,判断所述目标消息队列中的所有队列节点的节点数量是否超过预设阈值;步骤S802,如果所述节点数量不超过所述预设阈值,则由所述压缩模式切换为所述普通模式。本实施例可以实现将所述目标消息队列智能切换会所述普通模式,从而对所述目标消息队列中的队列节点进行逐个消费。
步骤S604,如果所述目标消息队列处于普通模式,则逐个消费所述目标消息队列中的各个队列节点。
步骤S606,如果所述目标消息队列处于压缩模式,则压缩所述多个可压缩节点,以得到压缩后的目标消息队列;并消费所述压缩后的目标消息队列中的各个队列节点。
如图9所示,为了使得本申请更加容易理解,以下提供一个示例。
如图9所示,数据处理器作为对外入口,用于接收一个接一个的消息;每个消费者对应一个消费线程,每个消费者对应一个消息队列,实现消息异步消费与智能压缩。在各个消费线程之间,可以通过同步机制保证所述各个消费线程正常且正确的执行(同步从数据处理器获取数据),避免出现数据污染等意外情况,确保线程安全。
以下提供消息A的处理流程:
S1:数据处理器接收消息A。
S2:数据处理器可以根据用户自定义的哈希算法,将消息A路由到对应的消费者(消费者2)中。
S3:消费者向节点工厂申请节点。节点工厂会优先返回重置的节点,若没有,则创建一个新节点。
S4:根据从节点工厂申请到的节点,对消息A进行封装,以得到封装有该消息A的队列节点A’。
S5:将队列节点A’加入到消息队列2中,以供消费者进行消费。
S6:当队列节点A’中的消费A被消费之后,将队列节点A’重置以返回到节点工厂中,供后续消息使用。
需要说明的是,队列节点A’可以是一个不可压缩节点,也可以是一个可压缩节点。当队列节点A’是一个可压缩节点时,则队列节点A’携带有一个相应的Key,作为压缩标记。
消息队列2中可以包括多个不可压缩节点和多个可压缩节点。
消息队列2可以基于两种工作模式实现智能压缩:普通模式与压缩模式。消息队列2的消息容量可以被实时监控并智能切换工作模式,及时减少消息堆积或恢复全量消费。
工作模式转换如下:
(1)消息队列2的初始工作模式为普通模式;
(2)当消息队列2的节点数量超过预设阈值时,消息队列2会自动切换到压缩模式,按照各个可压缩节点的Key进行分组以进行快速压缩。也就是说,过滤之前标记的可被压缩的队列节点,只消费不可压缩节点和压缩后剩下的可压缩节点。如图10所示,消息队列2中包括不可压缩节点1、不可压缩节点2、不可压缩节点3;可压缩节点1-Key1、可压缩节点2-Key1、…、可压缩节点100-Key1;以及可压缩节点1-Key2、可压缩节点2-Key2、…、可压缩节点1000-Key2。对该消息队列2进行压缩如下:(1)保持不可压缩节点1、不可压缩节点2、不可压缩节点3;(2)基于Key1,将可压缩节点1-Key1、可压缩节点2-Key1、…、可压缩节点100-Key1分为一组,并对可压缩节点1-Key1、可压缩节点2-Key1、…、可压缩节点100-Key1进行压缩,即保留这些队列节点中最后加入的可压缩节点100-Key1,删除可压缩节点1-Key1、可压缩节点2-Key1、…、可压缩节点99-Key1;(3)基于Key2,将可压缩节点1-Key2、可压缩节点2-Key2、…、可压缩节点1000-Key2分为另一组,并对可压缩节点1-Key2、可压缩节点2-Key2、…、可压缩节点1000-Key2进行压缩,即保留这些队列节点中最后加入的可压缩节点1000-Key2,删除可压缩节点1-Key2、可压缩节点2-Key2、…、可压缩节点999-Key1。最后,压缩后的消息队列2包括:不可压缩节点1、不可压缩节点2、不可压缩节点3;可压缩节点100-Key1、可压缩节点1000-Key2。
(3)当消息队列2的节点数量没有超过预设阈值时,则从压缩模式切换到普通模式,以恢复全量消费。
实施例三
图11示意性示出了根据本申请实施例三的消息处理系统的框图,该消息处理系统可以被分割成一个或多个程序模块,一个或者多个程序模块被存储于存储介质中,并由一个或多个处理器所执行,以完成本申请实施例。本申请实施例所称的程序模块是指能够完成特定功能的一系列计算机程序指令段,以下描述将具体介绍本实施例中各程序模块的功能。
如图9所示,该消息处理系统1100可以包括存储模块1110、压缩模块1120和消费模块1130,其中:
存储模块1110,用于通过目标消息队列存储与多个消息对应的多个队列节点,所述多个队列节点包括多个可压缩节点;
压缩模块1120,用于对所述目标消息队列中的所述多个可压缩节点进行压缩,以得到压缩后的目标消息队列;及
消费模块1130,用于消费所述压缩后的目标消息队列中的各个队列节点。
在示例性的实施例中,所述存储模块1110,还用于:接收一个或多个消息;根据各个消息的消息标识进行哈希运算,以得到所述各个消息的哈希值;根据所述各个消息的哈希值,将所述各个消息路由到多个消息队列中相应的消息队列。
在示例性的实施例中,所述消息处理系统还包括路由模块,用于:接收一个或多个消息;根据各个消息的消息标识进行哈希运算,以得到所述各个消息的哈希值;根据所述各个消息的哈希值,将所述各个消息路由到多个消息队列中相应的消息队列。
在示例性的实施例中,所述存储模块1110,还用于:检测是否有待入队的消息;当有所述待入队的消息,则确定所述待入队的消息是否可压缩;当所述待入队的消息可压缩,则根据所述待入队的消息得到携带有相应Key的可压缩节点;当所述待入队的消息不可压缩,则根据所述待入队的消息得到相应的不可压缩节点;及将所述携带有相应Key的可压缩节点或所述相应的不可压缩节点加入到所述目标消息队列中。
在示例性的实施例中,所述消息处理系统还包括确定模块,用于:确定所述目标消息队列的工作模式,以根据所述工作模式确定是否对所述目标消息队列进行压缩;其中,所述工作模式包括普通模式和压缩模式,所述普通模式不对所述目标消息队列进行压缩,所述压缩模式为对所述目标消息队列中的所述多个可压缩节点进行压缩。
在示例性的实施例中,所述确定模块,还用于:判断所述目标消息队列中的所有队列节点的节点数量是否超过预设阈值;如果所述节点数量超过所述预设阈值,则将所述目标消息队列的工作模式切换到所述压缩模式。
在示例性的实施例中,当所述目标消息队列处于所述压缩模式时;所述确定模块,还用于:判断所述目标消息队列中的所有队列节点的节点数量是否超过预设阈值;如果所述节点数量不超过所述预设阈值,则由所述压缩模式切换为所述普通模式。
在示例性的实施例中,所述多个可压缩节点中的各个可压缩节点分别携带有相应的Key;所述压缩模块1120还用于:根据所述各个可压缩节点的Key,将所述多个可压缩节点分为一个或多个分组;及分别将各个分组中的所有可压缩节点压缩为一个单一队列节点。
在示例性的实施例中,所述消息处理系统还包括节点存储模块,用于:当所述目标消息队列中的一个队列节点被消费之后,则将这个队列节点进行重置;及将这个重置后的队列节点存储到节点工厂中,以用于封装待入队的后续消息。
实施例四
图10示意性示出了根据本申请实施例四的适于实现消息处理方法的计算机设备12的硬件架构示意图。本实施例中,计算机设备12是一种能够按照事先设定或者存储的指令,自动进行数值计算和/或信息处理的设备。例如,可以是智能手机、平板电脑等。如图10所示,计算机设备12至少包括但不限于:可通过系统总线相互通信链接存储器1210、处理器1220、网络接口1230。其中:
存储器1210至少包括一种类型的计算机可读存储介质,可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如,SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中,存储器1210可以是计算机设备12的内部存储模块,例如该计算机设备12的硬盘或内存。在另一些实施例中,存储器1210也可以是计算机设备12的外部存储设备,例如该计算机设备12上配备的插接式硬盘,智能存储卡(Smart Media Card,简称为SMC),安全数字(Secure Digital,简称为SD)卡,闪存卡(Flash Card)等。当然,存储器1210还可以既包括计算机设备12的内部存储模块也包括其外部存储设备。本实施例中,存储器1210通常用于存储安装于计算机设备12的操作系统和各类应用软件,例如消息处理方法的程序代码等。此外,存储器1210还可以用于暂时地存储已经输出或者将要输出的各类数据。
处理器1220在一些实施例中可以是中央处理器(Central Processing Unit,简称为CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器1220通常用于控制计算机设备12的总体操作,例如执行与计算机设备12进行数据交互或者通信相关的控制和处理等。本实施例中,处理器1220用于运行存储器1210中存储的程序代码或者处理数据。
网络接口1230可包括无线网络接口或有线网络接口,该网络接口1230通常用于在计算机设备12与其他计算机设备之间建立通信链接。例如,网络接口1230用于通过网络将计算机设备12与外部终端相连,在计算机设备12与外部终端之间的建立数据传输通道和通信链接等。网络可以是企业内部网(Intranet)、互联网(Internet)、全球移动通讯系统(Global System of Mobile communication,简称为GSM)、宽带码分多址(Wideband CodeDivision Multiple Access,简称为WCDMA)、4G网络、5G网络、蓝牙(Bluetooth)、Wi-Fi等无线或有线网络。
需要指出的是,图10仅示出了具有部件1210-1230的计算机设备,但是应该理解的是,并不要求实施所有示出的部件,可以替代的实施更多或者更少的部件。
在本实施例中,存储于存储器1210中的消息处理方法还可以被分割为一个或者多个程序模块,并由一个或多个处理器(本实施例为处理器1220)所执行,以完成本申请实施例。
实施例五
本申请还提供一种计算机可读存储介质,计算机可读存储介质其上存储有计算机程序,计算机程序被处理器执行时实现实施例中的消息处理方法的步骤。
本实施例中,计算机可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如,SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中,计算机可读存储介质可以是计算机设备的内部存储单元,例如该计算机设备的硬盘或内存。在另一些实施例中,计算机可读存储介质也可以是计算机设备的外部存储设备,例如该计算机设备上配备的插接式硬盘,智能存储卡(Smart Media Card,简称为SMC),安全数字(Secure Digital,简称为SD)卡,闪存卡(Flash Card)等。当然,计算机可读存储介质还可以既包括计算机设备的内部存储单元也包括其外部存储设备。本实施例中,计算机可读存储介质通常用于存储安装于计算机设备的操作系统和各类应用软件,例如实施例中消息处理方法的程序代码等。此外,计算机可读存储介质还可以用于暂时地存储已经输出或者将要输出的各类数据。
显然,本领域的技术人员应该明白,上述的本申请实施例的各模块或各步骤可以用通用的计算装置来实现,它们可以集中在单个的计算装置上,或者分布在多个计算装置所组成的网络上,可选地,它们可以用计算装置可执行的程序代码来实现,从而,可以将它们存储在存储装置中由计算装置来执行,并且在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样,本申请实施例不限制于任何特定的硬件和软件结合。
需要说明的是,以上仅为本申请的优选实施例,并非因此限制本申请的专利保护范围,凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其他相关的技术领域,均同理包括在本申请的专利保护范围内。
Claims (11)
1.一种消息处理方法,其特征在于,所述方法包括:
通过目标消息队列存储与多个消息对应的多个队列节点,所述多个队列节点包括多个可压缩节点;
压缩所述多个可压缩节点,以得到压缩后的目标消息队列;及
消费所述压缩后的目标消息队列中的各个队列节点。
2.根据权利要求1所述的消息处理方法,其特征在于,所述目标消息队列为多个消息队列之一,所述方法还包括:
接收一个或多个消息;
根据各个消息的消息标识进行哈希运算,以得到所述各个消息的哈希值;
根据所述各个消息的哈希值,将所述各个消息路由到所述多个消息队列中相应的消息队列。
3.根据权利要求1所述的消息处理方法,其特征在于,通过目标消息队列存储多个队列节点,包括:
检测是否有待入队的消息;
当有所述待入队的消息,则确定所述待入队的消息是否可压缩;
当所述待入队的消息可压缩,则根据所述待入队的消息得到携带有相应Key的可压缩节点;
当所述待入队的消息不可压缩,则根据所述待入队的消息得到相应的不可压缩节点;及
将所述携带有相应Key的可压缩节点或所述相应的不可压缩节点加入到所述目标消息队列中。
4.根据权利要求1所述的消息处理方法,其特征在于,还包括:
确定所述目标消息队列的工作模式,以根据所述工作模式确定是否对所述目标消息队列进行压缩;
其中,所述工作模式包括普通模式和压缩模式,所述普通模式不对所述目标消息队列进行压缩,所述压缩模式为对所述目标消息队列中的所述多个可压缩节点进行压缩。
5.根据权利要求4所述的消息处理方法,其特征在于,确定所述目标消息队列的工作模式,包括:
判断所述目标消息队列中的所有队列节点的节点数量是否超过预设阈值;
如果所述节点数量超过所述预设阈值,则将所述目标消息队列的工作模式切换到所述压缩模式。
6.根据权利要求4所述的消息处理方法,其特征在于,当所述目标消息队列处于所述压缩模式时;
确定所述目标消息队列的工作模式,包括:
判断所述目标消息队列中的所有队列节点的节点数量是否超过预设阈值;
如果所述节点数量不超过所述预设阈值,则由所述压缩模式切换为所述普通模式。
7.根据权利要求1至6任意一项所述的消息处理方法,其特征在于,所述多个可压缩节点中的各个可压缩节点分别携带有相应的Key;对所述目标消息队列中的所述多个可压缩节点进行压缩,包括:
根据所述各个可压缩节点的Key,将所述多个可压缩节点分为一个或多个分组;及
分别将各个分组中的所有可压缩节点压缩为一个单一队列节点。
8.根据权利要求1至6任意一项所述的消息处理方法,其特征在于,还包括:
当所述目标消息队列中的一个队列节点被消费之后,则将这个队列节点进行重置;及
将这个重置后的队列节点存储到节点工厂中,以用于封装待入队的后续消息。
9.一种消息处理系统,其特征在于,包括:
存储模块,用于通过目标消息队列存储与多个消息对应的多个队列节点,所述多个队列节点包括多个可压缩节点;
压缩模块,用于对所述目标消息队列中的所述多个可压缩节点进行压缩,以得到压缩后的目标消息队列;及
消费模块,用于消费所述压缩后的目标消息队列中的各个队列节点。
10.一种计算机设备,所述计算机设备包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序,其特征在于,所述处理器执行所述计算机程序时用于实现权利要求1至8中任一项所述的消息处理方法的步骤。
11.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质内存储有计算机程序,所述计算机程序可以被至少一个处理器所执行,以使得所述至少一个处理器执行权利要求1至8中任一项所述的消息处理方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011116689.6A CN112422404B (zh) | 2020-10-19 | 2020-10-19 | 消息处理方法及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011116689.6A CN112422404B (zh) | 2020-10-19 | 2020-10-19 | 消息处理方法及系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN112422404A true CN112422404A (zh) | 2021-02-26 |
CN112422404B CN112422404B (zh) | 2022-08-19 |
Family
ID=74840220
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202011116689.6A Active CN112422404B (zh) | 2020-10-19 | 2020-10-19 | 消息处理方法及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN112422404B (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113467718A (zh) * | 2021-06-25 | 2021-10-01 | 北京达佳互联信息技术有限公司 | 一种数据处理方法、装置、电子设备及存储介质 |
CN115361454A (zh) * | 2022-10-24 | 2022-11-18 | 北京智芯微电子科技有限公司 | 消息序列编码、解码、传输方法及编码、解码设备 |
Citations (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8369324B1 (en) * | 2008-09-29 | 2013-02-05 | Avaya Inc. | Variable compression queue |
US20140337442A1 (en) * | 2013-05-10 | 2014-11-13 | Oracle International Corporation | Cloud messaging services optimization through adaptive message compression |
CN104468509A (zh) * | 2014-10-29 | 2015-03-25 | 北方工业大学 | 手机网络游戏数据传输的方法、系统和手机用户端 |
CN105956183A (zh) * | 2016-05-30 | 2016-09-21 | 广东电网有限责任公司电力调度控制中心 | 一种分布式数据库中海量小文件的多级优化存储方法及系统 |
CN106776967A (zh) * | 2016-12-05 | 2017-05-31 | 哈尔滨工业大学(威海) | 基于时序聚合算法的海量小文件实时存储方法及装置 |
CN106803841A (zh) * | 2017-02-14 | 2017-06-06 | 北京奇虎科技有限公司 | 消息队列数据的读取方法、装置及分布式数据存储系统 |
CN107872398A (zh) * | 2017-06-25 | 2018-04-03 | 平安科技(深圳)有限公司 | 高并发数据处理方法、装置及计算机可读存储介质 |
CN109445965A (zh) * | 2018-11-07 | 2019-03-08 | 北京明朝万达科技股份有限公司 | 由Redis和MySQL实现的消息处理方法和设备 |
CN109614248A (zh) * | 2018-12-03 | 2019-04-12 | Oppo广东移动通信有限公司 | 消息压缩方法、装置、存储介质及终端设备 |
US20190124180A1 (en) * | 2017-10-20 | 2019-04-25 | Hewlett Packard Enterprise Development Lp | Packet compression and decompression |
CN110134550A (zh) * | 2019-05-15 | 2019-08-16 | 腾讯科技(深圳)有限公司 | 一种数据处理方法、装置以及计算机可读存储介质 |
CN111212390A (zh) * | 2019-12-23 | 2020-05-29 | 北京健康之家科技有限公司 | 消息队列的处理方法、装置及设备 |
CN111541749A (zh) * | 2020-04-14 | 2020-08-14 | 杭州涂鸦信息技术有限公司 | 一种嵌入式设备的数据通信方法、系统及相关设备 |
-
2020
- 2020-10-19 CN CN202011116689.6A patent/CN112422404B/zh active Active
Patent Citations (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8369324B1 (en) * | 2008-09-29 | 2013-02-05 | Avaya Inc. | Variable compression queue |
US20140337442A1 (en) * | 2013-05-10 | 2014-11-13 | Oracle International Corporation | Cloud messaging services optimization through adaptive message compression |
CN104468509A (zh) * | 2014-10-29 | 2015-03-25 | 北方工业大学 | 手机网络游戏数据传输的方法、系统和手机用户端 |
CN105956183A (zh) * | 2016-05-30 | 2016-09-21 | 广东电网有限责任公司电力调度控制中心 | 一种分布式数据库中海量小文件的多级优化存储方法及系统 |
CN106776967A (zh) * | 2016-12-05 | 2017-05-31 | 哈尔滨工业大学(威海) | 基于时序聚合算法的海量小文件实时存储方法及装置 |
CN106803841A (zh) * | 2017-02-14 | 2017-06-06 | 北京奇虎科技有限公司 | 消息队列数据的读取方法、装置及分布式数据存储系统 |
CN107872398A (zh) * | 2017-06-25 | 2018-04-03 | 平安科技(深圳)有限公司 | 高并发数据处理方法、装置及计算机可读存储介质 |
US20190124180A1 (en) * | 2017-10-20 | 2019-04-25 | Hewlett Packard Enterprise Development Lp | Packet compression and decompression |
CN109445965A (zh) * | 2018-11-07 | 2019-03-08 | 北京明朝万达科技股份有限公司 | 由Redis和MySQL实现的消息处理方法和设备 |
CN109614248A (zh) * | 2018-12-03 | 2019-04-12 | Oppo广东移动通信有限公司 | 消息压缩方法、装置、存储介质及终端设备 |
CN110134550A (zh) * | 2019-05-15 | 2019-08-16 | 腾讯科技(深圳)有限公司 | 一种数据处理方法、装置以及计算机可读存储介质 |
CN111212390A (zh) * | 2019-12-23 | 2020-05-29 | 北京健康之家科技有限公司 | 消息队列的处理方法、装置及设备 |
CN111541749A (zh) * | 2020-04-14 | 2020-08-14 | 杭州涂鸦信息技术有限公司 | 一种嵌入式设备的数据通信方法、系统及相关设备 |
Non-Patent Citations (1)
Title |
---|
王静逸等: "一种分布式智能核心结构及其系统应用", 《计算机辅助工程》 * |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113467718A (zh) * | 2021-06-25 | 2021-10-01 | 北京达佳互联信息技术有限公司 | 一种数据处理方法、装置、电子设备及存储介质 |
CN113467718B (zh) * | 2021-06-25 | 2024-03-26 | 北京达佳互联信息技术有限公司 | 一种数据处理方法、装置、电子设备及存储介质 |
CN115361454A (zh) * | 2022-10-24 | 2022-11-18 | 北京智芯微电子科技有限公司 | 消息序列编码、解码、传输方法及编码、解码设备 |
CN115361454B (zh) * | 2022-10-24 | 2023-03-24 | 北京智芯微电子科技有限公司 | 消息序列编码、解码、传输方法及编码、解码设备 |
Also Published As
Publication number | Publication date |
---|---|
CN112422404B (zh) | 2022-08-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9495229B2 (en) | Methods, apparatus and computer programs for managing persistence | |
CN112422404B (zh) | 消息处理方法及系统 | |
CN111045810B (zh) | 一种任务调度处理方法及装置 | |
US9385948B2 (en) | Packet processing method, device and system | |
EP2493118A1 (en) | Information processing system | |
CN108834086B (zh) | 短信发送的方法、装置、计算机设备和存储介质 | |
CN108491301B (zh) | 电子装置、基于redis的异常预警方法及存储介质 | |
CN108388438B (zh) | 系统基表更新方法、装置、计算机设备和存储介质 | |
WO2019192133A1 (zh) | 电子装置、数据链路风险预警方法及存储介质 | |
EP3687204A1 (en) | Buffer status reporting method, terminal, and computer storage medium | |
CN113660173B (zh) | 一种流量控制方法、装置、计算机设备及存储介质 | |
US10715628B2 (en) | Attribute operating method and device | |
CN103677988A (zh) | 用于软件系统的多进程通讯方法及系统 | |
CN111490947A (zh) | 数据包发送方法、数据包接收方法、系统、设备及介质 | |
EP3174318A1 (en) | Method for realizing resource attribute notification, and common service entity | |
CN114035987A (zh) | 基于消息队列的数据传输方法、装置、电子设备及介质 | |
CN111580948A (zh) | 任务调度方法、装置及计算机设备 | |
CN111614577A (zh) | 一种多通信任务管理方法、装置和计算机设备 | |
US9596131B2 (en) | Method for transiting operation mode of routing processor | |
CN113179304B (zh) | 消息下发方法、系统、设备及存储介质 | |
CN107547412B (zh) | 一种stp计算方法和装置 | |
EP3148133A1 (en) | Load control method and apparatus for notification messages | |
CN108121580B (zh) | 应用程序通知服务的实现方法及装置 | |
CN106302184B (zh) | 一种流表项下发方法、流表项保存方法、相关装置和系统 | |
CN112512031B (zh) | 一种应用于5g网络的数据采集方法和5g网络 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |