一种多通信任务管理方法、装置和计算机设备与流程

本申请涉及通信技术领域，特别是涉及一种多任务通信管理方法、装置和计算机设备。

背景技术：

在各类通信系统中，尤其是在无线通信系统中，经常需要通过多个设备和/或业务间的通信获得系统或网络维护和管理所需的各类数据。比如服务器在监测网络设备的组件工作状态、设备健康度等数据时，ad-hoc、mesh网络中设备在与邻域节点交换路由、定位等信息时，边缘网络在上报态势信息时，都可能出现一个或多个设备同时作为接收端和发送端处理多个通信任务的情况。

目前在处理多个通信任务时采用的方式是：发送方针对一个接收设备中的一项业务建立一个独立消息队列，并建立单独的通信进程按队列顺序发送消息数据；接收方收到消息数据后将其存储到该业务的消息队列，从对应业务进程获取消息数据请求的数据并向发送方返回。随着系统或网络中设备和业务类型的增多，由于上述管理多通信任务的方式需要建立大量的通信进程，由于系统或网络中通信实现方式众多、技术各异，容易导致资源管理实现困难；在ad-hoc、mesh等需要通过大量设备、应用、组件间定时通信实现网络维护的网络中，上述方式会占用大量设备和网络资源，影响用户数据传输。

技术实现要素：

基于此，有必要针对上述技术问题，提供一种能够统一管理多个通信任务的多通信任务管理方法、装置和存计算机设备。

一种多通信任务管理方法，包括：

发送消息时：

根据定时需求生成消息数据，该消息数据包括通信需求编号、定时周期、目的地址以及通信业务数据需求，通过进程间通信将消息数据传输至统一输出服务；

根据通信需求编号，将消息数据保存至预先为统一输出服务配置的输出集中缓存中对应的消息发送队列，使用消息提取器从消息发送队列提取消息数据，根据消息数据的目的地址，将消息数据发送给消息接收端；

接收消息时：

接收消息发送端发送的消息数据，并将消息数据传输至统一输入服务，根据通信需求编号将消息数据存储至预先为统一输入服务配置的输入集中缓存中对应的消息接收队列，使用消息提取器从消息接收队列提取消息数据，使用进程间通信将消息数据传输给消息数据中通信业务数据需求对应的消息终点服务进程。

其中一个实施例中，其特征在于，在使用消息提取器从消息发送队列提取消息数据时，还包括：根据在预设时间内从消息发送队列提取所述消息数据的次数和消息发送队列对应的定时需求的定时周期，计算消息发送队列的处理频度值；使用消息提取器根据处理频度值从消息发送队列提取消息数据。

其中一个实施例中，在使用消息提取器从消息接收队列提取消息数据时，还包括：根据在预设时间内从消息发送队列中提取消息数据的次数和消息接收队列对应的定时需求的定时周期，计算该消息接收队列的处理频度值；使用消息提取器根据处理频度值从消息接收队列提取消息数据。

其中一个实施例中，还包括：根据在预设时间内从消息发送队列中提取消息数据的次数和该消息发送队列对应的定时需求的定时周期，计算该消息发送队列的处理频度值；检测输出集中缓存中消息数据的数量，当消息数据的数量等于预先配置的数量时，删除处理频度值最高的消息发送队列中存储时间最早的消息数据。

其中一个实施例中，还包括：根据在预设时间内从消息接收队列中提取消息数据的次数和该消息接收队列对应的定时需求的定时周期，计算该消息接收队列的处理频度值；检测输入集中缓存中消息数据的数量，当消息数据的数量等于预先配置的数量时，删除处理频度值最高的消息接收队列中存储时间最早的消息数据。

其中一个实施例中，还包括：检测输出集中缓存中消息数据的数量，当消息数据的数量等于预先配置的数量时，删除处理频度值最高的消息发送队列中存储时间最早的消息数据的步骤还包括：当处理频度值最高的消息发送队列有多个时，删除这些消息发送队列中，定时周期最短且存储时间最早的消息数据。

