CN113467898A - 多方协同业务处理方法及系统 - Google Patents

Abstract

本发明涉及一种多方协同业务处理方法及系统。本申请实施例的方法可以包括：宕机重启后，对业务的每个步骤依次执行恢复处理，在某个步骤的执行状态为未执行时，继续所述步骤及其后续的正向处理；在某个步骤的执行状态为失败时，反向撤销业务的已执行步骤。此处，本申请实施例还可以在步骤的执行状态为未知或执行时，通过状态查询动作周期性查询步骤的执行状态，由此，在某些参与方有临时性的故障的情况下，可以等到参与方恢复后立即继续后续的业务处理逻辑。本申请实施例能够在不增加额外处理压力和硬件成本的前提下，解决因业务处理过程中断或异常而导致的全局不一致问题。

Description

多方协同业务处理方法及系统

技术领域

本申请涉及计算机数据处理技术领域，尤其涉及一种多方协同业务处理方法及系统。

背景技术

在很多业务处理系统中，一笔业务处理过程通常都包含很多参与方，不仅包括不同的业务系统，也包括同一业务系统中的不同组件。例如，在金融支付交易处理中，参与方包括：发起支付的业务系统、支付系统、核心记账系统、后端支付通道，而支付系统内部又包括数据库系统、Redis系统等。这些系统协同工作，需要保持数据信息在全局范围的一致性。业界提出了很多解决该问题的方法，例如，基于消息队列的方法和基于反向操作的方法。

基于消息队列的方法核心在于利用一个消息队列在参与方之间传递每个参与方的执行状态，并通过消息队列维护这个业务处理过程的全局一致性。

基于反向操作的方法核心在于对每个参与方的动作定义个反向操作，在依次执行每个参与方的动作时，如果发生异常，则逆序反向执行每个动作的反向操作，从而维护整个业务处理过程的全局一致性。

已有的这些方法虽然从理论上能够做到整个业务处理过程的最终一致性，但在实际的应用场景中均存在以下缺陷和不足：

1. 有的参与方是外部参与方，有可能这些参与方在执行业务操作过程中发生异常，并没有及时地给出执行结果，这会导致整个分布式事务的控制过程发生中断，无法继续处理，哪怕一段时间后该参与方已经恢复正常运行，该笔业务处理过程也无法得到恢复。

2. 如果在一笔业务处理过程中，系统发生故障而导致处理中断，这会导致全局不一致的情况发生，并且都无法进行恢复。

针对上述因业务处理过程中断或异常而导致的全局不一致现象，目前只有采用另外的技术和方法来维护。

发明内容

本申请实施例意在提供一种多方协同业务处理方法及系统，以部分地或全部地解决相关技术中存在的不足。

本申请实施例的第一方面，提供了一种多方协同业务处理方法，包括：

宕机重启后，对第一业务的每个步骤依次执行如下的恢复处理：

执行所述步骤的恢复动作，以检测所述步骤是否已执行和所述步骤的执行状态；

在所述步骤的执行状态为未执行时，继续所述步骤及其后续步骤的正向处理；

在所述步骤的执行状态为失败时，反向撤销所述第一业务的已执行步骤；

其中，所述第一业务为多个参与方协同处理的业务，所述第一业务的每个步骤代表所述第一业务的一个参与方。

一些示例中，所述恢复处理还包括：在所述步骤的执行状态为成功时，继续前一步骤的恢复处理。

一些示例中，所述方法还包括：对所述第一业务的每个步骤依次执行如下的正向处理：对所述步骤执行正向处理动作并获取所述步骤的执行状态；在所述步骤的执行状态为未知或执行中时，周期性地调用状态查询动作查询所述步骤的执行状态。这里，因所述步骤的执行状态为未知或执行中的情况包括所述步骤对应的参与方发生故障的情况以及所述参与方在发生故障后恢复的情况，因此，由此，可以在某些参与方有临时性的故障的情况下，也不会导致业务处理过程完全中断，等到参与方恢复后，可以立即继续后续的业务处理逻辑，从而确保业务的全局一致性。

一些示例中，所述正向处理还包括：在所述步骤的执行状态为成功时，继续下一步骤的正向处理；在所述步骤的执行状态为失败时，反向撤销所述第一业务的已执行步骤。

