通知消息处理方法及装置与流程

文档序号:12278385阅读:637来源:国知局
通知消息处理方法及装置与流程

本发明涉及通信领域,具体一种通知消息处理方法及装置。



背景技术:

在分布式环境中,各个进程需要通过网络来交互各自的信息,协调相关的处理,为了提高消息的处理效率,在目前的多核主机上都会采用多线程的方式来处理消息通知,但在多线程处理通知消息的过程中,需要保证线程处理各通知消息的顺序与接收到各通知消息的顺序一致,否则就会造成业务逻辑出现问题;现有的多线程处理通知消息的方式在大型分布式系统中很难保证上述要求且进行通知消息处理所占用的线程多,系统资源利用率低。

因此在多线程处理通知消息过程中如何保证上述要求且尽可能占用较少线程以提升资源利用率就显得尤为重要。



技术实现要素:

本发明要解决的主要技术问题是,提供一种通知消息处理方法及装置,解决现有多线程处理通知消息难保证处理通知消息的顺序与接收通知消息的顺序一致,且资源利用率低的问题。

为解决上述技术问题,本发明提供一种通知消息处理方法,包括:

监测各保序队列中是否有存入新通知消息;所述各保序队列用于根据预设规则按序存储相应的通知消息;

监测到某一保序队列存入新通知消息时,从线程池中选择空闲状态的工作线程模块;

所述工作线程模块对所述保序队列存入的所述新通知消息进行处理。

在本发明的一种实施例中,所述工作线程模块处理完所述新通知消息后,还包括:

判断所述保序队列是否还有未处理的新通知消息,如有,对未处理的新通知消息继续处理。

在本发明的一种实施例中,如判断所述保序队列中没有未处理的新通知消息,开始计时监测在等待时间阈值t内所述保序队列是否接收到新通知消息,如有,则对该新通知消息继续处理。

在本发明的一种实施例中,在所述等待时间阈值t内所述保序队列没有接收到新通知消息时,所述工作线程模块回归所述线程池。

在本发明的一种实施例中,还包括:对所述线程池中的各工作线程模块的生命周期和/或工作状态进行维护。

为了解决上述问题,本发明还提供了一种通知消息处理装置,包括:

监测线程模块,用于监测各保序队列中是否有存入新通知消息;所述各保序队列用于根据预设规则按序存储相应的通知消息;

线程选择模块,用于在所述监测线程模块监测到某一保序队列存入新通知消息时,从线程池中选择空闲状态的工作线程模块;

工作线程模块,用于对所述保序队列存入的所述新通知消息进行处理。

在本发明的一种实施例中,所述工作线程模块包括消息处理子模块和判断子模块;

所述处理子模块用于对所述新通知消息进行处理;

所述判断子模块用于在所述处理子模块对所述新通知消息进行处理后,判断所述保序队列是否还有未处理的新通知消息,如有,通知所述处理子模块对 为处理的新通知消息继续处理。

在本发明的一种实施例中,所述工作线程模块还包括监测子模块,用于在所述判断子模块判断所述保序队列中没有未处理的新通知消息时,开始计时监测在等待时间阈值t内所述保序队列是否接收到新通知消息,如有,则通知所述处理子模块对该新通知消息继续处理。

在本发明的一种实施例中,所述监测子模块还用于在所述等待时间阈值t内所述保序队列没有接收到新通知消息时,将所述工作线程模块回归所述线程池。

在本发明的一种实施例中,还包括线程池维护模块,用于对所述线程池中的各工作线程模块的生命周期和/或工作状态进行维护。

本发明的有益效果是:

本发明提供的通知消息处理方法及装置,首先利用保序队列根据预设规则按序存储相应的通知消息,这样可以保证对各保护序列中的通知消息进行处理时的处理顺序与接收到各通知消息的顺序一致;然后监测各保对序列中是否有存入新通知消息,当监测到某一保序队列存入新通知消息时,从线程池中选择出当前工作状态为空闲状态的工作线程模块,利用该工作线程模块对该保序队列存入的新通知消息进行处理。采用线程池可以实现对线程池中的工作线程的复用,保证能使用原少于保序队列数据的线程就能有效的完成对全部通知消息的处理,提升系统资源利用率。

附图说明

图1为本发明实施例一提供的通知消息处理过程流程示意图一;

图2为本发明实施例一提供的通知消息处理过程流程示意图二;

图3为本发明实施例二提供的通知消息处理装置结构示意图一;

图4为本发明实施例二提供的通知消息处理装置结构示意图二。

具体实施方式

下面通过具体实施方式结合附图对本发明作进一步详细说明。

实施例一:

本实施例利用各通知消息的特点,采用保序队列对按照预设规则按序(也即按照接收到各通知消息的时间先后)存储相应的通知消息,以保证这后续对各保护序列中的通知消息进行处理时的处理顺序与接收到各通知消息的顺序一致,保证业务逻辑的准确无误,进而保证业务的正常进行。应当理解的是,本实施例中的预设规则可以根据具体的消息类型和/或应用场景进行灵活设定;例如,对于SNMP(Simple Network Management Protocol,简单网络管理协议)TRAP消息,当发生告警风暴时,会上报来自多个设备的大量告警通知信息,此时就可将各告警通知消息会按照消息的源IP地址存入到不同的保序队列中,各保序队列之间的通知消息可以并发的进行处理,且每个保序队列中的通知消息都按照到达的先后次序进行处理。