其中一个实施例中，还包括：检测输入集中缓存中消息数据的数量，当消息数据的数量等于预先配置的数量时，删除处理频度值最高的消息接收队列中存储时间最早的消息数据的步骤还包括：当处理频度值最高的消息接收队列有多个时，删除这些消息接收队列中，定时周期最短且存储时间最早的消息数据。

其中一个实施例中，还包括：检测消息发送队列和/或消息接收队列中消息数据的新增数量；当在预设时间内该新增数量为零时，删除该消息发送队列和/或消息接收队列中的消息数据。

一种多定时通信任务管理装置，包括消息发送端和消息接收端，

消息发送端包括：

定时通信消息源，用于根据定时需求生成消息数据，消息数据包括通信需求编号、定时周期、目的地址以及通信业务数据需求，通过进程间通信将消息数据传输至统一输出服务；

统一输出服务模块，用于根据通信需求编号，将消息数据保存至预先为统一输出服务配置的输出集中缓存中对应的消息发送队列，使用消息提取器从消息发送队列提取消息数据，根据消息数据的目的地址，将消息数据发送给消息接收端；

消息接收端包括：

统一输入服务模块：用于接收消息发送端发送的消息数据，并将消息数据传输至统一输入服务，根据通信需求编号将消息数据存储至预先为统一输入服务配置的输入集中缓存中对应的消息接收队列，使用消息提取器从消息接收队列提取消息数据，使用进程间通信将消息数据传输给通信业务数据需求对应的消息终点服务进程。

一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现上述任意一个实施例中所述方法的步骤。

上述多通信任务管理方法、装置和计算机设备针对不同的定时需求定义了统一格式的消息数据，基于该消息数据实现进程间通信，实现了对不同定时需求的通信消息的无差别传输，可解决由于系统或网络中通信实现方式众多、技术各异导致的资源管理代码分散、实现维护困难等问题；在统一输出服务与统一输入服务中分别使用集中缓存集中存储消息数据，使用消息提取器提取集中缓存中的消息数据，这样不仅可以统一管控协调各消息缓存，还可以避免传统多任务通信管理方式中针对一项定时通信需求单独建立至少一个消息通信通道造成的大量占用设备和网络资源的问题。

附图说明

图1为一个实施例中多通信任务管理方法的应用场景示意图；

图2为一个实施例中多通信任务管理方法的步骤流程图；

图3为另一个实施例中多通信任务管理方法的应用场景图；

图4为另一个实施例中多通信任务管理方法的应用场景示意图；

图5为一个实施例中多通信任务管理装置的逻辑框图；

图6为另一个实施例中多通信任务管理装置的逻辑框图；

图7为另一个实施例中多通信任务管理装置的逻辑框图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请提供的多通信任务管理方法可运用在如图1所示的场景中。其中，设备102、设备104、设备106等多个设备通过有线和/或无线通信方式进行设备间通信。其中，各设备可以但不限于是各种嵌入式通信设备、服务器、个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备。

具体的，设备102为实现本地功能需要多定时与设备104、设备106等进行通信，其中，设备102为通信任务发起方，设备104、设备106等为通信任务响应方。

在其中一个实施例中，如图2所示，提供了一种多通信任务管理方法。以该方法应用于图1所示场景中设备102和设备104间的多通信任务为例进行说明，如图3所示，包括以下步骤：

步骤202：根据定时需求生成消息数据，该消息数据包括通信需求编号、定时周期、目的地址以及通信业务数据需求，通过进程间通信将消息数据传输至统一输出服务；

设备102启动设置在本地的定时通信源服务和统一输出服务。定时通信消息源服务与统一输出服务间通过统一输出服务请求端口和统一输出服务接收端口进行进程间通信。统一输出服务在启动时，创建一个独立于统一输出服务主线程的消息提取线程即消息提取器，消息提取线程执行循环，每执行一次循环体就检查一次集中缓存中的各个消息发送队列，并尝试从一个非空队列中提取一个消息待用。

