CN107464088A - 基于消息队列的业务处理系统及方法 - Google Patents

Abstract

本申请公开一种基于消息队列的业务处理系统及方法。该系统包括：业务环节处理器集合、消息表及消息队列；其中，所述业务环节处理器集合包括多个业务环节处理器，各依次排列的业务环节处理器分别用于按照业务的业务流程顺序处理所述业务各业务环节的业务逻辑；所述消息表用于存储所述多个业务环节处理器产生的消息，并通过一定时任务将其中未发送过的消息加载到所述消息队列中；所述消息队列用于将从所述消息表收到的消息分发到相应的所述业务环节处理器中，以驱动所述业务环节处理器处理其对应业务环节的业务逻辑。该系统能够减少因单点业务故障而对整个业务的影响，应对业务的快速增长。

Description

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

技术领域

本发明涉及电子商务技术，具体而言，涉及一种基于消息队列的业务处理系统及方法。

背景技术

在电商平台提供的购票(如火车票、机票、门票等)业务中，包含查询、预订、出票、退票/款等诸多流程，相关业务环节之间互相依赖，耦合度过高，每个业务环节的故障皆有可能导致整体业务的不可用甚至瘫痪，严重影响了业务的运营。同时，业务的排查和解决方法效率低下，不能在第一时间准确地锁定问题，导致故障排查难度加大。

目前，一些小型系统采用订单表扫描的方式解决上述问题。将各个业务环节均设计成定时任务，每个定时任务定时扫描订单表获取该任务需要的订单，该定时任务用订单来执行该业务环节的业务逻辑。但随着订单量的增长，各个定时任务对订单表的频繁扫描会对订单表造成很大的压力，并且由于定时任务需要扫描全部的订单数据，因此也无法对订单表进行分表处理。

另外一些中型系统采用任务表扫描的方式解决上述问题。将各个业务环节产生的对应任务数据存储到任务表，并各个业务环节都设计成定时任务，每个定时任务扫描任务表获取某种类型的任务数据，定时任务使用该任务数据作为输入参数，来执行业务逻辑。虽然该方法避免了上述订单表扫描方法存在的问题，但也存在一些不足。每个业务环节对应的定时任务只能在单机上运行，因为如果在多台机器上同时启动同一业务环节的定时任务，就会出现把相同的任务数据扫描到不同服务器的业务环节处理器中去处理，出现了重复处理的问题。换言之，业务处理很难在集群中实现分布式处理。

在所述背景技术部分公开的上述信息仅用于加强对本发明的背景的理解，因此它可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

有鉴于此，本发明提供一种基于消息队列的业务处理系统及方法，能够减少因单点业务故障而对整个业务的影响，应对业务的快速增长。

本发明的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本发明的实践而习得。

根据本发明的一方面，提供了一种基于消息队列的业务处理系统，包括：业务环节处理器集合、消息表及消息队列；其中，所述业务环节处理器集合包括多个业务环节处理器，各依次排列的业务环节处理器分别用于按照业务的业务流程顺序处理所述业务各业务环节的业务逻辑；当所述多个业务环节处理器的其中之一收到所述消息队列中对应类型的消息时，处理其对应业务环节的业务逻辑，并当处理完其对应业务环节的业务逻辑时，产生驱动下一个业务环节处理器所需的对应类型的消息，及将所述消息存储到所述消息表中；所述消息表用于存储所述多个业务环节处理器产生的消息，并通过一定时任务将其中未发送过的消息加载到所述消息队列中；所述消息队列用于将从所述消息表收到的消息分发到相应的所述业务环节处理器中，以驱动所述业务环节处理器处理其对应业务环节的业务逻辑。

根据本发明的一实施方式，上述系统还包括：消息历史表，用于存储定期从所述消息表中迁移的已处理消息。

根据本发明的一实施方式，所述消息包括用于唯一标识业务流的业务流ID。

根据本发明的一实施方式，所述多个业务环节处理器架构于多个分布式集群服务器中。

根据本发明的一实施方式，所述消息表存储于一数据库中，所述数据库还包括：消息过滤器，用于当将所述消息表中的消息加载到所述消息队列时，过滤掉预设类型的消息。

