CN108089915B - 基于消息队列的业务控件化处理的方法及系统 - Google Patents

Abstract

本发明涉及一种基于消息队列的业务控件化处理的方法，其包括以下步骤：S1：将业务分为一个或多个业务块；S2：业务监听器通过分析所述业务判定待处理的业务块；S3：根据业务块类型选择业务块处理器，以处理所述业务块；S4：判断所述业务块是否存在后续业务块；若存在，则将业务块消息发送至消息队列，并执行步骤S2；否则将由业务块处理器处理所述业务块获得的处理结果存储在数据库中；其中，所述业务块消息包括所述后续业务块的信息和所述处理结果。本发明还公开了一种基于消息队列的业务控件化处理的系统。

Description

基于消息队列的业务控件化处理的方法及系统

技术领域

本发明涉及计算机网络技术领域，尤其涉及基于消息队列的业务控件化处理的方法及系统。

背景技术

在基于电子商务的业务中，多采用微服务的方式，一个业务可能会涉及到很多系统的调用，如果中间出现异常，则需要重新再运行一遍。这不仅影响效率，而且可能会重复执行某些数据库的插入操作，导致系统出现异常。

目前有基于事件驱动的Actor模型，比如Akka，其中Akka是一个用Scala编写的库，用于简化编写容错的、高可伸缩性的Java和Scala的Actor模型应用。采用Akka框架，消息发送的可靠性的保障，以及消息消费的防重机制略显复杂，不便于快速学习。并且，采用该方法还需要搭建一套全新的分布式环境，从而导致系统的维护成本较高。同时，Akka框架没有提供开源的消息监控界面，不利于从整体上把握系统的性能。

发明内容

有鉴于此，本发明提供一种基于消息队列的业务控件化处理的方法及系统，能够将一个业务细分为多个可复用的业务块，并为每个业务块定义一个业务块类型。根据业务块类型选择用于处理所述业务块的业务块处理器，通过发送消息的方式实现不同业务块之间的交互。

为实现上述目的，根据本发明的一个方面，提供了一种基于消息队列的业务控件化处理的方法。

本发明的方法包括以下步骤：

S1：将业务分为一个或多个业务块；

S2：业务监听器通过分析所述业务判定待处理的业务块；

S3：根据业务块类型选择业务块处理器，以处理所述业务块；

S4：判断所述业务块是否存在后续业务块；若存在，则将业务块消息发送至消息队列，并执行步骤S2；否则将由业务块处理器处理所述业务块获得的处理结果存储在数据库中；其中，所述业务块消息包括所述后续业务块的信息和所述处理结果。

可选地，该方法还包括：在步骤S3之前，判断内存数据库中是否存在所述业务的标记信息；若存在，则结束；否则执行步骤S3，并将所述业务的标记信息存储在所述内存数据库中。

可选地，该方法还包括：判断将业务块消息发送至消息队列是否成功；若不成功，则根据消息队列的重试机制将所述业务块消息发送至所述消息队列；若仍未成功，则将所述业务块消息发送至内存数据库；创建启动任务，并设置所述启动任务的启动时间；其中，所述启动任务为将内存数据库的任务队列中的业务块消息发送至消息队列。

可选地，该方法还包括：判断在消费消息时是否出现异常；若出现异常，则将所述业务块消息发送至110异常处理队列中，并执行步骤S3；否则，执行步骤S4。

可选地，该方法还包括：根据所述业务设置主题；在步骤S4中，将业务块消息发送至与所述主题相对应的消息队列，并且将所述业务块消息存储在所述主题下。

可选地，设置所述内存数据库存储所述标记信息的时效，达到所述时效，删除所述内存数据库中存储的所述标记信息。

根据本发明的另一方面，提供了一种基于消息队列的业务控件化处理的系统。

本发明的系统包括：拆分模块，用于将业务分为一个或多个业务块；

监听模块，用于通过分析所述业务判定待处理的业务块；

处理模块，用于根据业务块类型选择业务块处理器，以处理所述业务块；

后续业务块判断模块，用于判断所述业务块是否存在后续业务块；若存在，则将业务块消息发送至消息队列，并且所述监听模块通过分析所述业务判定待处理的业务块；否则将由处理模块处理所述业务块获得的处理结果存储在数据库中；其中，所述业务块消息包括所述后续业务块的信息和所述处理结果。

可选地，该系统还包括标记信息判断模块，用于判断内存数据库中是否存在所述业务的标记信息，若存在，则结束；否则将所述业务的标记信息存储在所述内存数据库中，并且所述处理模块根据业务块类型选择业务块处理器，以处理所述业务块。