一些示例中，所述反向撤销所述第一业务的已执行步骤，包括：对所述第一业务的已执行正向处理的每个步骤，逆向依次执行撤销动作，以消除所述步骤所带来的影响。

本申请实施例的第二方面，提供了一种多方协同业务处理系统，包括：调度控制器和与业务的参与方相对应的步骤执行器；

所述调度控制器，用于在宕机重启后，控制每个所述步骤执行器对第一业务的步骤依次执行恢复处理；以及，用于在所述步骤执行器提供的步骤的执行状态为未执行时，控制所述步骤执行器对所述步骤执行正向处理以及控制后续步骤的步骤执行器对相应步骤执行正向处理；以及，用于在所述步骤执行器提供的步骤的执行状态为失败时，控制所述第一业务的已执行步骤的步骤执行器反向撤销所述第一业务的已执行步骤；

所述步骤执行器，用于对所述第一业务的相应步骤执行恢复处理、正向处理或反向撤销，并向所述调度控制器提供所述步骤的执行状态；

其中，所述第一业务为多个所述参与方协同处理的业务，所述第一业务的每个步骤代表所述第一业务的一个参与方。

一些示例中，所述调度控制器，还用于在所述步骤执行器提供的步骤的执行状态为成功时，继续前一步骤的恢复处理。

一些示例中，所述调度控制器，还用于依次控制每个所述步骤执行器执行所述第一业务的相应步骤的正向处理；所述步骤执行器，还用于对所述第一业务的相应步骤执行正向处理，所述正向处理包括：对所述步骤执行正向处理动作并获取所述步骤的执行状态；在所述步骤的执行状态为未知或执行中时，周期性地调用状态查询动作查询所述步骤的执行状态。这里，因所述步骤的执行状态为未知或执行中的情况包括所述步骤对应的参与方发生故障的情况以及所述参与方在发生故障后恢复的情况，因此，由此，可以在某些参与方有临时性的故障的情况下，也不会导致业务处理过程完全中断，等到参与方恢复后，可以立即继续后续的业务处理逻辑，从而确保业务的全局一致性。

一些示例中，所述调度控制器，还用于在所述步骤执行器提供的步骤的执行状态为成功时，控制下一步骤的步骤执行器对所述第一业务的下一步骤执行正向处理；在所述步骤执行器提供的步骤的执行状态为失败时，控制所述第一业务的已执行步骤的步骤执行器反向撤销所述第一业务的已执行步骤。

一些示例中，所述调度控制器，用于控制所述第一业务的已执行步骤的步骤执行器反向撤销所述第一业务的已执行步骤，包括：逆向依次控制所述第一业务的已执行正向处理的每个步骤的步骤执行器对所述第一业务的相应步骤执行撤销动作。

本申请实施例能够在不增加额外处理压力和硬件成本的前提下，解决因业务处理过程中断或异常而导致的全局不一致问题。

附图说明

图1为本申请实施例多方协同业务处理系统的结构示意图。

图2为本申请实施例多方协同业务处理方法的流程示意图。

图3为本申请实施例多方协同业务处理中正向处理的流程示意图。

图4为本申请实施例多方协同业务处理中反向撤销的流程示意图。

图5为本申请实施例多方协同业务处理中恢复处理的流程示意图。

具体实施方式

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

如前文所述，针对上述因业务处理过程中断或异常而导致的全局不一致现象，目前只有采用另外的技术和方法来维护。

一些可能的实现方法中，在支付交易中，会在每日终了的时候，进行各方对账，发现其中的不一致的地方，并进行进一步的差错处理。这种方法的主要缺点在于，中断的业务处理中的信息不能及时正确地反馈，影响业务处理的及时性，无法适用于及时性要求比较高的应用场景。

一些可能的实现方法中，在执行每个步骤时，在另外的存储介质上记录步骤的执行状态，当系统宕机重启后，通过读取这些另外记录的执行状态对整个业务的处理状态进行恢复。但这会在业务的正常执行过程中引入大量的额外的操作，而且都是非常耗时的IO操作，会极大地降低正常情况下的系统性能。

鉴于此，本申请实施例提供一种多方协同业务处理方法及系统，能够在不增加额外处理压力和硬件成本的前提下，解决因业务处理过程中断或异常而导致的全局不一致问题。