根据本发明的另一方面，提供了一种基于消息队列的业务处理方法，应用于基于消息队列的业务处理系统中，所述系统包括：包括多个业务环节处理器的业务环节处理器集合、消息表及消息队列；所述方法包括：当所述多个业务环节处理器的其中之一收到所述消息队列中对应类型的第一消息时，处理其对应业务环节的业务逻辑，并当其处理完对应业务环节的业务逻辑时，产生驱动下一个业务环节处理器所需的对应类型的第二消息，及将所述第二消息存储到所述消息表中；通过一第一定时器任务定期扫描所述消息表，以将所述第二消息加载到所述消息队列中；以及所述消息队列将所述第二消息分发到所述下一个业务环节处理器中，以驱动所述下一个业务环节处理器处理器对应业务环节的业务逻辑。

根据本发明的一实施方式，所述系统还包括：消息历史表，所述方法还包括：通过一第二定时器任务定期对所述消息表中的已处理数据进行迁移，并归档到所述消息历史表中。

根据本发明的一实施方式，所述消息包括用于唯一标识业务流的业务流ID。

根据本发明的一实施方式，所述多个业务环节处理器架构于多个分布式集群服务器中。

根据本发明的一实施方式，所述消息表存储于一数据库中，所述数据库还包括：消息过滤器；所述方法还包括：当将所述消息表中的消息加载到所述消息队列时，所述消息过滤器过滤掉预设类型的消息。

根据本发明的基于消息队列的业务处理系统，通过解耦各业务环节之间的关联关系可以降低开发人员对故障的排查成本，缓解系统压力，应对业务的快速增长。并且该方法可应用于集群系统中，便于系统扩容。此外，该系统可通过对消息的控制，保证消息的可靠交付，从而实现对业务流程的监控。

另外，根据一些实施例，本发明的基于消息队列的业务处理系统，通过一消息历史表，定期对消息表进行迁移、归档，从而避免了消息表中数据量过大的问题。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本发明。

附图说明

通过参照附图详细描述其示例实施例，本发明的上述和其它目标、特征及优点将变得更加显而易见。

图1是根据一示例性实施方式示出的一种基于消息队列的业务处理系统的框图。

图2是根据一示例性实施方式示出的另一种基于消息队列的业务处理系统的框图。

图3是根据一示例性实施方式示出的一种基于消息队列的业务处理方法的流程图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本发明将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。附图仅为本发明的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本发明的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本发明的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知结构、方法、装置、实现或者操作以避免喧宾夺主而使得本发明的各方面变得模糊。

图1是根据一示例性实施方式示出的一种基于消息队列的业务处理系统的框图。如图1所示，基于消息队列的业务处理系统10包括：业务环节处理器集合102、消息表104及消息队列106。

业务环节处理器集合102包括多个业务环节处理器c1～cn，其中每个业务环节处理器处理一个业务中一个业务环节的业务逻辑，依次排列的各业务环节处理器c1～cn按照业务流程顺序处理各业务环节的业务逻辑。

业务环节处理器用于当收到消息队列106中对应类型的消息时，处理该业务环节处理器对应的业务逻辑；以及当处理完其对应的业务逻辑时，产生驱动下一个业务环节处理器所需的对应类型的消息，并将产生的驱动下一个业务环节处理器所需的消息存储到消息表104中。

业务环节处理器收到的消息可以由消息队列106发送给业务环节处理器，也可以由业务环节处理器自己从消息队列106中获取到，本发明不以此为限。

其中一个业务环节处理器对应收到一种类型的消息。这也使得各个业务环节的消息会被分发到集群中各个服务器的业务环节处理器上，实现了负载均衡。也即各业务环节处理器可以架构于多个分布式集群服务器中。因此可以通过添加集群服务器实例数，来扩展处理能力。

每个消息中均包含一个唯一的业务流ID，例如订单号，从而可以通过消息中的该业务流ID实现对业务各个环节产生的消息追踪，实现对某个订单业务的流程追踪和监控。

消息表104用于存储各业务环节处理器c1～cn产生的消息，并通过一定时任务，将其中未发送过的消息加载到消息队列106中。

消息表104例如为数据库系统中的一张用于存储消息的数据表。

此外，在存储该消息表104的数据库中还可以设置一消息过滤器，该消息过滤器用于当将消息表104中的消息加载到消息队列106中时，过滤掉预设类型的消息，也即对于预设类型的消息，不加载到消息队列106中，从而通过对消息的控制来实现对各业务环节的控制。