定时通信源根据设备102本地的定时需求生成消息数据，包括通信需求编号、定时周期、目的地址以及通信业务数据需求，通过进程间通信将生成的消息数据传输至统一输出服务，统一输出服务将收到的消息存储至集中缓存。

其中，消息数据中的通信需求编号和不同的定时需求唯一对应，用于标识设备102向系统或网络中其它设备获取的业务数据类型，包括设备工作状态数据、健康状态数据、服务资源数据等，以及设备间通信链路状态数据、路由数据等；定时周期用于标识该定时需求消息数据的生成周期，定时周期越长该定时需求发送消息的频率越低；目的地址用于标识该消息的通信目标接收设备，比如设备104或106或其它接收通信消息的设备地址；通信业务数据需求用于描述该定时需求从目的地址标识的通信目标接收设备获取的通信业务数据。这里消息数据的数据结构没有具体规定，只要求对设备102中所有定时需求生成统一格式的消息，以保证能对不同定时需求的通信消息进行无差别的传输即可。另外，由于各定时需求要求不同，各定时需求的消息数据中通信业务数据需求各异，为方便进行无差别处理，也对其进行统一序列化目标格式处理。

步骤204：根据通信需求编号，将消息数据保存至预先为统一输出服务配置的输出集中缓存中对应的消息发送队列，使用消息提取器从消息发送队列提取消息数据，根据消息数据的目的地址，将消息数据发送给消息接收端；

设备102的统一输出服务在存储收到的消息数据时，按照其通信需求编号将其存储到输出集中缓存中对应的消息发送队列中；若没有对应的消息发送队列则新建一个，将该消息数据存储在新建的消息发送队列中。统一输出服务的消息提取器从消息发送队列中提取消息，通过统一输入服务请求端口建立设备间通信发送给设备104。消息提取器在从消息发送队列中提取消息时，可以按照预设的规则确定消息提取的顺序，例如按照各消息发送队列中消息数据的存储时间从早到晚的顺序，依次进行提取。

步骤206：接收消息发送端发送的消息数据，并将消息数据传输至统一输入服务，根据通信需求编号将消息数据存储至预先为统一输入服务配置的输入集中缓存中对应的消息接收队列，使用消息提取器从消息接收队列提取消息数据，使用进程间通信将消息数据传输给消息数据中通信业务数据需求对应的消息终点服务进程。

设备104启动设置在本地的统一输入服务，并为统一输入服务分配输入集中缓存。统一输入服务与设备104本地提供定时需求所需的各类业务数据的服务通过消息终点服务请求端和消息终点服务接收端进行进程间通信。统一输入服务在启动时，创建一个独立于统一输入服务主线程的消息提取器，消息提取器执行循环，每执行一次循环体就检查一次输入集中缓存中的各个非空消息队列，并尝试从一个队列中提取一个消息待用。

设备104通过统一输入服务接收端接收设备102发送的消息数据后，按照其通信需求编号将其存储到输入集中缓存中对应的消息接收队列中；若没有对应的消息接收队列则新建一个，将该消息数据存储在新建的消息接收队列中。统一输入服务的消息提取器从消息接收队列中提取消息，通过进程间通信发送给对应的消息终点服务接收端。同样地，消息提取器在从消息接收队列中提取消息时，可以按照预设的规则确定消息提取的顺序，例如按照各消息接收队列中消息数据的存储时间从早到晚的顺序，依次进行提取。

消息终点服务根据消息数据的数据内容生成相应的业务数据，生成响应消息返回给设备102。至此，设备102通过基于统一格式消息数据的设备间通信从设备102获得了定时需求所需的业务数据。

上述多通信任务管理方法针对不同的定时需求定义了统一格式的消息数据，基于该消息数据实现进程间通信，实现了对不同定时需求的通信消息的无差别传输。设备102和设备104通过增加统一输出服务、统一输入服务，根据定时需求添加定时通信消息源和定时通信终点服务，并指定各服务间对应的通信端口，就能使用上述方法对多通信任务进行统一的管理，可解决由于系统或网络中通信实现方式众多、技术各异导致的资源管理代码分散、实现困难等问题；使用集中缓存集中存储消息数据，在统一输出服务和统一输入服务中分别使用一个消息提取器提取序列化通信信息，对提取的消息进行后续处理，可以避免传统多任务通信管理方式中每针对一项定时通信需求单独建立一个消息处理与传输通道造成的大量占用设备和网络资源的问题。