可选地，该系统还包括业务块消息发送异常处理模块，用于判断将业务块消息发送至消息队列是否成功；若不成功，则根据消息队列的重试机制将所述业务块消息发送至所述消息队列；若仍未成功，则还将所述业务块消息发送至内存数据库；以及所述业务块消息发送异常处理模块还用于创建启动任务，并设置所述启动任务的启动时间；其中，所述启动任务为将内存数据库的任务队列中的业务块消息发送至消息队列。

可选地，该系统还包括消费消息异常处理模块，用于判断在消费消息时是否出现异常；若出现异常，则将所述业务块消息发送至110异常处理队列中，并且所述处理模块根据业务块类型选择业务块处理器，以处理所述业务块；否则，所述后续业务块判断模块判断所述业务块是否存在后续业务块。

可选地，该系统还包括主题设置模块，用于根据所述业务设置主题；以及后续业务块判断模块还用于将业务块消息发送至与所述主题相对应的消息队列，以便所述业务块消息存储在所述主题下。

可选地，标记信息判断模块还用于设置述内存数据库存储所述标记信息的时效，达到所述时效，删除所述内存数据库中存储的所述标记信息。

根据本发明的另一方面，提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现上述任一项的基于消息队列的业务控件化处理的方法。

根据本发明的另一方面，提供了一种计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现上述任一项的基于消息队列的业务控件化处理的方法。

根据本发明的技术方案，通过通用的消息队列实现了业务控件化处理，将业务分为一个或多个业务块，提高了业务的复用性。在业务块运行过程中，会判断所述业务块是否存在后续业务块；若存在，则将业务块消息发送至消息队列。并且每个业务块发送异常时，通过消息队列自身的重试机制来处理，避免业务其它环节不必要的重试处理，进而提高了业务的容错性和运行效率。同时与其它的事件驱动模型相比，减少了系统的可维护性，并提高了系统的易用性。

附图说明

附图用于更好地理解本发明，不构成对本发明的不当限定。其中：

图1是根据本发明实施例的基于消息队列的业务控件化处理的方法主要步骤的示意图；

图2是根据本发明实施例的基于消息队列的业务控件化处理的系统主要模块的示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

图1是根据本发明实施例的基于消息队列的业务控件化处理的方法主要步骤的示意图。

如图1所示，本发明实施例的一种基于消息队列的业务控件化处理的方法的主要步骤包括：

S11：将业务分为一个或多个业务块。

将一个业务细分为多个可复用的业务块，并为每一个业务块定义一个业务块类型。定义业务块类型之后，监听器会根据业务块类型确定执行其对应的处理方法。

S12：业务监听器通过分析业务判定待处理的业务块。

业务监听器用来监听消息队列(MQ)中对应主题的消息，监听器会分析当前的业务，首先决定调用哪个起始的业务块。

S13：根据业务块类型选择业务块处理器，以处理业务块。

从简单工厂和策略模式中选择业务块对应的业务块处理器执行业务逻辑，其中，业务逻辑就是这个业务要具体执行的活动。但是，在业务块处理器处理业务块之前，判断内存数据库中是否存在业务的标记信息；若存在，则结束；否则执行步骤S13，并将业务的标记信息存储在内存数据库中。例如，在执行业务逻辑前，先在内存数据库中验证此业务块对应的业务ID是否曾经执行过，若已执行，则返回。若未执行，处理当前业务逻辑后，将当前业务ID存入内存数据库，以备防重，从而避免消息队列出现异常，重复消费消息。

其中，还可设置内存数据库存储标记信息的时效，达到时效则删除内存数据库中存储的标记信息。内存数据库的防重数据会比较多，通常将其时效设置为24小时。消息队列出现异常时导致重复发送的消息，一般在发生在几个小时之内，24小时的防重时效足以覆盖当前所有的异常消息。

S14：判断业务块是否存在后续业务块；若存在，则执行S16，将业务块消息发送至消息队列，并执行步骤S12；否则执行S15，将由业务块处理器处理业务块获得的处理结果存储在数据库中。其中，业务块消息包括后续业务块的信息和处理结果。

根据业务设置主题,在步骤S14中，将业务块消息发送至与所述主题相对应的消息队列，并且将所述业务块消息存储在所述主题下，便于业务监听器的监听。

若后续仍有业务块需要处理，则发送业务块信息至消息队列。例如，一个业务包含3个业务块，其分别为业务块101、业务块102和业务块103，在业务块101处理完后，会携带业务块102的信息，发送至消息队列。同理，业务块102处理完之后，会携带业务块103的信息再发送至消息队列。