为了避免上传消息定时任务的单点处理，还可以使用Zookeeper来实现主从故障转移。

消息队列106用于将收到的消息分发到相应业务环节处理器，以驱动该业务环节处理器处理其业务逻辑。

此外，消息队列106在消息因为外部依赖不可用等因素导致处理失败的情况下，还可以通过抛出异常的方式，通知消息队列106重试，来保证消息的可靠交付。

本发明实施方式的基于消息队列的业务处理系统，通过解耦各业务环节之间的关联关系可以降低开发人员对故障的排查成本，缓解系统压力，应对业务的快速增长。并且该方法可应用于集群系统中，便于系统扩容。此外，该系统可通过对消息的控制，保证消息的可靠交付，从而实现对业务流程的监控。

应清楚地理解，本发明描述了如何形成和使用特定示例，但本发明的原理不限于这些示例的任何细节。相反，基于本发明公开的内容的教导，这些原理能够应用于许多其它实施方式。

图2是根据一示例性实施方式示出的另一种基于消息队列的业务处理系统的框图。如图1所示的基于消息队列的业务处理系统10不同之处在于，图2所示的基于消息队列的业务处理系统20还包括：消息历史表208。

消息历史表208也可以为数据库中存储的一张数据表，用于从迁移消息表104中存储的已处理的消息，从而避免消息表104数据量过大的问题。例如可以通过一定时任务定期对消息表104中的已处理数据进行迁移，归档到消息历史表208中。

本发明实施方式的基于消息队列的业务处理系统，通过一消息历史表，定期对消息表进行迁移、归档，从而避免了消息表中数据量过大的问题。

需要注意的是，上述附图中所示的框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

下述为本发明方法实施例，适用于本发明系统实施例。对于本发明方法实施例中未披露的细节，请参照本发明系统实施例。

图3是根据一示例性实施方式示出的一种基于消息队列的业务处理方法的流程图。该基于消息队列的业务处理方法应用于图1或2所示的系统中。如图3所示，基于消息队列的业务处理方法30包括：

在步骤S302中，当业务环节处理器收到消息队列106中对应类型的第一消息时，处理该业务环节处理器对应业务环节的业务逻辑。

以图1中的业务环节处理器c1为例，当业务环节处理器c1收到消息队列106中的消息A时，业务环节处理器c1开始处理其对应的业务逻辑。

业务环节处理器c1收到的消息A可以由消息队列106发送给业务环节处理器c1，也可以由业务环节处理器c1自己从消息队列106中获取到，本发明不以此为限。

在步骤S304中，当该业务环节处理器处理完其对应的业务逻辑时，产生驱动下一个业务环节处理器所需的第二消息。

例如，当业务环节处理器c1处理完其对应的业务逻辑时，产生驱动业务环节处理器c2所需的消息B。

此外，业务环节处理器c1还将消息A标记为已完成。

在步骤S306中，将产生的驱动下一个业务环节处理器所需的对应类型的第二消息存储到消息表104中。

该消息表104例如为数据库系统中的一张用于存储消息的数据表。

产生驱动业务环节处理器c2所需的消息B被存储到消息表104中。

在步骤S308中，通过一定时器任务定期扫描消息表104，以将驱动下一个业务环节处理器所需的第二消息加载到消息队列106中。

通过该步骤，产生驱动业务环节处理器c2所需的消息B被加载到消息队列106中。

通过一定时器任务，消息表104定期将未发送过的消息加载到消息队列106的broker。

为了避免上传消息定时任务的单点处理，还可以使用Zookeeper来实现主从故障转移。

在步骤S310中，消息队列106将该第二消息分发到所述下一个业务环节处理器中，以驱动所述下一个业务环节处理器处理其对应业务环节的业务逻辑。

所述下一个业务环节处理器重复上述过程，直至所有业务环节的业务逻辑被执行完成。

此外，对于图2所示的系统，该方法还可以包括：通过定时器任务定期对消息表104中的已处理数据进行迁移，并归档到消息历史表208中。该定时时长例如可以设置为1天，但本发明不以此为限。通过一消息历史表，定期对消息表进行迁移、归档，可避免了消息表中数据量过大的问题。