应该理解的是，虽然图2的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

其中一个实施例中，在使用消息提取器从消息发送队列提取消息数据时，还包括：根据在预设时间内从消息发送队列提取所述消息数据的次数和消息发送队列对应的定时需求的定时周期，计算消息发送队列的处理频度值；使用消息提取器根据处理频度值从消息发送队列提取消息数据。

其中一个实施例中，在使用消息提取器从消息接收队列提取消息数据时，还包括：根据在预设时间内从消息发送队列中提取消息数据的次数和消息接收队列对应的定时需求的定时周期，计算该消息接收队列的处理频度值；使用消息提取器根据处理频度值从消息接收队列提取消息数据。

在许多通信系统中，设备间需要定时通信或周期重复通信以实现系统或网络的维护、管理等功能，例如定时检测设备工作状态、周期性上报汇集网络态势信息等。这种情况下，设备102、104的集中缓存中可能同时存在多个消息序列；并且受到设备消息处理速度的影响，各消息队列中可能有多个通信消息。

针对上述情况，本实施例提供了消息提取器提取消息数据的顺序策略，即根据消息队列的处理频度值确定从哪一个消息数据队列提取消息数据。

以设备102的为例，设备102首先计算各消息发送队列的处理频度值。处理频度是指在最近一段长度的时间内，从一个消息发送队列提取消息数据的次数和该消息发送队列对应的定时需求要求的消息处理周期之间的关系，可以表示为

其中，δt为最近一段长度的时间，n为该时间内从一个消息队列提取消息的次数，t为该消息队列对应的定时需求的处理周期。f越大，说明在最近的该段时间内对该消息队列的实际处理次数越接近要求的次数，反之则说明实际处理次数与要求的处理次数差距越大。

设备102在从消息接收队列提取消息时，由统一输出入服务建立消息提取器，从非空并且处理频度值最低的消息发送队列中提取一个消息。通过指定上述消息数据获取策略，可以确保设备102在发送消息数据时，选择发送次数和系统要求差距最大的任务类型，并且首先发送其中被处理频度低的队列的消息数据，以确保各消息定时源所在设备能较公平地获得发送各定时需求的消息数据，确保设备获得的业务数据种类齐全、各种类业务数据的获取时间线相对统一，提供及时、完整的设备功能。

同样地，设备104统一输入服务的消息提取器同样采用上述策略从消息接收队列中提取消息数据，以确保各消息定时源所在设备能较公平地获得各定时需求所需的业务数据，确保设备获得的业务数据种类齐全、各种类业务数据的获取时间线相对统一，提供及时、完整的设备功能。

其中一个实施例中，还包括：根据在预设时间内从消息发送队列中提取消息数据的次数和该消息发送队列对应的定时需求的定时周期，计算该消息发送队列的处理频度值；检测输出集中缓存中消息数据的数量，当消息数据的数量等于预先配置的数量时，删除处理频度值最高的消息发送队列中存储时间最早的消息数据。

其中一个实施例中，还包括：根据在预设时间内从消息接收队列中提取消息数据的次数和该消息接收队列对应的定时需求的定时周期，计算该消息接收队列的处理频度值；检测输入集中缓存中消息数据的数量，当消息数据的数量等于预先配置的数量时，删除处理频度值最高的消息接收队列中存储时间最早的消息数据。

由于设备对消息队列的消费处理能力受限于本地设备的数据读写和处理能力，以及对外通信能力。当消息队列消费能力不足时，通信消息队列占据的存储空间将逐渐增大，引起设备或系统的内存紧张、程序崩溃等。

