CN103209153A - 消息处理方法、装置及系统 - Google Patents

Abstract

本申请公开了一种消息处理方法、装置及系统。其中，该方法包括：从数据库中读取一个或多个消息以及每个消息的消息类型标识；根据消息类型标识来获取该消息类型标识所对应的消息的处理流程；以及通过处理流程对消息进行去重处理和/或合并处理，以生成一个或多个目标消息。通过本申请，能够实现大幅度减少系统之间交互的无效消息和冗余消息，且由于消息类型标识占用资源相对较少，因此也节省了系统资源，并提高了系统的处理效率，即进一步提升了系统性能和减少网络带宽资源浪费。

Description

消息处理方法、装置及系统

技术领域

本申请涉及信息交互领域，具体而言，涉及一种消息处理方法、装置及系统。

背景技术

目前，将消息通知作为互联网应用系统的交互模式的情况越来越多，由于互联网应用的规模越来越大，产生的消息数量也呈几何基数增长，因此，对于将消息进行去重或合并，来减少消息量，从而节约资源具有比较强烈的需求。

现有技术中基于消息去重的方法，主要采用根据消息的具体内容进行比较，过滤掉内容相同的消息。例如，以电子商务网站上发布的一条商品广告信息为例，该商品广告信息会依据接收到的消息发生变化，且消息中携带有关于这条商品广告信息的消息内容，当客户端用户在一个时间段内修改了两次该商品广告信息的标题时，会产生两条携带有修改该商品广告信息的标题的消息内容，此时，两条消息内容可以分别为“供应MP3”和“供应MP3”(即该二消息的消息内容相同)，现有技术通常采用通过过滤内容相同的消息的方法可以有效的过滤掉消息内容重复的消息。而基于消息之间的合并方法目前还没有相关技术。

上述现有技术方案的核心是基于消息体内容进行去重判断，该方法包括如下缺点：

首先，由于汉语表达的灵活性和多样性，通过对消息内容进行过滤而实现去重，导致了过滤结果不确定性，并不能达到准确去重的效果，只能对部分冗余的消息做一层过滤，在实现对海量数据进行去重的效率和准确性的效果都比较差。例如，如果是基于消息内容进行去重时，虽然针对消息内容“供应MP3”和“供应了MP3”表达含义相同，但利用现有的去重技术仅在消息内容都是供应MP3”或“供应了MP3”才会过滤，这样过滤结果显然不准确，同时由于消息内容的字符占用资源相对较多，因此在进行海量数据的去重处理时，系统处理效率相对较低。

另外，考虑到应用场景的多样性，每个应用场景发出的消息同样灵活且多样，因此，同理的上述消息的去重方法很难同时满足所有的应用场景。需要对每一类应用场景做针对性的优化，从而增加了项目的迁移成本，降低了项目的易用性。

目前相关技术中，针对业务终端发出的海量消息进行去重而得到的过滤结果准确性差、效率低，以及无法对海量消息进行合并的问题，目前尚未提出有效的解决方案。

发明内容

针对相关技术的对业务终端发出的海量消息进行去重而得到的过滤结果准确性差，以及无法对海量消息进行合并的问题，目前尚未提出有效的问题而提出本申请，为此，本申请的主要目的在于提供一种消息处理方法、装置及系统，以解决上述问题。

为了实现上述目的，根据本申请的一个方面，提供了一种消息处理方法，该方法包括：从数据库中读取一个或多个消息以及每个消息的消息类型标识；根据消息类型标识来获取该消息类型标识所对应的消息的处理流程；以及通过处理流程对消息进行去重处理和/或合并处理，以生成一个或多个目标消息。

进一步地，在从数据库中读取一个或多个消息以及每个消息的消息类型标识之前，方法还包括：业务终端生成一个或多个消息，并生成每一个消息的消息类型标识；以及将所有的消息及其对应的消息类型标识保存至数据库。

进一步地，生成每一个消息的消息类型标识的方法包括：对每个消息设置对应的消息类型标识，并将消息类型标识添加到消息中；或者，抽取消息中的一个或多个属性值，对获取到的属性值进行提取处理，以获取提取结果，将提取结果作为消息对应的消息类型标识添加到消息中。

进一步地，通过处理流程对消息进行去重处理和/或合并处理，以生成一个或多个目标消息包括：在检测到所有消息中存在一组或多组消息的消息类型标识相同的情况下，选择每组消息中消息生成时间最晚的消息作为该组消息的目标消息；或者，判断任意一个消息类型标识所对应的第一消息是否与其他消息类型标识所对应的消息进行合并，其中，在确认合并的情况下，读取需要与第一消息合并的预定消息，并将第一消息的内容与预设消息的内容进行合并，以生成目标消息；在确认不合并的情况下，将第一消息作为目标消息。

