CN107465549A - 一种分布式消息处理方法和系统 - Google Patents

Abstract

本申请提供一种分布式消息处理方法和系统，方法包括：获取消息消费者、消息生产者和消息代理的本地日志文件，本地日志文件存储有各个业务消息的发送和接收情况以及相关联的业务消息的业务内容；依据获取到的关键字对获取到的本地日志文件中的内容进行查询，输出与关键字相对应的日志条目，关键字为所需查找的业务消息的消息属性。该方案通过将业务消息的收发情况与业务消息的业务内容相关联，依据用户输入的关键字对各个本地日志文件进行检索，提取与关键字相对应的日志条目，即可依据提取到的日志条目得到业务消息的完整消费轨迹，实现了异常消息的故障定位。

Description

一种分布式消息处理方法和系统

技术领域

本发明涉及计算机技术领域，具体涉及一种支持消费轨迹的分布式消息处理方法和系统。

背景技术

现代互联网公司的系统架构多是由各个子系统组成的分布式系统，而分布式消息系统作为分布式系统中重要的组件被大量使用来解决应用耦合、异步消息、流量削锋等问题。

分布式消息系统由消息生产者、消息代理和消息消费者组成，消息生产者将消息发送至消息代理，消息代理将接收到的消息缓存至内存或其他存储设备，消息消费者从消息代理中取出消息并作相应处理。消息消费者可以根据自身的处理能力来合理地进行消息消费和处理，避免消息消费者的处理子系统被前端瞬时大量的流量给冲垮。

由于分布式消息系统构建在不可靠的软硬件系统和异步网络通信之上，因此十分容易出现消息丢失的情况，如网络故障、消费失败等。对于使用者而言，消息丢失会导致业务异常，但使用者又很难查出导致异常的是哪些消息。针对上述问题，已有的解决方案多是通过在消息系统客户端记录每次消息发送接收的日志信息，当出现异常时通过查看客户端的日志信息来分析问题。用户通常只能看到出现异常的业务内容，无法判断是在业务处理的哪个环节出现异常的，无法将业务内容与日志信息相关联，因此存在故障定位难的问题。

发明内容

有鉴于此，本发明实施例提供一种支持消费轨迹的分布式消息处理方法和系统，以实现异常业务消息的故障定位。

为实现上述目的，本发明实施例提供如下技术方案：

一种分布式消息处理方法，包括：

获取消息消费者、消息生产者和消息代理的本地日志文件，所述本地日志文件存储有各个业务消息的发送和接收情况以及与发送和接收的业务消息相关联的业务消息的业务内容；

依据获取到的关键字对获取到的消息消费者、消息生产者和消息代理的本地日志文件中的内容进行查询，输出获取消息消费者、消息生产者和消息代理的本地日志文件中存储的与所述关键字相对应的日志条目，所述关键字为所需查找的业务消息的消息属性。

优选的，上述分布式消息处理方法中，所述消息生产者的本地日志文件中存储有生产者信息，所述生产者信息至少包括：各个业务消息对应的生产者客户端IP、发送时间、发送状态标识、发送耗时、业务消息ID以及业务消息的业务内容；

所述消费者的本地日志文件中存储有消费者信息，所述消费者信息至少包括：各个业务消息对应的消费者客户端IP、投递次数、消费状态标识和消费耗时；

所述代理者的本地日志文件中存储有代理信息，所述代理信息至少包括：各个业务消息的存储位置和存储时间。

优选的，上述分布式消息处理方法中，获取消息消费者、消息生产者和消息代理的本地日志文件，具体为：

异步获取消息消费者、消息生产者和消息代理的本地日志文件。

优选的，上述分布式消息处理方法中，依据获取到的关键字对获取到的本地日志文件中的内容进行查询之后，还包括：

依据与所述关键字相对应的日志条目生成并输出与所述关键字相对应的报文消息的消费轨迹。

优选的，上述分布式消息处理方法中，生成并输出与所述关键字相对应的报文消息的消费轨迹之后，还包括：

依据所述消费轨迹对所述报文消息进行故障定位，并输出定位结果。

一种分布式消息处理系统，包括：