以设备102为例，本实施例通过配置设备102的输出集中缓存限制了其存储消息的总数，并且设备102根据式(1)计算各非空消息队列的处理频度值；当输出集中缓存中消息的数量等于其预先配置的总数时，选择非空并且处理频度值最高的消息发送队列，从中删除存储时间最早的消息数据。

通过配置输出集中缓存的大小和上述消息数据删除策略，可以控制设备102中消息数据的总数，限制其占用的存储空间；在删除消息数据时，通过选择实际处理次数和处理要求最接近的定时需求消息，首先删除其中等待时间最长的信消息，使删除的消息对设备获得各类业务数据的影响最小，确保设备能提供及时、完整的设备功能。

同样地，设备104通过配置输入集中缓存的大小，并同样采用上述消息数据删除策略，可以控制设备104中消息数据的总数，限制其占用的存储空间；在删除消息数据时，通过选择实际处理次数和处理要求最接近的定时需求消息，首先删除其中等待时间最长的信消息，使删除的消息对设备获得各类业务数据的影响最小，确保设备能提供及时、完整的设备功能。

其中一个实施例中，还包括：检测输出集中缓存中消息数据的数量，当消息数据的数量等于预先配置的数量时，删除处理频度值最高的消息发送队列中存储时间最早的消息数据的步骤还包括：当处理频度值最高的消息发送队列有多个时，删除这些消息发送队列中，定时周期最短且存储时间最早的消息数据。

其中一个实施例中，还包括：检测输入集中缓存中消息数据的数量，当消息数据的数量等于预先配置的数量时，删除处理频度值最高的消息接收队列中存储时间最早的消息数据的步骤还包括：当处理频度值最高的消息接收队列有多个时，删除这些消息接收队列中，定时周期最短且存储时间最早的消息数据。

具体地，当设备102中多个消息发送队列的处理频度值相同时，从t最短的一个或多个消息数据队列中提取消息。处理频度值相同时，t较短的消息在对应的消息队列中的存储数量较多。优先处理t较短的消息可进一步平衡各消息队列的长度。同样地，对于设备104通过对等的消息删除方法也能够进一步平衡各消息接收队列的长度。

其中一个实施例中，还包括：检测消息发送队列和/或消息接收队列中消息数据的新增数量；当在预设时间内该消息发送队列和/或消息接收队列中消息数据的新增数量为零时，删除该消息发送队列和/或消息接收队列中的消息数据。

在系统或网络正常运转时，由设备102定时重复或周期性发送的消息具有连贯性，因此设备104中各消息接收队列的消息接收时间存在相应的规律性。但当设备102关闭、重启或设备、网络出现故障等情况时，设备102和设备104中的一个或多个消息队列可能出现不符合上述消息接收规律的情况。

针对上述情况，本实施例为各消息发送队列和消息接收队列设定时间间隔，当该消息发送队列和/或消息接收队列在指定时间间隔内没有收到新的消息数据时，删除该消息发送队列和/或消息接收队列中的所有消息数据。其中，该时间间隔可以根据该消息队列对应的定时需求的定时周期、处理需求和系统运行环境等确定。通过上述消息删除策略，能够删除来自当前离线或发生故障的设备的消息数据，减少上述因素带来的影响，避免浪费消息处理资源。

其中一个实施例中，设备102和设备104处理各自内部进程间通信时，将定时通信消息源向统一输出服务发送消息过程的发送端，以及统一输入服务向消息终点服务发送消息过程的接收端分别封装为对应的请求库和发送库，以便在后续有需要实现同类型通信方式的新定时通信需求时复用，利用封装好的请求库和发送库方法可加速完成新需求实现。

其中一个实施例应用在如图4所示的场景中，设备102、设备104、设备106等根据定时需求分别设置统一输出服务、统一输入服务、定时通信源、消息终点服务等。具体地，设备102、设备104和设备106均启动统一输出服务和统一输入服务，通过网络进行多通信任务的消息收发，从其他设备获取所需的业务数据。其中1s，2s，3s，4s代表不同类型的定时消息源，1d，2d，3d，4d代表与定时消息源对应的定时消息终点。