此外，存储消息表104的数据库还包括：消息过滤器。该方法还可以包括：当将消息表104中的消息加载到消息队列106时，消息过滤器过滤掉预设类型的消息。也即对于预设类型的消息，不加载到消息队列106中，从而通过对消息的控制来实现对各业务环节的控制。

本发明实施方式的基于消息队列的业务处理方法，通过解耦各业务环节之间的关联关系可以降低开发人员对故障的排查成本，缓解系统压力，应对业务的快速增长。并且该方法可应用于集群系统中，便于系统扩容。此外，该系统可通过对消息的控制，保证消息的可靠交付，从而实现对业务流程的监控。

本领域技术人员可以理解实现上述实施方式的全部或部分步骤被实现为由CPU执行的计算机程序。在该计算机程序被CPU执行时，执行本发明提供的上述方法所限定的上述功能。所述的程序可以存储于一种计算机可读存储介质中，该存储介质可以是只读存储器，磁盘或光盘等。

此外，需要注意的是，上述附图仅是根据本发明示例性实施方式的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本发明实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本发明实施方式的方法。

以上具体地示出和描述了本发明的示例性实施方式。应可理解的是，本发明不限于这里描述的详细结构、设置方式或实现方法；相反，本发明意图涵盖包含在所附权利要求的精神和范围内的各种修改和等效设置。

Claims (10)

1.一种基于消息队列的业务处理系统，其特征在于，包括：业务环节处理器集合、消息表及消息队列；其中，

所述业务环节处理器集合包括多个业务环节处理器，各依次排列的业务环节处理器分别用于按照业务的业务流程顺序处理所述业务各业务环节的业务逻辑；当所述多个业务环节处理器的其中之一收到所述消息队列中对应类型的消息时，处理其对应业务环节的业务逻辑，并当处理完其对应业务环节的业务逻辑时，产生驱动下一个业务环节处理器所需的对应类型的消息，及将所述消息存储到所述消息表中；

所述消息表用于存储所述多个业务环节处理器产生的消息，并通过一定时任务将其中未发送过的消息加载到所述消息队列中；

所述消息队列用于将从所述消息表收到的消息分发到相应的所述业务环节处理器中，以驱动所述业务环节处理器处理其对应业务环节的业务逻辑。

2.根据权利要求1所述的系统，其特征在于，还包括：消息历史表，用于存储定期从所述消息表中迁移的已处理消息。

3.根据权利要求1或2所述的系统，其特征在于，所述消息包括用于唯一标识业务流的业务流ID。

4.根据权利要求1或2所述的系统，其特征在于，所述多个业务环节处理器架构于多个分布式集群服务器中。

5.根据权利要求1或2所述的系统，其特征在于，所述消息表存储于一数据库中，所述数据库还包括：消息过滤器，用于当将所述消息表中的消息加载到所述消息队列时，过滤掉预设类型的消息。

6.一种基于消息队列的业务处理方法，应用于基于消息队列的业务处理系统中，其特征在于，所述系统包括：包括多个业务环节处理器的业务环节处理器集合、消息表及消息队列；所述方法包括：

当所述多个业务环节处理器的其中之一收到所述消息队列中对应类型的第一消息时，处理其对应业务环节的业务逻辑，并当其处理完对应业务环节的业务逻辑时，产生驱动下一个业务环节处理器所需的对应类型的第二消息，及将所述第二消息存储到所述消息表中；

通过一第一定时器任务定期扫描所述消息表，以将所述第二消息加载到所述消息队列中；以及

所述消息队列将所述第二消息分发到所述下一个业务环节处理器中，以驱动所述下一个业务环节处理器处理器对应业务环节的业务逻辑。

7.根据权利要求6所述的方法，其特征在于，所述系统还包括：消息历史表，所述方法还包括：通过一第二定时器任务定期对所述消息表中的已处理数据进行迁移，并归档到所述消息历史表中。

8.根据权利要求6或7所述的方法，其特征在于，所述消息包括用于唯一标识业务流的业务流ID。

9.根据权利要求6或7所述的方法，其特征在于，所述多个业务环节处理器架构于多个分布式集群服务器中。

10.根据权利要求6或7所述的系统，其特征在于，所述消息表存储于一数据库中，所述数据库还包括：消息过滤器；所述方法还包括：当将所述消息表中的消息加载到所述消息队列时，所述消息过滤器过滤掉预设类型的消息。