消息生产模块，用于生成业务消息，提供将业务消息发送至代理模块的消息输出接口，当有业务消息由所述消息输出接口输出时，将与输出的所述业务消息相对应的生产者信息存储至本地日志文件中；

代理模块，用于缓存接收到的业务消息，并将获取到的业务消息的存储位置和存储时间保存至本地日志文件中；

消费模块，用于由所述代理模块中提取业务消息并作相应处理，将处理的业务消息的消费信息存储至本地日志文件中；

日志提取模块，用于获取所述消息生产模块、代理模块和消费模块的本地日志文件,所述本地日志文件存储有各个业务消息的发送和接收情况以及与发送和接收的业务消息相关联的业务消息的业务内容；

消费轨迹查询模块，用于依据获取到的关键字对获取到的消息消费者、消息生产者和消息代理的本地日志文件中的内容进行查询，输出获取消息消费者、消息生产者和消息代理的本地日志文件中存储的与所述关键字相对应的日志条目至显示模块进行显示，所述关键字为所需查找的业务消息的消息属性。

优选的，上述分布式消息处理系统中，所述生产者信息至少包括：各个业务消息对应的生产者客户端IP、发送时间、发送状态标识、发送耗时、业务消息ID以及业务消息的业务内容；所述消费者信息至少包括：各个业务消息对应的消费者客户端IP、投递次数、消费状态标识和消费耗时。

优选的，上述分布式消息处理系统中，所述日志提取模块，具体被配置为：

依据预设频率异步获取消息消费者、消息生产者和消息代理的本地日志文件。

优选的，上述分布式消息处理系统中，所述消费轨迹查询模块，还包括：

消费轨迹生成模块，用于依据与所述关键字相对应的日志条目生成并输出与所述关键字相对应的报文消息的消费轨迹，输出所述消费轨迹至显示模块进行显示。

优选的，上述分布式消息处理系统中，还包括：

故障定位模块，用于依据所述消费轨迹对所述报文消息进行故障定位，并输出定位结果。

基于上述技术方案，本发明实施例提供的上述方案，通过将业务消息的收发情况与业务消息的业务内容相关联，将关联后的数据存储至本地日志文件中，当其中某个业务消息出现故障时，用户输入故障的业务消息的关键字，依据所述关键字对各个所述本地日志文件进行检索，提取与所述关键字相对应的日志条目，用户即可依据提取到的日志条目查看对应的业务消息的完整消费轨迹，从而能够确定该业务消息出现故障的具体位置，方便了异常消息的故障定位。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请实施例公开的一种分布式消息处理方法的流程示意图；

图2为本申请实施例公开的一种分布式消息处理系统的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

针对于现有技术中，用户通过查看客户端的日志信息来分析业务消息异常原因时，无法确定哪些消息是正常发送和接收的，哪些消息是异常的，并且当业务消息在处理过程中出现异常时，用户通常只能看到出现异常的业务内容，无法判断是在业务处理的哪个环节出现异常的，无法将业务内容与日志信息相关联，因此存在故障定位难的问题。

针对于此，本申请公开了一种支持消费轨迹的分布式消息处理方法和系统。通过在业务消息生产和消费时，支持使用者将业务消息与业务内容关联记录输出到本地日志文件中，并对客户端产生的日志数据进行基于业务消息ID的分析展示，从而得到每条业务消息的发送和接收详细信息及与之关联的业务内容，从而便于业务消息的追踪和异常的分析定位。

图1为本申请实施例公开的一种分布式消息处理方法，该方法应用于分布式消息系统中，参见图1，该方法可以包括：

步骤S101：获取本地日志文件；

所述分布式消息系统主要由三个模块组成，这三个模块分别为消息生产者、代理者和消费者，其中，每个模块分别具有一个自己独立的本地日志文件，该日志文件中存储有在处理业务消息的过程中的相关信息，所述相关信息可以包括业务消息的发送和接收情况以及与发送和接收的业务消息相关联的业务消息的业务内容，当然还包括每个业务消息的ID等基本信息，在本步骤中，所获取的本地日志文件为上述三个模块的本地日志文件；

步骤S102：获取检索关键字；