其中一个实施例中，采用omniorb实现进程间通信与设备间通信。omniorb是知名的开源分布式通信中间件，这里选用omniorb只是为了实施方便，选用其它适合设备情况的通信框架或直接采用一些能达到进程间通信或设备间通信功能的基础性技术予以实现都是可以的。

本实施例的设备间通信实现方式包括：通用设备间通信方式如利用套接字(socket)、蓝牙通信等，也可采用相关的通信库或框架予以实现。

本实例中的数据及其结构定义为：

统一输入/输出缓存上限缓存数量：limit；

统一输入/输出缓存数据结构：std::map<id，std::queue<msg*>>cache，其中std::map是c++/stl中的键值映射数据结构，std::queue是c++/stl中的队列数据结构。

本实施例消息提取器的主逻辑表达为：

pop_message_from_cache中，以互斥锁实现线程安全，用条件变量实现事件等待避免消息提取器循环空转消耗cpu处理。

在检测预设时间内消息队列中消息数据的新增数量时，将各消息队列的预设时间指定为t+3000ms，其中t为该消息队列对应的定时需求的定时周期。

在其中一个实施例中，如图5所示，提供了一种多通信任务管理装置，包括消息发送端和消息接收端。其中，

消息发送端包括：

定时通信消息源，用于根据定时需求生成消息数据，消息数据包括通信需求编号、定时周期、目的地址以及通信业务数据需求，通过进程间通信将消息数据传输至统一输出服务；

统一输出服务模块，用于根据通信需求编号，将消息数据保存至预先为统一输出服务配置的输出集中缓存中对应的消息发送队列，使用消息提取器从消息发送队列提取消息数据，根据消息数据的目的地址，将消息数据发送给消息接收端；

消息接收端包括：

统一输入服务模块：用于接收消息发送端发送的消息数据，并将消息数据传输至统一输入服务，根据通信需求编号将消息数据存储至预先为统一输入服务配置的输入集中缓存中对应的消息接收队列，使用消息提取器从消息接收队列提取消息数据，使用进程间通信将消息数据传输给通信业务数据需求对应的消息终点服务进程。

其中一个实施例如图6所示，还包括：统一输出服务消息提取顺序设置模块，用于根据在预设时间内从输出集中缓存中的消息发送队列中提取消息的次数和该消息发送队列对应的定时需求的定时周期，计算该消息发送队列的处理频度值；使用消息提取器根据处理频度值从该消息发送队列提取消息数据。

其中一个实施例中还包括：统一输入服务消息提取顺序设置模块，用于根据在预设时间内从输入集中缓存中的消息接收队列中提取消息的次数和该消息接收队列对应的定时需求的定时周期，计算该消息接收队列的处理频度值；使用消息提取器根据处理频度值从该消息接收队列提取消息数据。

其中一个实施例如图7所示，还包括：统一输出服务消息删除模块，用于根据在预设时间内从消息发送队列中提取消息数据的次数和该消息发送队列对应的定时需求的定时周期，计算该消息发送队列的处理频度值；检测输出集中缓存中消息数据的数量，当消息数据的数量等于预先配置的数量时，删除处理频度值最高的消息发送队列中存储时间最早的消息数据。

其中一个实施例中，还包括：统一输入服务消息删除模块，用于根据在预设时间内从消息接收队列中提取消息数据的次数和该消息接收队列对应的定时需求的定时周期，计算该消息接收队列的处理频度值；检测输入集中缓存中消息数据的数量，当消息数据的数量等于预先配置的数量时，删除处理频度值最高的消息接收队列中存储时间最早的消息数据。

其中一个实施例中，统一输出服务消息删除模块还用于，当处理频度值最高的消息发送队列有多个时，删除这些消息发送队列中定时周期最短且存储时间最早的消息数据。

其中一个实施例中，统一输入服务消息删除模块还用于，当处理频度值最高的消息接收队列有多个时，删除这些消息接收队列中定时周期最短且存储时间最早的消息数据。