图1示出了本申请实施例提供的多方协同业务处理系统100的架构示意图。参见图1所示，本申请实施例提供的多方协同业务处理系统可以包括调度控制器110和多个步骤执行器120，每个步骤执行器120对应业务处理的一个参与方，调度控制器110可用于调度这多个步骤执行器120以实现整个业务的处理。例如，对于需要n（n为不小于1的整数）个参与方协同处理的第一业务，其对应的步骤执行器120有n个，也即，相应的多方协同业务处理系统100可以包括一个调度控制器110和n个步骤执行器120，每个步骤执行器120对应第一业务的一个参与方，负责实现相应参与方需执行的预定义动作。

调度控制器110，可负责一笔业务（例如，交易业务）处理的整体控制。每个步骤执行器120则负责执行一个参与方中包含的若干个预定义的动作，以供调度控制器110控制。

在进行步骤设计时，对每个相对独立的参与方都需要设计单独的步骤。而每个步骤内部的一致性必须要能够由步骤内部的机制来保证，例如依赖步骤内的数据库的事务来实现一致性保证。

在每个业务的处理过程中，本申请实施例的多方协同业务处理系统100可以工作在如下的三种模式：

1）正向处理模式：即正常的业务处理模式，在正向处理模式下，多方协同业务处理系统100可以通过正向处理动作来实现业务的每个步骤的正常处理。

2）反向撤销模式：当业务整体状态为失败时，进入反向撤销模式，在反向撤销模式下，多方协同业务处理系统100可以反向撤销该业务的已执行步骤。

3）恢复模式：当因宕机被中断的业务重新被拉起后，进入恢复模式。该模式下，多方协同业务处理系统100可以通过一系列动作确定业务中断的步骤，并根据恢复状态转为正向处理模式继续业务处理，或者转为反向撤销模式从中断处开始反向撤销业务中已执行的动作。

在每个业务的处理过程中，本申请实施例多方协同业务处理系统100的每个步骤执行器120可具体用于实现如下的4种动作：

1）正向处理动作：即在正常的业务处理过程中，该步骤应该执行的动作。以互联网交易的扣款业务为例，支付方张三需要向商户M支付款项X之后需要对张三的账户扣款X，此时，正向处理动作是扣减张三账户中的款项X。

2）反向撤销动作：即，当业务整体处理失败时，对已经执行了正向处理动作的步骤，需要执行相应的反向撤销动作来消除该步骤已经做出的影响。仍以上述扣款业务为例，反向撤销动作可以是将已扣减的款项X还回到支付方张三的账户。

3）状态查询动作：即，当某个步骤的正向处理动作执行结果未知时（例如，在该步骤对应的参与方发生故障及其故障之后的时段中，该步骤的正向处理动作的执行结果将持续处于未知的状态），可以通过本状态查询动作得到该步骤的正向处理动作的执行结果，是成功还是失败。查询结果也可能继续返回未知，则需要再次调用状态查询动作进行查询，直到明确步骤的执行结果状态，由此，可以在某个参与方发生故障及其故障之后通过持续状态查询来继续相应业务的后续处理，能够在参与方发生故障的情况下业务发生异常之后继续业务的正常处理，从而确保全局一致性。这里，为了不对该步骤对应的业务系统产生过大的压力，两次状态查询动作需要有一定时间间隔，该时间间隔可以是预定时长，预定时长可以根据需要灵活设置。仍以上述扣款业务为例，状态查询动作可以是查询张三账户上款项X的扣减是否成功。

4）恢复动作：即，当系统发生宕机重启后，被中断的业务会切换到恢复模式，依次调用每个步骤的恢复动作，以确定当前步骤的执行状态。仍以上述扣款业务为例，恢复动作可以是检测张三账户上款项X的扣减是否执行以及扣减是成功、失败还是其他的执行状态。

本申请实施例中，步骤的执行状态用于描述步骤的执行情况，调度控制器110可根据步骤的执行状态对各个步骤执行器120进行调度控制，从而完成整个业务的处理。

具体地，步骤的执行状态可以包括如下5种：

1）未执行：步骤还未开始执行正向处理动作。

2）处理中：步骤正在执行正向处理动作。

3）成功：步骤执行正向处理动作成功，该状态是执行最终状态（简称终态）之一。

4）失败：步骤执行正向处理动作失败，需要执行反向撤销动作进行撤销，该状态也是最终状态之一。

5）未知：步骤执行状态未知。