在本步骤中，所述关键字为用户输入的用于查找业务消息的输入信息，其可以为所需查找的业务消息的消息属性，例如：业务消息的ID、业务消息的生成时间、业务消息的部分内容等；所需查找的业务消息指的是与关键字对应的业务消息，其可以为用户想要查找的任意一个业务消息；

步骤S103：依据所述关键字对本地日志文件内容进行检索；

在本步骤中，当获取到所述检索关键字后，依据所述检索关键字对各个本地日志文件中的记录内容进行检索，得到所有相关联的日志条目，当然，如果所述关键字为上述三个本地日志文件中都存储的该关键字时，可以直接调取得到与所述检索关键字所对应的所有的日志条目，如果该关键字为存储于其中一个本地日志文件中的关键字时，通过该关键字无法由其他两个本地日志文件中检索得到相关的日志条目，针对于此，该步骤具体可以为：当由其中某个本地日志文件检索得到一包含有所述检索关键字的日志条目时，获取该日志条目所包含的业务消息的ID，依据所述ID再次对各个本地日志文件重新进行检索，调取各个本地日志文件中包含有该ID的所有的日志条目；

步骤S104：输出并通过显示窗口显示检索得到的所有的日志条目。

通过本申请上述实施例公开的技术方案可见，通过将业务消息的收发情况与业务消息的业务内容相关联，将关联后的数据存储至本地日志文件中，当其中某个业务消息出现故障时，用户输入故障的业务消息的关键字，依据所述关键字对各个所述本地日志文件进行检索，提取与所述关键字相对应的日志条目，用户即可依据提取到的日志条目查看对应的业务消息的完整消费轨迹，从而能够确定该业务消息出现故障的具体位置，方便了异常消息的故障定位。

在本申请上述实施例公开的技术方案中，用户可以依据自身需求确定所述本地日志文件中所存储的日志的日志内容，例如，所述消息生产者模块的本地日志文件中，所述生产者信息的内容至少可以包括：各个业务消息对应的生产者客户端IP、发送时间、发送状态标识(表征发送成功与否)、发送耗时(业务消息由生成到发送所用的时间)、业务消息ID以及该业务消息所包含的业务内容等；所述代理者的本地日志文件所包含的代理信息的内容至少包括各个业务消息的存储位置以及存储时间等；所述消费者的本地日志文件中所存储的消费者信息至少可以包括：各个业务消息对应的消费者客户端IP、业务消息的投递次数、消费状态标识(是否成功对该业务消息进行了处理)、消费耗时(由提取到所述业务消息到处理完成该业务消息)等。通过依据输入的关键字对本地日志文件中的上述内容进行检索，即可得到与关键字相对应的各个日志条目。

在本申请上述实施例公开的技术方案中，在由消息消费者、消息生产者和消息代理中提取各个本地日志文件时，可采用异步提取的方式进行提取，其提取方式可以为每隔预设时间段自动提取一次，或者是当需要时用户输出提取指令，手动提取上述各个模块中的本地日志文件。

在本申请上述实施例公开的技术方案中，为了方便用户查看提取得到的业务消息的消费轨迹，本申请还可在提取得到关键字对应的各个日志条目后，依据各个日志条目的时间节点对各个日志条目进行拼接，形成所述业务消息的完整的消费轨迹，从而方便了用户查看。

除了用户通过输入的关键字主动查询某个业务消息的消费轨迹之外，本申请上述方案中还可以自动检索处理过程中存在异常的业务消息，即，当获取到上述各个模块的本地日志文件后，依据各个日志文件中业务消息的ID，将各个日志文件中的日志条目进行分类，将具备同一业务消息ID的日志条目进行整合，组成该业务消息的消费轨迹，通过判断所述消费轨迹的完整性的方式来判断该业务消息ID对应的业务消息是否在处理过程中存在异常的情况，输出不完整的消费轨迹，所述消费轨迹中至少应包括该消费轨迹对应的业务消息的消息内容。

在本申请上述实施例公开的技术方案中，当确定消费轨迹之后，为了便于用户故障定位，本申请上述实施例公开的技术方案中，还可以依据所述消费轨迹对所述报文消息进行故障定位，并输出定位结果。如果消费轨迹为正常轨迹，则，其应是完整的轨迹，如果消费轨迹存在异常时，其部分内容应该缺失，从而导致其不完整，因此，可以通过判断所述消费轨迹的完整性的方式所述消费轨迹是否存在断点，由于不同终端所负责的消息轨迹中的内容不同，因此，可通过断点位置确定出现故障的终端设备，即：在故障定位过程中，可以通过如下方式进行定位：判断所述消费轨迹是否存在断点，如果是，判断并输出断点位置所对应的终端设备。