其中一个实施例中，统一输出服务消息删除模块还用于，检测预设时间内消息发送队列中消息数据的新增数量；当新增数量为零时，删除消息发送队列中的消息数据。

其中一个实施例中，统一输入服务消息删除模块还用于，检测预设时间内消息接收队列中消息数据的新增数量；当新增数量为零时，删除消息接收队列中的消息数据。

关于多通信任务管理装置的具体限定可以参见上文中对于多通信任务管理方法的限定，在此不再赘述。上述多通信任务管理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现以下步骤：

发送消息时：

根据定时需求生成消息数据，该消息数据包括通信需求编号、定时周期、目的地址以及通信业务数据需求，通过进程间通信将消息数据传输至统一输出服务；

根据通信需求编号，将消息数据保存至预先为统一输出服务配置的输出集中缓存中对应的消息发送队列，使用消息提取器从消息发送队列提取消息数据，根据消息数据的目的地址，将消息数据发送给消息接收端；

接收消息时：

接收消息发送端发送的消息数据，并将消息数据传输至统一输入服务，根据通信需求编号将消息数据存储至预先为统一输入服务配置的输入集中缓存中对应的消息接收队列，使用消息提取器从消息接收队列提取消息数据，使用进程间通信将消息数据传输给消息数据中通信业务数据需求对应的消息终点服务进程。

其中一个实施例中，处理器执行计算机程序时还实现以下步骤：在使用消息提取器从消息发送队列提取消息数据时，根据在预设时间内从消息发送队列提取所述消息数据的次数和消息发送队列对应的定时需求的定时周期，计算消息发送队列的处理频度值；使用消息提取器根据处理频度值从消息发送队列提取消息数据。

其中一个实施例中，处理器执行计算机程序时还实现以下步骤：在使用消息提取器从消息接收队列提取消息数据时，根据在预设时间内从消息发送队列中提取消息数据的次数和消息接收队列对应的定时需求的定时周期，计算该消息接收队列的处理频度值；使用消息提取器根据处理频度值从消息接收队列提取消息数据。

其中一个实施例中，处理器执行计算机程序时还实现以下步骤：根据在预设时间内从消息发送队列中提取消息数据的次数和该消息发送队列对应的定时需求的定时周期，计算该消息发送队列的处理频度值；检测输出集中缓存中消息数据的数量，当消息数据的数量等于预先配置的数量时，删除处理频度值最高的消息发送队列中存储时间最早的消息数据。

其中一个实施例中，处理器执行计算机程序时还实现以下步骤：根据在预设时间内从消息接收队列中提取消息数据的次数和该消息接收队列对应的定时需求的定时周期，计算该消息接收队列的处理频度值；检测输入集中缓存中消息数据的数量，当消息数据的数量等于预先配置的数量时，删除处理频度值最高的消息接收队列中存储时间最早的消息数据。

其中一个实施例中，处理器执行计算机程序时还实现以下步骤：当处理频度值最高的消息发送队列有多个时，删除这些消息发送队列中，定时周期最短且存储时间最早的消息数据。

其中一个实施例中，处理器执行计算机程序时还实现以下步骤：当处理频度值最高的消息接收队列有多个时，删除这些消息接收队列中，定时周期最短且存储时间最早的消息数据。

其中一个实施例中，处理器执行计算机程序时还实现以下步骤：检测消息发送队列和/或消息接收队列中消息数据的新增数量；当在预设时间内该新增数量为零时，删除该消息发送队列和/或消息接收队列中的消息数据。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(rom)、可编程rom(prom)、电可编程rom(eprom)、电可擦除可编程rom(eeprom)或闪存。易失性存储器可包括随机存取存储器(ram)或者外部高速缓冲存储器。作为说明而非局限，ram以多种形式可得，诸如静态ram(sram)、动态ram(dram)、同步dram(sdram)、双数据率sdram(ddrsdram)、增强型sdram(esdram)、同步链路(synchlink)dram(sldram)、存储器总线(rambus)直接ram(rdram)、直接存储器总线动态ram(drdram)、以及存储器总线动态ram(rdram)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。