进一步地，通过处理流程对消息进行去重处理和/或合并处理，以生成一个或多个目标消息包括：在检测到所有消息中存在一组或多组消息的类型标识相同的情况下，仅保存每组消息中消息生成时间最晚的消息，以获取第一消息组；判断第一消息组中任意一个消息类型标识所对应的第一消息是否与其他消息类型标识所对应的消息进行合并，其中，在确认合并的情况下，读取需要与第一消息合并的预定消息，并将第一消息的内容与预设消息的内容进行合并，以生成目标消息；在确认不合并的情况下，将第一消息作为目标消息。

进一步地，通过处理流程对消息进行去重处理和/或合并处理，以生成一个或多个目标消息包括：判断所有消息中任意一个消息类型标识所对应的第一消息是否与其他消息类型标识所对应的消息进行合并，其中，在确认合并的情况下，读取需要与第一消息合并的预定消息，并将第一消息的内容与预设消息的内容进行合并，将将经过合并得到的所有合并消息作为第二消息组；在确认不合并的情况下，将所有的第一消息作为第三组消息；在检测到第二消息组或第三组消息中存在N个消息的类型标识相同的情况下，仅保存N个消息中消息生成时间最晚的消息作为目标消息。

为了实现上述目的，根据本申请的另一方面，提供了一种消息处理装置，该装置包括：读取模块，用于从数据库中读取一个或多个消息以及每个消息的消息类型标识；获取模块，用于根据消息类型标识来获取该消息类型标识所对应的消息的处理流程；以及第一处理模块，用于通过处理流程对消息进行去重处理和/或合并处理，以生成一个或多个目标消息。

进一步地，装置还包括：生成模块，用于业务终端生成一个或多个消息，并生成每一个消息的消息类型标识；以及保存模块，用于将所有的消息及其对应的消息类型标识保存至数据库。

进一步地，生成模块包括：设置模块，用于对每个消息设置对应的消息类型标识，并将消息类型标识添加到消息中；或者，第二处理模块，用于抽取消息中的一个或多个属性值，对获取到的属性值进行提取处理，以获取提取结果，将提取结果作为消息对应的消息类型标识添加到消息中。

进一步地，第一处理模块包括：去重处理模块，用于在检测到所有消息中存在一组或多组消息的消息类型标识相同的情况下，选择每组消息中消息生成时间最晚的消息作为该组消息的目标消息；或者，合并处理模块，用于判断任意一个消息类型标识所对应的第一消息是否与其他消息类型标识所对应的消息进行合并，其中，在确认合并的情况下，读取需要与第一消息合并的预定消息，并将第一消息的内容与预设消息的内容进行合并，以生成目标消息；在确认不合并的情况下，将第一消息作为目标消息。

为了实现上述目的，根据本申请的另一方面，提供了一种消息处理系统，该系统包括：业务终端，用于生成一个或多个消息以及每一个消息的消息类型标识，并将所有的消息及其对应的消息类型标识保存至数据库；以及通知消息终端，用于从数据库中读取一个或多个消息以及每个消息的消息类型标识，根据消息类型标识来获取该消息类型标识所对应的消息的处理流程，并通过处理流程对消息进行去重处理和/或合并处理，以生成一个或多个目标消息。

进一步地，系统还包括：外部终端，用于接收经过格式转换的所有目标消息。

为了实现上述目的，根据本申请的另一方面，提供了一种消息处理方法，该方法包括：业务终端接收客户端发送的修改后的新消息；业务终端获取所述新消息对应的消息类型标识；业务终端将新的消息及其对应的消息类型标识保存至数据库，以使通知消息终端从数据库中读取所述新消息以及该消息的消息类型标识；根据消息类型标识来获取该消息类型标识所对应的消息的处理流程；以及通过处理流程对消息进行去重处理和/或合并处理，以生成一个或多个目标消息。

通过本申请，采用从数据库中读取一个或多个消息以及每个消息的消息类型标识；根据消息类型标识来获取该消息类型标识所对应的消息的处理流程；以及通过处理流程对消息进行去重处理和/或合并处理，以生成一个或多个目标消息，该实施例通过读取消息中已经添加了的消息类型标识，使得在去重处理和/合并处理过程中，仅需根据读取到的消息类型标识调用已经预设的处理流程，就可以得到对应的目标消息，由于消息类型标识的内容单一且准确，因此，将基于消息类型标识的去重处理和/或合并处理，不会因为消息本身内容的灵活和多样，以及应用场景的多样而发生变化，显然准确度更高，从而解决了现有技术中针对业务终端发出的海量消息进行去重而得到的过滤结果准确性差，以及无法对海量消息进行合并的问题，进而实现大幅度减少系统之间交互的无效消息和冗余消息，且由于消息类型标识占用资源相对较少，因此也节省了系统资源，并提高了系统的处理效率，即进一步提升了系统性能和减少网络带宽资源浪费的效果。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的消息处理系统的结构示意图；