在发送业务块消息时，判断将业务块消息发送至消息队列是否成功。若不成功，则根据消息队列的重试机制将业务块消息发送至消息队列；若仍未成功，则将业务块消息发送至内存数据库；并创建启动任务，设置启动任务的启动时间。其中，启动任务为将内存数据库的任务队列中的业务块消息发送至消息队列。也就是说，在发送业务块消息出现异常时，消息队列自身会进行几次重试。若重试失败，系统将业务块消息发送至内存数据库的任务队列中。然后创建一个启动任务，每隔一定时间从内存数据库的任务队列中拉取任务，然后再发送至消息队列对应的主题中。针对监听的外部消息，由于不能重新发送至原主题，将其重新放入一个异常主题中(将异常主题命名为110主题)。监听器会监听到消息后重新执行业务逻辑。110主题中的消息由110异常监听器监听，并且110主题中的消息已经携带了业务块类型，所以可以直接调用简单工厂中的业务块处理器。

判断在消费消息时是否出现异常；若出现异常，则将业务块消息发送至110异常处理队列中，并执行步骤S13；否则，执行步骤S14。在消费消息时，若出现异常，首先消息队列自身会进行重试。在消息队列重试达到指定的次数之后，系统会停止重试，然后将这条消息再发送至消息队列中，以避免消息队列因为自身的机制将这条异常消息清除掉。

图2是根据本发明实施例的基于消息队列的业务控件化处理的系统主要模块的示意图。

如图2所示，本发明实施例的基于消息队列的业务控件化处理的系统2的主要模块包括：拆分模块21、监听模块22、处理模块23和后续业务块判断模块24。其中，拆分模块21用于将业务分为一个或多个业务块。监听模块22用于通过分析业务判定待处理的业务块。处理模块23用于根据业务块类型选择业务块处理器，以处理业务块。后续业务块判断模块24用于判断业务块是否存在后续业务块；若存在，则将业务块消息发送至消息队列，并且监听模块通过分析业务判定待处理的业务块；否则将由处理模块处理业务块获得的处理结果存储在数据库中；其中，业务块消息包括后续业务块的信息和处理结果。

该系统还包括标记信息判断模块，用于判断内存数据库中是否存在业务的标记信息，若存在，则结束；否则将业务的标记信息存储在内存数据库中，并且处理模块根据业务块类型选择业务块处理器，以处理业务块。标记信息判断模块还用于设置述内存数据库存储标记信息的时效，达到时效则删除内存数据库中存储的标记信息。

该系统还包括业务块消息发送异常处理模块，用于判断将业务块消息发送至消息队列是否成功；若不成功，则根据消息队列的重试机制将业务块消息发送至消息队列；若仍未成功，则还将业务块消息发送至内存数据库；以及业务块消息发送异常处理模块还用于创建启动任务，并设置启动任务的启动时间；其中，启动任务为将内存数据库的任务队列中的业务块消息发送至消息队列。

该系统还包括消费消息异常处理模块，用于判断在消费消息时是否出现异常；若出现异常，则将业务块消息发送至110异常处理队列中，并且处理模块根据业务块类型选择业务块处理器，以处理业务块；否则，后续业务块判断模块判断业务块是否存在后续业务块。

主题设置模块，用于根据业务设置主题；以及后续业务块判断模块还用于将业务块消息发送至与主题相对应的消息队列，以便业务块消息存储在主题下。

监听模块21将一个业务细分为多个可复用的业务块，并为每个业务块定义一个业务块类型。监听器从简单工厂中选择出待处理的业务块对应的业务块处理器，其中，每个业务块对应一个处理器，通过发送消息的方式实现不同业务块之间的交互。但是在业务块处理器处理之前，标记信息判断模块判断内存数据库中是否存在业务的标记信息(例如业务ID)，若存在，说明该业务曾被执行过，则不进行重复执行。若不存在，则业务块处理器执行该业务块，并将该业务块对应的业务ID存储在内存数据库中，以备之后验证。业务块处理器处理之后，将处理后的结果发送至消息队列或数据库。若后续业务块判断模块判断该业务块存在后续业务块，则还要将该后续业务块的信息发送至消息队列。