第一业务为多个参与方协同处理的业务，第一业务的每个步骤代表第一业务的一个参与方。以此为例，一些实施例中，调度控制器110，用于在宕机重启后或发生故障的参与方恢复后，控制每个步骤执行器120对第一业务的步骤依次执行恢复处理；以及，用于在步骤执行器120提供的步骤的执行状态为未执行时，控制步骤执行器120对该未执行的步骤执行正向处理以及控制后续步骤的步骤执行器120对相应步骤执行正向处理；以及，用于在步骤执行器120提供的步骤的执行状态为失败时，控制第一业务的已执行步骤的步骤执行器120反向撤销第一业务的已执行步骤。步骤执行器120可用于对第一业务的相应步骤执行恢复处理、正向处理或反向撤销，并向调度控制器110提供步骤的执行状态。

一些实施例中，调度控制器110，还用于在步骤执行器120提供的步骤的执行状态为成功时，继续前一步骤的恢复处理。

本申请实施例的多方协同业务处理系统100针对某一业务的每个步骤，除了执行“正向处理动作”、“反向撤销动作”外，还增加了“状态查询动作”和“恢复动作”这两个基本操作，这样，在系统宕机重启恢复之后，对发生中断的业务，可以通过进入恢复模式，依次从第一个步骤开始执行“恢复动作”，检测每个步骤是否已经执行，以及执行状态如何，如果某个步骤是未执行，那么可以切换到正常模式继续完成后续的步骤。如果检测到某步骤是执行失败，则说明该步骤即为发生中断的步骤，可以自此步骤开始逆向的回滚操作，反向撤销已经执行的步骤，然后再重新执行该业务的每个步骤，由此，当系统宕机后重启，能让被中断业务从中断的位置开始继续后续的步骤，进而实现全局的最终一致性。并且，系统没有在正常处理过程引入任何额外的工作，也没有引入额外的存储，保证了系统的性能，不会给系统带来额外的处理压力和硬件成本。

一些实施例中，调度控制器110，还用于依次控制每个步骤执行器120执行第一业务的相应步骤的正向处理。步骤执行器120，还用于对第一业务的相应步骤执行正向处理，所述正向处理包括：对步骤执行正向处理动作并获取步骤的执行状态；在步骤的执行状态为未知或执行中时，周期性地调用状态查询动作查询步骤的执行状态。由此，可以在依次执行每个步骤的过程中，遇到“正向动作”超时（例如，某些参与方有临时性的故障的情况）或其他类似的情况，不能及时返回步骤的执行状态时，便可以调用该步骤的“状态查询”动作，周期性地查询该参与方对该业务的该步骤的执行状态，直到得到确定的执行状态（即终态）后，再继续业务的后续步骤的处理工作。其中，步骤的执行状态为未知或未执行的情况可以包括所述步骤对应的参与方发生故障的情况以及所述参与方在发生故障后恢复的情况。由此，在某些参与方有临时性的故障的情况下，也不会导致业务处理过程完全中断，可以等到参与方恢复后立即继续后续的业务处理逻辑，从而确保业务的全局一致性。

一些实施例中，调度控制器110，还用于在步骤执行器120提供的步骤的执行状态为成功时，控制下一步骤的步骤执行器120对第一业务的下一步骤执行正向处理；在步骤执行器120提供的步骤的执行状态为失败时，控制第一业务的已执行步骤的步骤执行器120反向撤销第一业务的已执行步骤。

一些实施例中，调度控制器110，用于控制第一业务的已执行步骤的步骤执行器120反向撤销第一业务的已执行步骤，包括：逆向依次控制第一业务的已执行正向处理的每个步骤的步骤执行器120对第一业务的相应步骤执行撤销动作。

由此，可以通过切换到反向撤销模式，依次撤销已执行步骤的影响，这之后再重新进行业务处理，从而解决因系统异常宕机或参与方暂时故障而导致的全局不一致问题。

实际应用中，本申请实施例多方协同业务处理系统可以部署于分布式系统中，或者可通过分布式系统来实现。该分布式系统可以通过服务器或其集群来实现。

图2示出了本申请实施例多方协同业务处理方法200的流程示意图。参见图2所示，本申请实施例多方协同业务处理方法200可以包括如下步骤：

步骤S210，宕机重启后或发生故障的参与方恢复后，对第一业务的每个步骤依次执行如下的恢复处理：