图2是根据本申请实施例的消息处理方法的流程图；

图3是根据图2所示实施例的一种消息处理方法的详细流程图；

图4是根据图2所示实施例的另一种消息处理方法的详细流程图；以及

图5是根据本申请实施例的消息处理装置的结构示意图。

具体实施方式

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

图1是根据本申请实施例的消息处理系统的结构示意图。

如图1所示，该消息处理系统包括：业务终端10，用于生成一个或多个消息以及每一个消息的消息类型标识，并将所有的消息及其对应的消息类型标识保存至数据库；以及，通知消息终端30，用于从数据库中读取一个或多个消息以及每个消息的消息类型标识，根据消息类型标识来获取该消息类型标识所对应的消息的处理流程，并通过处理流程对消息进行去重处理和/或合并处理，以生成一个或多个目标消息。

本申请上述实施例通过读取消息中已经添加了的消息类型标识，使得在去重处理和/合并处理过程中，仅需根据读取到的消息类型标识来调用已经预设的处理流程，就可以得到对应的目标消息，由于消息类型标识的内容单一且准确，不会因为消息本身内容的灵活和多样，以及应用场景的多样而发生变化，从而解决了现有技术中针对业务终端发出的海量消息进行去重而得到的过滤结果准确性差、效率低，以及无法对海量消息进行合并的问题，进而实现大幅度减少系统之间交互的无效消息和冗余消息，进一步提升了系统性能和减少网络带宽资源浪费的效果。

具体的，在目前越来越多的商业实体通过互联网来组织信息流、资金流和物流的过程中，采用以消息作为交互模式来实现互联网应用系统的通知功能，本申请基于图1所示的实施例可知，首先，给互联网应用系统中的业务终端10上发出的每种消息都各添加一个消息类型标识，即给每种消息引入终端设备可识别的自然语言的消息类型，并将添加了消息类型标识的消息及其消息类型标识保存至数据库，例如，以用户修改网站上发布的信息的标题为例说明增加了消息类型标识的消息结构，消息结构如下表1所示：

表1：

消息类型标识	消息内容	消息生成时间
			302	供应MP3	2011-8-17 10:00:00
302	供应MP3/MP4	2011-8-17 10:00:02

然后，通知消息终端30中的消息处理装置从数据库中取出对应的消息及消息类型标识，并根据读取到的消息类型标识在处理规则配置装置中获取到对应的处理流程(即进行去重和/或合并处理的规则)，则根据消息类型标识及获取到的处理规则对消息进行去重和/或合并处理，如表1中所示例子，当检测到消息类型标识一致(都是302)时，将这两条消息进行合并得到目标消息，或者将两个消息中消息生成时间最晚的一条消息作为目标消息，而将冗余的另一条消息禁止发送，例如仅将消息生成时间为2011-8-17 10:00:02的消息作为目标消息进行发送。

上述具体的实施例使得通知消息终端30可以根据消息中的消息类型标识来确定该消息的处理流程(也可以是处理规则)，从而对消息准确有效的进行去重和/或合并处理，由于消息类型标识具有准确、内容单一、易识别等特点，则基于消息类型标识的去重和/或合并处理准确且大幅度减少了系统间交互的消息量，使得减少无效的消息和冗余的消息的效率大大提高，进一步提升了系统性能和减少网络带宽资源浪费。而且本申请的技术方案也完全摆脱了项目对于人力运维成本和应用场景的制约，在所有应用场景下都可以表现出准确且高效的效果。

本申请上述实施例中的系统还可以包括：外部终端50，用于接收经过格式转换的所有目标消息。为了使得外部终端50可以成功识别通知消息终端30中得到的目标消息，需要将目标消息基于外部终端50的格式等要求进行转换，提高了消息识别的准确度。

本申请实施例的产品可以应用在网销宝后台的多个交互系统(例如，Notify、同步系统)中进行使用。

另外，此处需要说明的是，本申请实施例中涉及到的业务终端10可以是指应用各种商业应用软件的终端设备，它是消息通知的发起者；通知客户端可以是指安装在业务终端10中供商业应用使用的客户端软件。此处，商业应用可以使用通知客户端注册一个消息。一旦消息注册成功，系统就能够确保该消息需要到达的目的接收方，即使此时消息接收方不在线，或者网络暂时无法连通；数据库可以是任何通用的关系型数据库，它负责保存待发送的消息或者曾经发送不成功等待重发的消息；消息是指各个系统交互具有可识别性的信息实体；通知消息终端30是指把消息通知给具体的消费者的执行者；外部终端是指某个商业系统，它是具体的消息消费者及接收者；而实施例中涉及到的消息类型标识具体可以指消息在通知消息终端30中内部处理所表达的机器语言。如下表实例：

消息类型标识	功能描述
		300	新增信息类型消息，如新增商品发布信息
301	删除类型消息，如删除商品发布信息
		302	修改信息的某一个属性，如商品发布信息的标题