但若在发送业务块消息时出现异常，每个业务块发送异常时，MQ自身会进行几次重试。若重试失败，系统将业务块消息发送至内存数据库的任务队列中。然后创建一个启动任务，每隔一定时间从内存数据库的任务队列中拉取任务，然后再发送至MQ对应的主题中。针对监听的外部消息，由于不能重新发送至原主题，将其重新放入一个异常主题中(本系统将异常主题命名为110主题)。业务监听器会监听到消息后重新执行业务逻辑。通过消息队列自身的重试机制来处理，避免业务其它环节不必要的重试处理。

若在消费消息时出现异常，则MQ自身会进行重试。在MQ重试达到指定的次数之后，系统会停止重试，然后将这条消息再发送至消息队列中，以避免消息队列因为自身的机制将这条异常消息清除掉。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。

Claims (12)

1.一种基于消息队列的业务控件化处理的方法，其特征在于，包括以下步骤：

S1：将业务分为一个或多个业务块；

S2：业务监听器通过分析所述业务判定待处理的业务块；

S3：根据业务块类型选择业务块处理器，以处理所述业务块；

S4：判断所述业务块是否存在后续业务块；若存在，则将业务块消息发送至消息队列，并执行步骤S2；否则将由业务块处理器处理所述业务块获得的处理结果存储在数据库中；其中，所述业务块消息包括所述后续业务块的信息和所述处理结果；

其中，判断将业务块消息发送至消息队列是否成功；若不成功，则根据消息队列的重试机制将所述业务块消息发送至所述消息队列；若仍未成功，则将所述业务块消息发送至内存数据库；

创建启动任务，并设置所述启动任务的启动时间；其中，所述启动任务为将内存数据库的任务队列中的业务块消息发送至消息队列。

2.根据权利要求1所述的方法，其特征在于，还包括：

在步骤S3之前，判断内存数据库中是否存在所述业务的标记信息；若存在，则结束；否则执行步骤S3，并将所述业务的标记信息存储在所述内存数据库中。

3.根据权利要求1所述的方法，其特征在于，还包括：

判断在消费消息时是否出现异常；若出现异常，则将所述业务块消息发送至110异常处理队列中，并执行步骤S3；否则，执行步骤S4。

4.根据权利要求1所述的方法，其特征在于，还包括：

根据所述业务设置主题；

在步骤S4中，将业务块消息发送至与所述主题相对应的消息队列，并且将所述业务块消息存储在所述主题下。

5.根据权利要求2所述的方法，其特征在于，设置所述内存数据库存储所述标记信息的时效，达到所述时效，删除所述内存数据库中存储的所述标记信息。

6.一种基于消息队列的业务控件化处理的系统，其特征在于，包括：

拆分模块，用于将业务分为一个或多个业务块；

监听模块，用于通过分析所述业务判定待处理的业务块；

处理模块，用于根据业务块类型选择业务块处理器，以处理所述业务块；

后续业务块判断模块，用于判断所述业务块是否存在后续业务块；若存在，则将业务块消息发送至消息队列，并且所述监听模块通过分析所述业务判定待处理的业务块；否则将由处理模块处理所述业务块获得的处理结果存储在数据库中；其中，所述业务块消息包括所述后续业务块的信息和所述处理结果；

其中，业务块消息发送异常处理模块，用于判断将业务块消息发送至消息队列是否成功；若不成功，则根据消息队列的重试机制将所述业务块消息发送至所述消息队列；若仍未成功，则还将所述业务块消息发送至内存数据库；以及

所述业务块消息发送异常处理模块还用于创建启动任务，并设置所述启动任务的启动时间；其中，所述启动任务为将内存数据库的任务队列中的业务块消息发送至消息队列。

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

标记信息判断模块，用于判断内存数据库中是否存在所述业务的标记信息；若存在，则结束；否则将所述业务的标记信息存储在所述内存数据库中，并且所述处理模块根据业务块类型选择业务块处理器，以处理所述业务块。

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

消费消息异常处理模块，用于判断在消费消息时是否出现异常；若出现异常，则将所述业务块消息发送至110异常处理队列中，并且所述处理模块根据业务块类型选择业务块处理器，以处理所述业务块；否则，所述后续业务块判断模块判断所述业务块是否存在后续业务块。

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

主题设置模块，用于根据所述业务设置主题；以及

后续业务块判断模块还用于将业务块消息发送至与所述主题相对应的消息队列，以便所述业务块消息存储在所述主题下。

10.根据权利要求7所述的系统，其特征在于，标记信息判断模块还用于设置述内存数据库存储所述标记信息的时效，达到所述时效，删除所述内存数据库中存储的所述标记信息。

11.一种电子设备，其特征在于，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-5中任一所述的方法。

12.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1-5中任一所述的方法。

Images