步骤S211，执行步骤的恢复动作，以检测步骤是否已执行和步骤的执行状态；

步骤S212，在步骤的执行状态为未执行时，继续所述步骤及其后续步骤的正向处理；

具体地，若某个步骤的执行状态为未执行，则表明该步骤即为发生中断的步骤，且该发生中断的步骤的执行状态为未执行，可以继续该步骤及其后续步骤的正向处理，由此，可以在业务中断并恢复后立即继续后续的业务处理逻辑。

步骤S213，在步骤的执行状态为失败时，反向撤销第一业务的已执行步骤；

具体地，若某个步骤的执行状态为失败，表明该步骤即为发生中断的步骤，但该发生中断的步骤执行状态为失败，可以通过反向撤销整个业务来重新执行业务，以保证整个业务的全局一致性。

其中，第一业务为多个参与方协同处理的业务，第一业务的每个步骤代表第一业务的一个参与方。

一些实施例中，步骤S210的恢复处理还包括：步骤S214，在步骤的执行状态为成功时，继续前一步骤的恢复处理。具体地，如果某个步骤的执行状态为成功，表明已经成功执行本步骤，可以继续向前恢复，即继续前一步骤的恢复处理。

本申请实施例中，在业务处理过程中，若系统发生宕机或参与方暂时故障，业务处理的整体流程只执行了部分步骤，即使重新拉起业务处理流程也无法获知业务发生中断的步骤是哪个或者在哪里。通过本申请实施例，可以在系统重启或参与方恢复之后业务被重新拉起时，进入恢复模式，通过逐个步骤恢复来找到发生中断的步骤，进而根据该发生中断的步骤的执行状态，切换到正向处理模式或反向撤销模式来继续后续的处理。

一些实施例中，本申请实施例多方协同业务处理方法200还可以包括：步骤S220，对第一业务的每个步骤依次执行如下的正向处理：

步骤S221，对步骤执行正向处理动作并获取所述步骤的执行状态；

步骤S222，在步骤的执行状态为未知或执行中时，周期性地调用状态查询动作查询步骤的执行状态。其中，步骤的执行状态为未知或未执行的情况可以包括所述步骤对应的参与方发生故障的情况以及所述参与方在发生故障后恢复的情况。由此，在某些参与方有临时性的故障的情况下，也不会导致业务处理过程完全中断，可以等到参与方恢复后立即继续后续的业务处理逻辑，从而确保业务的全局一致性。

这里，所述周期性调用状态查询动作查询所述步骤的执行状态，包括：所述状态查询动作的相邻两次调用之间间隔预定时长。其中，预定时长可以自由设定。由此可以降低系统处理压力。

一些实施例中，步骤S220中的正向处理还可以包括：

步骤S223，在步骤的执行状态为成功时，继续下一步骤的正向处理；

步骤S224，在步骤的执行状态为失败时，反向撤销第一业务的已执行步骤。

一些实施例中，反向撤销第一业务的已执行步骤，可以包括：对第一业务的已执行正向处理的每个步骤，逆向依次执行撤销动作，以消除步骤所带来的影响。

本申请实施例的多方协同业务处理方法可以针对某一业务的每个步骤，除了执行“正向处理动作”、“反向撤销动作”外，还增加了“状态查询动作”和“恢复动作”这两个基本操作，这样，可以在某个参与方因暂时故障而不能及时返回业务处理状态继而导致整个业务处理过程异常结束时，在参与方恢复后及时继续处理该笔业务的后续流程。并且，可以在系统异常宕机而导致一笔业务处理流程中断继而导致全局不一致的情况下，系统恢复后可以及时恢复发生中断的业务的处理流程，并且在达到前述目的的基础上，不额外增加正常业务处理过程的负担，也不增加额外的存储需求，可以提高整个业务处理过程的执行效率、降低整个业务处理过程的时间成本和硬件成本。

下面对本申请实施例各技术细节的示例性具体实现方式进行详细说明。