303	修改信息的某一个属性，如商品发布信息状态
		…………………….	………………………………….

图2是根据本申请实施例的消息处理方法的流程图；图3是根据图2所示实施例的一种消息处理方法的详细流程图；以及图4是根据图2所示实施例的另一种消息处理方法的详细流程图。

如图2所示该方法包括如下步骤：

步骤S102，通过图1中的通知消息终端30来实现从数据库中读取一个或多个消息以及每个消息的消息类型标识。

步骤S104，通过图1中通知消息终端30来执行根据消息类型标识来获取该消息类型标识所对应的消息的处理流程。

步骤S106，通过图1中通知消息终端30的消息处理装置来执行通过处理流程对消息进行去重处理和/或合并处理，以生成一个或多个目标消息。

本申请上述实施例通过读取消息中已经添加了的消息类型标识，使得在去重处理和/合并处理过程中，仅需根据读取到的消息类型标识来调用已经预设的处理流程，就可以得到对应的目标消息，由于消息类型标识的内容单一且准确，不会因为消息本身内容的灵活和多样，以及应用场景的多样而发生变化，从而解决了现有技术中针对业务终端10发出的海量消息进行去重而得到的过滤结果准确性差、效率低，以及无法对海量消息进行合并的问题，进而实现大幅度减少系统之间交互的无效消息和冗余消息，进一步提升了系统性能和减少网络带宽资源浪费的效果。

本申请上述实施例中，在从数据库中读取一个或多个消息以及每个消息的消息类型标识之前，还可以包括如下步骤：业务终端10生成一个或多个消息，并生成每一个消息的消息类型标识；以及将所有的消息及其对应的消息类型标识保存至数据库。该实施例确认了每一个消息所对应的消息类型标识，并将其作为消息的一部分进行保存，这种独立生成消息类型标识并独立保存的方式，使得需要更新消息类型标识的过程简单、易用，研发人员可以准确高效的确定需要更新的消息类型标识的位置，提高了系统的灵活性和易用性。同时，该实施例中的业务终端在接收到客户端由于更改商品广告信息而发布的新消息之后，直接获取该新消息所对应的消息类型标识，并将得到的新消息及其消息类型标识的组合保存至数据库，且该消息可以携带关于商品广告信息的消息内容。

本申请上述实施例中，生成每一个消息的消息类型标识的方法可以包括如下两种实施方式：第一种是对每个消息设置对应的消息类型标识，并将消息类型标识添加到消息中；或者，业务终端通过抽取消息中的一个或多个属性值，对获取到的属性值进行提取处理，以获取提取结果，将提取结果作为消息对应的消息类型标识添加到消息中。该实施例实现了两种生成消息类型标识的方式，第一种为自动设置的方式，该方式简单易行，第二种方式为利用消息已有的内容自动生成消息类型标识，该方式虽然复杂，但可以降低人工成本，具体的，可以通过检测消息内容的重复度或者检测消息生成时间的重复范围，来确定对该消息中需要添入的消息类型标识，以抽取消息中的消息内容为例，检测到当前的消息内容与之前的消息内容有两个字符重复时(表1中两个消息中的“供应MP3”)，则提取重复的内容，并将重复的内容作为消息类型标识插入源消息中，作为合并和去重处理的依据。

本申请上述实施例中，通过处理流程对消息进行去重处理和/或合并处理，以生成一个或多个目标消息的实施步骤中，可以分别进行独立的去重处理或者独立的合并处理。

其中，独立完成去重处理的方式可以是：在检测到所有消息中存在一组或多组消息的消息类型标识相同的情况下，选择每组消息中消息生成时间最晚的消息作为该组消息的目标消息。该实施例的具体过程可以基于表1所示的实施例进行描述，在从数据库中取出多条消息之后，通知消息终端30中的消息处理装置从处理规则配置装置中取出对应的去重处理流程，该去重处理流程如下，当检测到两条消息的消息类型标识相同时，可以考虑仅向外部终端发送其中一条消息，为了提高发送消息的实时性和准确性，此时可以选择两个消息中消息生成时间最晚的一条消息作为目标消息，例如将消息生成时间为2011-8-17 10:00:02的消息作为目标消息，这样就去除了重复的消息，减少了用于处理消息的系统资源。针对更加复杂的情况，如果存在海量消息的情况下，该实施例可以采用基于相同的消息类型标识将海量的消息划分成消息组，由于每组消息中的各个消息的消息类型标识都相同，则每个消息组都仅向外发送一条目标消息，这样就将海量消息尽可能的压缩到最少的消息数目供系统处理。