业务方在使用应用有本申请上述实施例公开的方法的消息系统时，在发送业务消息时支持将业务消息的的业务内容与所发送的业务消息的记录信息进行关联并记录在本地日志中，便于用户基于业务内容搜索业务消息的详情。通过异步收集各个模块的日志文件，然后通过基于文本检索的日志查询引擎进行查询每条业务消息的收发详情信息。

对应于上述方法，本申请还公开了一种分布式消息处理系统，参见图2，该系统可以包括：

消息生产模块100(对应于上文中的消息生产者)：用于生成业务消息，提供将业务消息发送至代理模块的消息输出接口，当有业务消息由所述消息输出接口输出时，将与输出的所述业务消息相对应的生产者信息存储至本地日志文件中；

代理模块200(对应于上文中的代理者)，用于缓存接收到的业务消息，并将获取到的业务消息的存储位置和存储时间保存至本地日志文件中；

消费模块300(对应于上文中的消息消费者)，用于由所述代理模块200中提取业务消息并作相应处理，将处理的业务消息的消费信息存储至本地日志文件中,所述本地日志文件存储有各个业务消息的发送和接收情况以及与发送和接收的业务消息相关联的业务消息的业务内容；

日志提取模块400，用于获取所述消息生产模块100、代理模块200和消费模块300的本地日志文件；

消费轨迹查询模块500，用于依据获取到的关键字对获取到的消息生产模块100、代理模块200和消费模块300的本地日志文件中的内容进行查询，输出消息消费者、消息生产者和消息代理的本地日志文件中存储的与所述关键字相对应的日志条目至显示模块进行显示，所述关键字为所需查找的业务消息的消息属性；

如果该关键字为存储于其中一个本地日志文件中的关键字时，通过该关键字无法由其他两个本地日志文件中检索得到相关的日志条目，针对于此，所述消费轨迹查询模块500具体可以被配置为：当由其中某个本地日志文件检索得到一包含有所述检索关键字的日志条目时，获取该日志条目所包含的业务消息的ID，依据所述ID再次对各个本地日志文件进行检索，调取各个本地日志文件中报刊有该ID的所有的日志条目。

与上述方法相对应，所述日志提取模块400，具体可以被配置为：

依据预设频率异步获取消息消费模块、消息生产模块和消息代理模块的本地日志文件，或者是依据用户输入的触发信号，由所述消息消费模块、消息生产模块和消息代理模块中调取各个模块的本地日志文件。

与上述方法相对应，所述消费轨迹查询模块500，还包括：

消费轨迹生成模块，用于依据与所述关键字相对应的日志条目生成并输出与所述关键字相对应的报文消息的消费轨迹，输出所述消费轨迹至显示模块进行显示。

与上述方法相对应，所述消费轨迹查询模块500中还可以配置有，异常消息自动提取模块，用于：当获取到上述各个模块的本地日志文件后，依据各个日志文件中业务消息的ID，将各个日志文件中的日志条目进行分类，将具备同一业务消息ID的日志条目进行整合，组成该业务消息的消费轨迹，通过判断所述消费轨迹的完整性的方式来判断该业务消息ID对应的业务消息是否在处理过程中存在异常的情况，输出不完整的消费轨迹至显示模块，所述消费轨迹中至少应包括该消费轨迹对应的业务消息的消息内容。

对应于上述方法，本申请上述系统中还可以包括故障定位模块，其用于依据所述消费轨迹对所述报文消息进行故障定位，并输出定位结果。其具体可以通过如下方式对故障进行定位：判断所述消费轨迹的完整性的方式所述消费轨迹是否存在断点，由于不同终端所负责的消息轨迹中的内容不同，因此，可通过断点位置确定出现故障的终端设备，即：在故障定位过程中，可以通过如下方式进行定位：判断所述消费轨迹是否存在断点，如果是，判断并输出断点位置所对应的终端设备。