图3示出了正常业务处理过程的流程示意图。参见图3所示，正常业务处理过程的示例性实现流程可以包括：判断是否所有步骤均已执行完毕，如果是，则当前业务正常处理成功，结束当前业务的处理流程。如果仍有步骤没有执行完毕，则进入到下一步骤，执行该步骤的正向处理动作并获取该步骤的执行状态，判断该步骤的执行状态是否为成功，如果该步骤的执行状态为成功，则返回最初的步骤，即判断是否所有步骤均已执行完毕并继续下一步骤的正向处理，如果该步骤的执行状态不是成功，则继续判断该步骤的执行状态是否为失败，如果该步骤的执行状态为失败，则可以切换到反向撤销模式，如果该步骤的执行状态不是失败，则执行该步骤的查询状态动作并获取该步骤的执行状态，然后返回“判断该步骤的执行状态是否为成功”的步骤。

上述正常业务处理过程中，依次执行每个步骤的正向动作，并获取其执行状态，如果某个步骤执行成功，则继续执行下一步骤的正向动作，如果某个步骤执行失败，则切换到反向撤销动作。如果某个步骤执行状态未知或为执行中（例如，所述步骤对应的参与方发生故障的情况），则周期性调用状态查询动作查询该步骤的执行状态，直到该步骤的执行状态为终态，该终态为成功或失败。由此，在某些参与方有临时性的故障的情况下，也不会导致业务处理过程完全中断，可以等到参与方恢复后立即继续后续的业务处理逻辑，从而确保业务的全局一致性。

图4示出了反向撤销模式的示例性实现流程示意图。参见图4所示，反向撤销过程的示例性实现流程可以包括：判断是否所有步骤（即所有已经执行的步骤）均已撤销，如果所有步骤均已撤销，则业务处理失败，结束该业务的反向撤销。如果仍有步骤没有撤销，则后退到前一步骤，执行该前一步骤的反向撤销动作，并继续“判断是否所有步骤均已撤销”，如此循环执行，直到所有步骤均已撤销。该反向撤销的实现过程中，对已经执行完正向处理动作的步骤依次执行反向撤销动作，执行反向撤销动作不再关注执行状态，如果发生撤销异常，可以记录日志，以便后续针对该异常之处进行例如人工等处理。仍以上文扣款业务为例，反向撤销动作就是将扣减的款项X重新加到张三账户上。如果恰好这时张三账户出现问题，无法转入资金（也即无法将款项X重新加到张三账户），这就发生了撤销异常，为了不会因类似的撤销异常影响继续整个业务的反向撤销，可以先记录日志（即记录该撤销异常的具体信息），待后续可通过诸如人工核查、自动核查等方式进行处理即可。

图5示出了恢复模式的示例性实现流程示意图。参见图5所示，业务处理过程恢复的示例性实现流程可以包括：判断是否所有步骤均已恢复，如果仍有步骤未恢复，可以前进到下一个需执行恢复处理的步骤（例如，当前步骤的前一步骤），执行该步骤的恢复动作并获取执行状态，判断该步骤的执行状态是否为成功，如果该步骤的执行状态不是成功，则继续判断该步骤的执行状态是否为失败，如果该步骤的执行状态为失败，可以切换到反向撤销模式，反向撤销该业务的已执行步骤，如果该步骤的执行状态不是失败，可以继续判断该步骤的执行状态是否为未执行，如果该步骤的执行状态为未执行，则切换到正向处理模式，继续该步骤及其后续步骤的正向处理，如果该步骤的执行状态不是未执行，可以重新执行该步骤的恢复动作并获取其执行状态，并重复上述步骤，如果该步骤的执行状态是成功，则继续判断是否所有步骤均已恢复，如此循环，直到所有步骤均已恢复，且各个步骤的执行状态均为终态，结束业务处理过程的恢复。

参见图5所示，在整个恢复过程中，没有依赖正常处理过程中保存的信息，而仅仅通过查询步骤执行状态即可获知步骤的实际执行情况，从而大大降低了系统设计难度和正常处理过程中的系统资源消耗。

应该指出，上述详细说明都是示例性的，旨在对本申请提供进一步的说明。除非另有指明，本文使用的所有技术和科学术语均具有与本申请所属技术领域的普通技术人员的通常理解所相同的含义。

需要注意的是，这里所使用的术语仅是为了描述具体实施方式，而非意图限制根据本申请所述的示例性实施方式。如在这里所使用的，除非上下文另外明确指出，否则单数形式也意图包括复数形式。此外，还应当理解的是，当在本说明书中使用术语“包含”和/或“包括”时，其指明存在特征、步骤、操作、器件、组件和/或它们的组合。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的术语在适当情况下可以互换，以便这里描述的本申请的实施方式能够以除了在这里图示或描述的那些以外的顺序实施。