独立完成合并处理的方式可以是：判断任意一个消息类型标识所对应的第一消息是否与其他消息类型标识所对应的消息进行合并，其中，在确认合并的情况下，读取需要与第一消息合并的预设消息，并将第一消息的内容与预设消息的内容进行合并，以生成目标消息；在确认不合并的情况下，将第一消息作为目标消息。该实施例的具体合并过程可以基于表2所示的消息结构进行描述。如表2可知，消息类型标识为机器可识别的自然语言符号，与每种消息对应一致。合并属性值代表预先设定该消息类型标识所对应的消息是否需要合并，以及合并的预设消息，并用“+”号来表示当前消息类型标识对应的消息需要与哪个或哪些消息类型标识对应的消息进行合并。

表2：

消息类型标识	合并属性	功能描述
			300	300	新增商品发布信息
302	302+303	修改商品发布信息的标题
			303	302+303	修改商品发布信息的状态
…………………….	…………………….	…………………….

该实施例中，在从数据库中取出多条消息之后，通知消息终端30中的消息处理装置从处理规则配置装置中取出对应的合并处理流程，该合并处理流程如下：根据当前消息的消息类型标识(例如消息类型标识为302的消息)确认是否需要跟其他消息类型标识对应的消息进行合并，例如，可以从表2中确定消息类型标识为302的消息需要和类型标识为303的消息进行合并，从而调用将消息类型标识为302的消息内容和类型标识为303的消息内容进行合并，得到一个消息内容合并后的目标消息，这样就可以将一些虽然内容不完全一致但实际使用过程中没必要单一发送的消息作为一条目标消息进行发送，减少了冗余消息。如果该消息不可以合并(例如消息类型标识为300的消息)，则将该消息作为目标消息直接发送。

上述实施例中当客户端修改了广告信息中的一个属性之后，例如消息内容，此时，业务终端10接收到这个新的消息内容之后，会基于消息内容的属性定义得到消息内容所对应的消息类型标识，通知消息终端30获取到该新的消息及其消息类型标识之后，就会从处理规则配置装置中取出对应的合并处理流程进行处理，具体流程如上述实施例所表述的步骤执行。

同样的，在存在海量消息的情况下，该实施例可以通过消息类型标识预设当前消息是否需要合并，以及需要合并哪些消息，这样可以根据实际情况，通过将大量的消息进行合并而得到若干组合并后的目标消息，这样就将海量消息尽可能的压缩到最少的消息数目供系统处理。由于消息合并的数目可以依据情况设定，因此，合并处理使得系统的灵活性更高。

基于上述各个实施例可知，本申请可以将业务终端10生成的海量消息进行单独的合并处理和单独的去重处理，由此，本申请还可以将合并处理和去重处理进行合并使用，使得海量消息的得到进一步优化，进一步提高系统性能和减少网络带宽资源浪费。

即通过处理流程对消息进行去重处理和/或合并处理，以生成一个或多个目标消息的步骤还可以是如下实施步骤：在检测到所有消息中存在一组或多组消息的类型标识相同的情况下，仅保存每组消息中消息生成时间最晚的消息，以获取第一消息组；判断第一消息组中任意一个消息类型标识所对应的第一消息是否与其他消息类型标识所对应的消息进行合并，其中，在确认合并的情况下，读取需要与第一消息合并的预定消息，并将第一消息的内容与预设消息的内容进行合并，以生成目标消息；在确认不合并的情况下，将第一消息作为目标消息。

如图3所示，上述实施例可以包括如下详细步骤：

步骤S201，从数据库中取出多条消息及各个消息的消息类型标识。

步骤S202，在从数据库中取出多条消息之后，通知消息终端30中的消息处理装置从处理规则配置装置中取出对应每个消息类型标识的处理流程。本实施例中该步骤得到的处理流程是进行先去重再合并的处理方式，以下步骤可以结合表1和表2的实施例进行描述。

步骤S203，根据消息类型标识先对消息进行去重处理。该步骤具体的实施过程可以是，在接收到的所有消息中，将消息类型标识相同的消息进行去重(如表1中将消息类型标识都为302的消息去重)，并选择消息生成时间最晚的一条消息作为下一步合并处理的基础。该步骤中进行的去重处理也可以认为是根据相同的消息类型标识将所有的消息划分成消息组，每个消息组仅取到一条消息作为下一步合并处理的基础。

步骤S204，再根据当前消息的消息类型标识确认是否需要跟其他消息类型标识对应的消息进行合并，如果需要合并则进入步骤S205，否则将当前消息作为目标消息而进入步骤S206。

步骤S205，根据消息类型标识得到当前消息需要与哪个或哪些消息类型标识对应的消息进行合并，例如将表2中消息类型标识为302的消息需要和消息类型标识为303的消息合并，同理可以得到其他消息类型标识所对应的消息的合并结果，最终得到经过两次去冗余处理的目标消息。

步骤S206，将得到的目标消息发送至外部终端。