为了描述的方便，描述以上系统时以功能分为各种模块分别描述。当然，在实施本申请时可以把各模块的功能在同一个或多个软件和/或硬件中实现。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

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

获取消息消费者、消息生产者和消息代理的本地日志文件，所述本地日志文件存储有各个业务消息的发送和接收情况以及与发送和接收的业务消息相关联的业务消息的业务内容；

依据获取到的关键字对获取到的消息消费者、消息生产者和消息代理的本地日志文件中的内容进行查询，输出获取消息消费者、消息生产者和消息代理的本地日志文件中存储的与所述关键字相对应的日志条目，所述关键字为所需查找的业务消息的消息属性。

2.根据权利要求1所述的分布式消息处理方法，其特征在于，

所述消息生产者的本地日志文件中存储有生产者信息，所述生产者信息至少包括：各个业务消息对应的生产者客户端IP、发送时间、发送状态标识、发送耗时、业务消息ID以及业务消息的业务内容；

所述消费者的本地日志文件中存储有消费者信息，所述消费者信息至少包括：各个业务消息对应的消费者客户端IP、投递次数、消费状态标识和消费耗时；

所述代理者的本地日志文件中存储有代理信息，所述代理信息至少包括：各个业务消息的存储位置和存储时间。

3.根据权利要求1所述的分布式消息处理方法，其特征在于，获取消息消费者、消息生产者和消息代理的本地日志文件，具体为：

异步获取消息消费者、消息生产者和消息代理的本地日志文件。

4.根据权利要求1所述的分布式消息处理方法，其特征在于，依据获取到的关键字对获取到的本地日志文件中的内容进行查询之后，还包括：

依据与所述关键字相对应的日志条目生成并输出与所述关键字相对应的报文消息的消费轨迹。

5.根据权利要求4所述的分布式消息处理方法，其特征在于，生成并输出与所述关键字相对应的报文消息的消费轨迹之后，还包括：

依据所述消费轨迹对所述报文消息进行故障定位，并输出定位结果。

6.一种分布式消息处理系统，其特征在于，包括：

消息生产模块，用于生成业务消息，提供将业务消息发送至代理模块的消息输出接口，当有业务消息由所述消息输出接口输出时，将与输出的所述业务消息相对应的生产者信息存储至本地日志文件中；

代理模块，用于缓存接收到的业务消息，并将获取到的业务消息的存储位置和存储时间保存至本地日志文件中；

消费模块，用于由所述代理模块中提取业务消息并作相应处理，将处理的业务消息的消费信息存储至本地日志文件中；

日志提取模块，用于获取所述消息生产模块、代理模块和消费模块的本地日志文件,所述本地日志文件存储有各个业务消息的发送和接收情况以及与发送和接收的业务消息相关联的业务消息的业务内容；

消费轨迹查询模块，用于依据获取到的关键字对获取到的消息消费者、消息生产者和消息代理的本地日志文件中的内容进行查询，输出获取消息消费者、消息生产者和消息代理的本地日志文件中存储的与所述关键字相对应的日志条目至显示模块进行显示，所述关键字为所需查找的业务消息的消息属性。

7.根据权利要求6所述的分布式消息处理系统，其特征在于，所述生产者信息至少包括：各个业务消息对应的生产者客户端IP、发送时间、发送状态标识、发送耗时、业务消息ID以及业务消息的业务内容；所述消费者信息至少包括：各个业务消息对应的消费者客户端IP、投递次数、消费状态标识和消费耗时。

8.根据权利要求6所述的分布式消息处理系统，其特征在于，所述日志提取模块，具体被配置为：

依据预设频率异步获取消息消费者、消息生产者和消息代理的本地日志文件。

9.根据权利要求6所述的分布式消息处理系统，其特征在于，所述消费轨迹查询模块，还包括：

消费轨迹生成模块，用于依据与所述关键字相对应的日志条目生成并输出与所述关键字相对应的报文消息的消费轨迹，输出所述消费轨迹至显示模块进行显示。

10.根据权利要求9所述的分布式消息处理系统，其特征在于，还包括：

故障定位模块，用于依据所述消费轨迹对所述报文消息进行故障定位，并输出定位结果。