此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含。例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

在上面详细的说明中，参考了附图，附图形成本文的一部分。在附图中，类似的符号典型地确定类似的部件，除非上下文以其他方式指明。在详细的说明书、附图及权利要求书中所描述的图示说明的实施方案不意味是限制性的。在不脱离本文所呈现的主题的精神或范围下，其他实施方案可以被使用，并且可以作其他改变。

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

Claims (10)

1.一种多方协同业务处理方法，其特征在于，包括：

宕机重启后，对第一业务的每个步骤依次执行如下的恢复处理：

执行所述步骤的恢复动作，以检测所述步骤是否已执行和所述步骤的执行状态；

在所述步骤的执行状态为未执行时，继续所述步骤及其后续步骤的正向处理；

在所述步骤的执行状态为失败时，反向撤销所述第一业务的已执行步骤；

其中，所述第一业务为多个参与方协同处理的业务，所述第一业务的每个步骤代表所述第一业务的一个参与方。

2.根据权利要求1所述的方法，其特征在于，所述恢复处理还包括：在所述步骤的执行状态为成功时，继续前一步骤的恢复处理。

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

对所述第一业务的每个步骤依次执行如下的正向处理：

对所述步骤执行正向处理动作并获取所述步骤的执行状态；

在所述步骤的执行状态为未知或执行中时，周期性地调用状态查询动作查询所述步骤的执行状态。

4.根据权利要求3所述的方法，其特征在于，所述正向处理还包括：

在所述步骤的执行状态为成功时，继续下一步骤的正向处理；

在所述步骤的执行状态为失败时，反向撤销所述第一业务的已执行步骤。

5.根据权利要求1或4所述的方法，其特征在于，所述反向撤销所述第一业务的已执行步骤，包括：对所述第一业务的已执行正向处理的每个步骤，逆向依次执行撤销动作，以消除所述步骤所带来的影响。

6.一种多方协同业务处理系统，其特征在于，包括：调度控制器和与业务的参与方相对应的步骤执行器；

所述调度控制器，用于在宕机重启后，控制每个所述步骤执行器对第一业务的步骤依次执行恢复处理；以及，用于在所述步骤执行器提供的步骤的执行状态为未执行时，控制所述步骤执行器对所述步骤执行正向处理以及控制后续步骤的步骤执行器对相应步骤执行正向处理；以及，用于在所述步骤执行器提供的步骤的执行状态为失败时，控制所述第一业务的已执行步骤的步骤执行器反向撤销所述第一业务的已执行步骤；

所述步骤执行器，用于对所述第一业务的相应步骤执行恢复处理、正向处理或反向撤销，并向所述调度控制器提供所述步骤的执行状态；

其中，所述第一业务为多个所述参与方协同处理的业务，所述第一业务的每个步骤代表所述第一业务的一个参与方。

7.根据权利要求6所述的多方协同业务处理系统，其特征在于，

所述调度控制器，还用于在所述步骤执行器提供的步骤的执行状态为成功时，继续前一步骤的恢复处理。

8.根据权利要求6所述的多方协同业务处理系统，其特征在于，

所述调度控制器，还用于依次控制每个所述步骤执行器执行所述第一业务的相应步骤的正向处理；

所述步骤执行器，还用于对所述第一业务的相应步骤执行正向处理，所述正向处理包括：对所述步骤执行正向处理动作并获取所述步骤的执行状态；在所述步骤的执行状态为未知或执行中时，周期性地调用状态查询动作查询所述步骤的执行状态。

9.根据权利要求8所述的多方协同业务处理系统，其特征在于，所述调度控制器，还用于在所述步骤执行器提供的步骤的执行状态为成功时，控制下一步骤的步骤执行器对所述第一业务的下一步骤执行正向处理；在所述步骤执行器提供的步骤的执行状态为失败时，控制所述第一业务的已执行步骤的步骤执行器反向撤销所述第一业务的已执行步骤。

10.根据权利要求6或9所述的多方协同业务处理系统，其特征在于，

所述调度控制器，用于控制所述第一业务的已执行步骤的步骤执行器反向撤销所述第一业务的已执行步骤，包括：逆向依次控制所述第一业务的已执行正向处理的每个步骤的步骤执行器对所述第一业务的相应步骤执行撤销动作。

Images