上述实施例通常在处理海量消息的情况下，该方法的效果更加明显，该实施例可以先采用基于相同的消息类型标识将海量的消息划分成消息组，由于每个消息组去重后仅取一个消息作为下一步合并的基础，因此，在海量消息进行去重后的消息可以看作为第一消息组，然后，在对这个第一消息组进行合并处理，即通过检测第一消息组中各个消息的消息类型标识预设当前每个消息是否需要合并，以及需要合并哪些消息，这样可以根据实际情况，通过将第一消息组中的各个消息进行合并而得到若干合并后的目标消息，这样就将海量消息压缩到最少的消息数目供系统处理。

基于与图3所示实施例相同的目的，该通过处理流程对消息进行去重处理和/或合并处理，以生成一个或多个目标消息的步骤还可以实施为以下另外一种实施例过程：判断所有消息中任意一个消息类型标识所对应的第一消息是否与其他消息类型标识所对应的消息进行合并，其中，在确认合并的情况下，读取需要与第一消息合并的预定消息，并将第一消息的内容与预设消息的内容进行合并，将将经过合并得到的所有合并消息作为第二消息组；在确认不合并的情况下，将所有的第一消息作为第三组消息；在检测到第二消息组或第三组消息中存在N个消息的类型标识相同的情况下，仅保存N个消息中消息生成时间最晚的消息作为目标消息。

具体的，如图4所示，上述实施例可以包括如下详细步骤：

步骤S301，从数据库中取出多条消息及各个消息的消息类型标识。

步骤S302，在从数据库中取出多条消息之后，通知消息终端30中的消息处理装置从处理规则配置装置中取出对应每个消息类型标识的处理流程。本实施例中该步骤得到的处理流程是进行先合并再去重的处理方式，以下步骤可以结合表1和表2的实施例进行描述。

步骤S303，在接收到的所有消息中，可以先根据当前消息的消息类型标识来确认是否需要跟其他消息类型标识对应的消息进行合并，如果需要合并则进入步骤S304，否则将当前消息保持不变，作为步骤S305的去重处理的基础。

步骤S304，根据消息类型标识得到当前消息需要与哪个或哪些消息类型标识对应的消息进行合并，例如表2中消息类型标识为302的消息需要和消息类型标识为303的消息合并，得到一条合并后的消息，同理可以得到其他消息类型标识所对应的消息的合并结果，作为下一步去重处理的基础。

步骤S305，将步骤S303中合并得到的所有消息以及步骤S304中未进行合并的消息进行去重处理，具体可以根据消息类型标识对消进行去重处理。

该步骤具体的实施过程可以是，在接收到的所有消息中，将消息类型标识相同的消息进行去重(如表1中将消息类型标识都为302的消息去重)，并选择消息生成时间最晚的一条消息作为目标消息。该步骤中进行的去重处理也可以认为是将合并后处理后得到的所有消息按照相同的消息类型标识的条件进行筛选，将所有的消息划分成消息组，每个消息组仅得到一条消息作为目标消息。最终得到经过两次去冗余处理的目标消息。

步骤S306，将得到的目标消息发送至外部终端。

同理的，在处理海量消息的情况下，该方法的效果一样更加明显，该实施例可以根据每个消息的消息类型标识确认每个消息是否需要合并，以及与哪些消息进行合并，在完成所有消息的合并处理之后，可以得到合并消息内容后的第二消息组，然后采用基于相同的消息类型标识将第二消息组中的消息划分成消息组，即将第二消息组中对于具有相同消息类型标识的消息仅取其中一个消息作为目标消息，由此通过将第二消息组中的各个消息进行去重而得到若干目标消息，这样就将海量消息压缩到最少的消息数目供系统处理。

本申请上述各个实施例中得到的所有目标消息都需要经过格式处理才能够被外部设备所识别，因此，需要通过通知消息终端30中的通知转换装置将经过消息处理装置处理得到的目标消息进行转换，再发送至外部终端。

本申请可以包括实现上述消息处理方法的计算机程序以及保存该计算程序的存储器，该消息处理方法的计算机程序可以采用Java实现，并在Linux系统上运行能达到最佳的实施效果

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

图5是根据本申请实施例的消息处理装置的结构示意图。

如图5所示，该消息处理装置包括：读取模块20，用于从数据库中读取一个或多个消息以及每个消息的消息类型标识；获取模块40，用于根据消息类型标识来获取该消息类型标识所对应的消息的处理流程；以及第一处理模块60，用于通过处理流程对消息进行去重处理和/或合并处理，以生成一个或多个目标消息。

本申请上述实施例通过读取模块20来读取消息中已经添加了的消息类型标识，使得在去重处理和/合并处理过程中，获取模块40仅需根据读取到的消息类型标识来调用已经预设的处理流程，就可以通过第一处理模块60得到对应的目标消息，由于消息类型标识的内容单一且准确，不会因为消息本身内容的灵活和多样，以及应用场景的多样而发生变化，从而解决了现有技术中针对业务终端10发出的海量消息进行去重而得到的过滤结果准确性差、效率低，以及无法对海量消息进行合并的问题，进而实现大幅度减少系统之间交互的无效消息和冗余消息，进一步提升了系统性能和减少网络带宽资源浪费的效果。