另外,考虑到大型分布系统中需要较多的这种保序队列对各通知消息按照预设规则进行有序存储,因此如果为每个保序队列指定用一个固定的工作线程处理通知消息的话,就会占用大量的工作线程,消耗很多的系统资源。由于在所有保序队列中,同时处于有新通知消息到达状态的保序队列的数量是相当有限的,因此本实施例提出采用线程池,且通过少量活动的监测线程来完成各个保序队列消息状态的监控,在监测到某一保序队列有新的通知消息到达时,则从线程池选择出工作状态为空闲状态的工作线程模块对该保护队列中的新通知消息进行处理,处理完后则可回归线程池等待下一次或者其他保序列队的调用,这样采用线程池可以实现对线程池中的工作线程的复用,保证能使用原少于保序队列数据的线程就能有效的完成对全部通知消息的处理,提升系统资源利用 率。上述过程请参见图1所示,具体包括:

步骤101:监测各保序队列中是否有存入新通知消息;如上所示,此处的各保序队列用于根据预设规则按序存储相应的通知消息,此处的按序是指按接收到各通知消息的先后顺序;

步骤102:监测到某一保序队列有存入新通知消息时,从线程池中选择空闲状态的工作线程模块;

步骤103:选择出的工作线程模块对该保序队列存入的新通知消息进行处理。

请参见图2所示,在本实施例中,在上述步骤103工作线程模块处理完新通知消息后,还包括:

步骤104:判断该保序队列是否还有未处理的新通知消息,如有,则该新通知消息则是工作线程模块处理之前存入的新通知消息过程中新存入的,转至步骤105;否则,转至步骤106;

步骤105,对未处理的新通知消息继续处理后,转回步骤104继续判断;

步骤106:开始计时监测,在等待时间阈值t内保序队列是否接收到新通知消息,如有,转至步骤107;否则,转至步骤108;

步骤107:对该新通知消息继续处理后,转至步骤104。

步骤108:工作线程模块回归线程池。

在上述步骤106的中,仅由工作线程模块对该保序队列进行监测,监测线程在此期间不再对该保序队列进行监测,但仍对其他保序队列进行监测;在上述步骤108之后,该保序队列的监测则继续转交由监测线程执行。

通过上述步骤104-108,可以保证同一保序队列中的通知消息尽量由同一工作线程模块进行处理,从而降低线程上下文的切换,提升处理效率,降低系统处理性能的损耗。

本实施例中,在上述步骤过程中,还包括对线程池中的各工作线程模块的生命周期和/或工作状态进行维护的步骤,具体维护的规则和方式都可根据具体的应用场景等灵活选择,此处不再赘述。

实施例二:

本实施例提供一种通知消息处理装置,请参见图3所示,包括:

保护队列模块1,用于根据预设规则将各通知消息按序存(也即按照接收到各通知消息的时间先后)储到各保序队列中,以保证这后续对各保护序列中的通知消息进行处理时的处理顺序与接收到各通知消息的顺序一致,保证业务逻辑的准确无误,进而保证业务的正常进行;应当理解的是,本实施例中的预设规则可以根据具体的消息类型和/或应用场景进行灵活设定;

监测线程模块2,用于监测各保序队列中是否有存入新通知消息;

线程选择模块3,用于在监测线程模块监测到某一保序队列存入新通知消息时,从线程池中选择空闲状态的工作线程模块4;

工作线程模块4,用于对该保序队列存入的新通知消息进行处理。

其中,工作线程模块4包括消息处理子模块41、判断子模块42和监测子模块43;

处理子模块41用于对保序队列中的新通知消息进行处理;

判断子模块42用于在处理子模块41对新通知消息进行处理后,判断保序队列是否还有未处理的新通知消息,如有,通知处理子模块对为处理的新通知消息继续处理;否则,通知监测子模块43;

监测子模块43用于在判断子模块42判断保序队列中没有未处理的新通知消息时,开始计时监测在等待时间阈值t内保序队列是否接收到新通知消息,如有,则通知处理子模块41对该新通知消息继续处理;否则,将该工作线程模块回归线程池。在监测子模块43对该保序队列监测过程中,监测线程模块2在此期间不再对该保序队列进行监测;在该工作线程模块回归线程池后,该保序队列的监测则继续转交由监测线程模块2执行。

可见,本实施例中的工作线程模块4可以保证同一保序队列中的通知消息尽量由同一工作线程模块进行处理,从而降低线程上下文的切换,提升处理效 率,降低系统处理性能的损耗。

请参见图4所示,本实施例中的通知消息处理装置还包括线程池维护模块5,用于对所线程池中的各工作线程模块的生命周期和/或工作状态进行维护,具体维护的规则和方式都可根据具体的应用场景等灵活选择,此处不再赘述。

可见,本发明实施以事件驱动模型为理论基础,采用了两层事件驱动机制(分别为监测新通知消息到来事件和处理该新通知消息的工作线程选择处理事件),在保证通知信息有序处理的前提下,同时利用了多线程在处理性能的优势,并且在整个处理流程中,不涉及对锁资源的竞争,并且减少了线程上下文的切换,同时采用了线程池,达到了线程复用的目的,保证了能使用远少于保序队列数目的线程,就能完成对全部通知消息的处理。

以上内容是结合具体的实施方式对本发明所作的进一步详细说明,不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干简单推演或替换,都应当视为属于本发明的保护范围。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1