本申请上述实施例中的装置还可以包括：生成模块80，用于业务终端10生成一个或多个消息，并生成每一个消息的消息类型标识；以及保存模块100，用于将所有的消息及其对应的消息类型标识保存至数据库。该实施例确认了每一个消息所对应的消息类型标识，并将其作为消息的一部分进行保存，这种独立生成消息类型标识并独立保存的方式，使得需要更新消息类型标识的过程简单、易用，研发人员可以准确高效的确定需要更新的消息类型标识的位置，提高了系统的灵活性和易用性。

本申请上述实施例中的生成模块80可以包括：设置模块，用于对每个消息设置对应的消息类型标识，并将消息类型标识添加到消息中；或者，第二处理模块，用于抽取消息中的一个或多个属性值，对获取到的属性值进行提取处理，以获取提取结果，将提取结果作为消息对应的消息类型标识添加到消息中。该实施例实现了两种生成消息类型标识的方式，第一种为自动设置的方式，该方式简单易行，第二种方式为利用消息已有的内容自动生成消息类型标识，该方式虽然复杂，但可以降低人工成本，具体的，可以检测消息内容的重复度或者检测消息生成时间的重复范围，来确定对该消息中需要添入的消息类型标识。

本申请上述实施例中的第一处理模块60可以包括：去重处理模块601，用于在检测到所有消息中存在一组或多组消息的消息类型标识相同的情况下，选择每组消息中消息生成时间最晚的消息作为该组消息的目标消息；或者，合并处理模块602，用于判断任意一个消息类型标识所对应的第一消息是否与其他消息类型标识所对应的消息进行合并，其中，在确认合并的情况下，读取需要与第一消息合并的预定消息，并将第一消息的内容与预设消息的内容进行合并，以生成目标消息；在确认不合并的情况下，将第一消息作为目标消息。本申请上述实施例中的合并处理模块601和去重处理模块602可以独立完成海量消息的完成大幅度减少系统之间交互的无效消息和冗余消息，也可以两个模块进行合作对消息进行处理，如图4所示，可以先执行合并处理模块601的功能，再执行去重处理模块602的功能，但处理过程中两个模块的启动顺序不限于此，也可以调换过来，因此，本申请上述实施例方法在达到提升了系统性能和减少网络带宽资源浪费的效果的同时，也提高了系统的灵活性，实用性强。

本申请上述装置实施例通过消息类型标识(机器可识别的自然语言)对消息进行分类，以此达到了有效的消息合并和去重的方法。

本申请还可以提供一种消息处理方法，该方法包括：业务终端接收客户端发送的修改后的新消息；业务终端获取所述新消息对应的消息类型标识；业务终端将新的消息及其对应的消息类型标识保存至数据库，以使通知消息终端从数据库中读取所述新消息以及该消息的消息类型标识；根据消息类型标识来获取该消息类型标识所对应的消息的处理流程；以及通过处理流程对消息进行去重处理和/或合并处理，以生成一个或多个目标消息。

从以上的描述中，可以看出，本申请实现了如下技术效果：通过消息类型(机器可识别的自然语言)的引入，大幅度减少了系统间交互的无效消息和冗余消息。而且完全摆脱了项目对于人力运维成本和应用场景的制约，可以实现在所有场景下都进行合理的去冗余消息的效果，进一步也提升了系统性能和减少网络带宽资源浪费的效果。

显然，本领域的技术人员应该明白，上述的本申请的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请不限制于任何特定的硬件和软件结合。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (13)

1.一种消息处理方法，其特征在于，包括：

从数据库中读取一个或多个消息以及每个消息的消息类型标识；

根据所述消息类型标识来获取该消息类型标识所对应的消息的处理流程；以及

通过所述处理流程对所述消息进行去重处理和/或合并处理，以生成一个或多个目标消息。

2.根据权利要求1所述的方法，其特征在于，在从数据库中读取一个或多个消息以及每个消息的消息类型标识之前，所述方法还包括：

业务终端生成所述一个或多个消息，并生成每一个消息的消息类型标识；以及

将所有的消息及其对应的消息类型标识保存至所述数据库。

3.根据权利要求2所述的方法，其特征在于，生成每一个消息的消息类型标识的方法包括：

对每个消息设置对应的消息类型标识，并将所述消息类型标识添加到所述消息中；

或者，

抽取所述消息中的一个或多个属性值，对获取到的属性值进行提取处理，以获取提取结果，将所述提取结果作为所述消息对应的消息类型标识添加到所述消息中。

4.根据权利要求1-3中任意一项所述的方法，其特征在于，通过所述处理流程对所述消息进行去重处理和/或合并处理，以生成一个或多个目标消息包括：

在检测到所有消息中存在一组或多组消息的消息类型标识相同的情况下，选择每组消息中消息生成时间最晚的消息作为该组消息的目标消息；或者，

判断任意一个消息类型标识所对应的第一消息是否与其他消息类型标识所对应的消息进行合并，其中，

在确认合并的情况下，读取需要与所述第一消息合并的预定消息，并将所述第一消息的内容与所述预设消息的内容进行合并，以生成所述目标消息；

在确认不合并的情况下，将所述第一消息作为所述目标消息。

5.根据权利要求1-3中任意一项所述的方法，其特征在于，通过所述处理流程对所述消息进行去重处理和/或合并处理，以生成一个或多个目标消息包括：

在检测到所有消息中存在一组或多组消息的类型标识相同的情况下，仅保存每组消息中消息生成时间最晚的消息，以获取第一消息组；

判断所述第一消息组中任意一个消息类型标识所对应的第一消息是否与其他消息类型标识所对应的消息进行合并，其中，

在确认合并的情况下，读取需要与所述第一消息合并的预定消息，并将所述第一消息的内容与所述预设消息的内容进行合并，以生成所述目标消息；

在确认不合并的情况下，将所述第一消息作为所述目标消息。

6.根据权利要求1-3中任意一项所述的方法，其特征在于，通过所述处理流程对所述消息进行去重处理和/或合并处理，以生成一个或多个目标消息包括：

判断所有消息中任意一个消息类型标识所对应的第一消息是否与其他消息类型标识所对应的消息进行合并，其中，

在确认合并的情况下，读取需要与所述第一消息合并的预定消息，并将所述第一消息的内容与所述预设消息的内容进行合并，将将经过合并得到的所有合并消息作为第二消息组；

在确认不合并的情况下，将所有的第一消息作为第三组消息；

在检测到所述第二消息组或所述第三组消息中存在N个消息的类型标识相同的情况下，仅保存所述N个消息中消息生成时间最晚的消息作为所述目标消息。

7.一种消息处理装置，其特征在于，包括：

读取模块，用于从数据库中读取一个或多个消息以及每个消息的消息类型标识；

获取模块，用于根据所述消息类型标识来获取该消息类型标识所对应的消息的处理流程；以及

第一处理模块，用于通过所述处理流程对所述消息进行去重处理和/或合并处理，以生成一个或多个目标消息。

8.根据权利要求7所述的装置，其特征在于，所述装置还包括：

生成模块，用于业务终端生成所述一个或多个消息，并生成每一个消息的消息类型标识；以及

保存模块，用于将所有的消息及其对应的消息类型标识保存至所述数据库。

9.根据权利要求8所述的装置，其特征在于，所述生成模块包括：

设置模块，用于对每个消息设置对应的消息类型标识，并将所述消息类型标识添加到所述消息中；或者，

第二处理模块，用于抽取所述消息中的一个或多个属性值，对获取到的属性值进行提取处理，以获取提取结果，将所述提取结果作为所述消息对应的消息类型标识添加到所述消息中。

10.根据权利要求79中任意一项所述的装置，其特征在于，所述第一处理模块包括：

去重处理模块，用于在检测到所有消息中存在一组或多组消息的消息类型标识相同的情况下，选择每组消息中消息生成时间最晚的消息作为该组消息的目标消息；或者，

合并处理模块，用于判断任意一个消息类型标识所对应的第一消息是否与其他消息类型标识所对应的消息进行合并，其中，在确认合并的情况下，读取需要与所述第一消息合并的预定消息，并将所述第一消息的内容与所述预设消息的内容进行合并，以生成所述目标消息；在确认不合并的情况下，将所述第一消息作为所述目标消息。

11.一种消息处理系统，其特征在于，包括：

业务终端，用于生成一个或多个消息以及每一个消息的消息类型标识，并将所有的消息及其对应的消息类型标识保存至所述数据库；以及

通知消息终端，用于从数据库中读取一个或多个消息以及每个消息的消息类型标识，根据所述消息类型标识来获取该消息类型标识所对应的消息的处理流程，并通过所述处理流程对所述消息进行去重处理和/或合并处理，以生成一个或多个目标消息。

12.根据权利要求12所述的系统，其特征在于，所述系统还包括：

外部终端，用于接收经过格式转换的所有目标消息。

13.一种消息处理方法，其特征在于，包括：

业务终端接收客户端发送的修改后的新消息；

所述业务终端获取所述新消息对应的消息类型标识；

所述业务终端将所述新消息及其对应的消息类型标识保存至数据库，以使通知消息终端从所述数据库中读取所述新消息以及该消息的消息类型标识；

根据所述消息类型标识来获取该消息类型标识所对应的消息的处理流程；以及

通过所述处理流程对所述消息进行去重处理和/或合并处理，以生成一个或多个目标消息。

Images