CN110399429A - 一种分布式事务处理方法和系统 - Google Patents

Abstract

本说明书一个或多个实施例公开了一种分布式事务处理方法。所述方法包括，在分布式事务一阶段中，建立事务中间表，将所述事务在一阶段得到的最终业务状态数据存储至所述事务中间表中，所述最终业务状态数据为所述事务的执行结果；在分布式事务二阶段中执行以下操作：当事务回滚时，删除所述事务中间表中的所述最终业务状态数据；当事务提交时，使用所述事务中间表中的所述最终业务状态数据覆盖真实的业务状态数据；所述真实的业务状态数据包括基于事务操作完成后的业务流水数据进行合并修改，得到操作后的所述最终业务状态数据，所述真实的业务状态数据存储在存储器中。

Description

一种分布式事务处理方法和系统

技术领域

本说明书一个或多个实施例涉及计算机处理技术领域，特别涉及一种分布式事务处理方法。

背景技术

分布式事务是一种跨系统的事务处理方法，事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。分布式事务操作过程中，会涉及到流水数据和状态数据，其中，流水数据是业务处理中基于每次业务情况的记录数据，流水数据在生成之后不会更改；状态数据是业务处理中代表一个对象当前状态的数据。

在分布式事务中，传统方案把对于状态数据的修改业务映射成一个个原子操作，并且需要完整记录所有原子操作，操作过程中的所有流水数据都需要存储在数据库中，内容繁杂，数据量大，对服务器的处理能力提出了较高的要求。尤其在高并发情况下，各个事务的处理顺序及处理速度可能会受到一定影响，如多个事务的处理顺序可能发生乱序，进一步导致业务处理的瞬时状态可能不一致等情况。随着互联网的快速发展及业务发展，业务数据快速增长，对应的数据库的种类也日益增多，事务操作越发复杂，传统的事务处理方法已无法满足当前巨大的数据需求。

因此，希望能有一种可靠的改进方法，能够完善事务处理过程、优化数据处理结果。

发明内容

本说明书的一个方面提供一种分布式事务处理方法。所述方法包括，在分布式事务一阶段中，建立事务中间表，将所述事务在一阶段得到的最终业务状态数据存储至所述事务中间表中，所述最终业务状态数据为所述事务的执行结果；在分布式事务二阶段中执行以下操作：当事务回滚时，删除所述事务中间表中的所述最终业务状态数据；当事务提交时，使用所述事务中间表中的所述最终业务状态数据覆盖真实的业务状态数据；所述真实的业务状态数据包括基于事务操作完成后的业务流水数据进行合并修改，得到操作后的所述最终业务状态数据，所述真实的业务状态数据存储在存储器中。

在一些实施例中，所述最终业务状态数据与所述真实的业务状态数据的存储格式相同。

在一些实施例中，所述最终业务状态数据通过以下方式得到：

本地事务操作过程中加载所述真实的业务状态数据，所述真实的业务状态数据基于本次事务操作完成后的业务流水数据进行合并修改，得到本次操作后的所述最终业务状态数据。

在一些实施例中，所述本地事务存在多个时，每个所述本地事务均建立独立的所述事务中间表用于存储各自的所述最终业务状态数据。

在一些实施例中，所述本地事务中存在多个分支事务时，建立所述事务中间表用于存储多个所述分支事务操作后的所述最终业务状态数据。

在一些实施例中，所述事务中间表存储在所述本地事务的数据库中。

在一些实施例中，所述方法还包括：当第二阶段判断为回滚时，删除所述事务中间表。

本说明书的另一方面提供一种分布式事务处理系统。所述系统包括：事务中间表建立单元和执行单元；

所述事务中间表建立单元用于在分布式事务一阶段中，建立事务中间表，将所述事务在一阶段得到的最终业务状态数据存储至所述事务中间表中，所述最终业务状态数据为所述事务的执行结果；

所述执行单元用于在分布式事务二阶段中执行以下操作：当事务回滚时，删除所述事务中间表中的所述最终业务状态数据；当事务提交时，使用所述事务中间表中的所述最终业务状态数据覆盖真实的业务状态数据；所述真实的业务状态数据包括基于事务操作完成后的业务流水数据进行合并修改，得到操作后的所述最终业务状态数据，所述真实的业务状态数据存储在存储器中。

在一些实施例中，所述最终业务状态数据与所述真实的业务状态数据的存储格式相同。

在一些实施例中，所述最终业务状态数据通过以下方式得到：

本地事务操作过程中加载所述真实的业务状态数据，所述真实的业务状态数据基于本次事务操作完成后的业务流水数据进行合并修改，得到本次操作后的所述最终业务状态数据。

在一些实施例中，所述本地事务存在多个时，每个所述本地事务均建立独立的所述事务中间表用于存储各自的所述最终业务状态数据。

在一些实施例中，所述本地事务中存在多个分支事务时，建立所述事务中间表用于存储多个所述分支事务操作后的所述最终业务状态数据。

在一些实施例中，所述事务中间表存储在所述本地事务的数据库中。

在一些实施例中，所述执行单元还执行以下操作：当第二阶段判断为回滚时，删除所述事务中间表。

本说明书的另一方面提供一种分布式事务处理装置。包括至少一个处理器以及至少一个存储器；

所述至少一个存储器用于存储计算机指令；

所述至少一个处理器用于执行所述计算机指令中的至少部分指令以实现如前所述的分布式事务处理方法。

附图说明

本说明书将以示例性实施例的方式进一步说明，这些示例性实施例将通过附图进行详细描述。这些实施例并非限制性的，在这些实施例中，相同的编号表示相同的结构，其中：

图1是根据本说明书一些实施例所示的分布式事务处理方法的示例性流程步骤图；

图2是根据本说明书一些实施例所示的处理方法的示例性流程框图；

图3是根据本说明书一些实施例所示的处理方法存在多个本地事务的示例性流程图；

图4是根据本说明书一些实施例所示的处理方法中本地事务存在多个分支事务的示例性流程图；

图5是根据本说明书的一些实施例所示的示例性分布式事务方法的系统框图。

具体实施方式

为了更清楚地说明本说明书的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本说明书的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本说明书应用于其它类似情景。除非从语言环境中显而易见或另做说明，图中相同标号代表相同结构或操作。

应当理解，本文使用的“系统”、“装置”、“单元”和/或“模组”是用于区分不同级别的不同组件、元件、部件、部分或装配的一种方法。然而，如果其他词语可实现相同的目的，则可通过其他表达来替换所述词语。

如本说明书和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其它的步骤或元素。

本说明书中使用了流程图用来说明根据本说明书的实施例的系统所执行的操作。应当理解的是，前面或后面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各个步骤。同时，也可以将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作。

本实施例说明书的实施例可以应用于多种业务场景，包括但不限于转账处理、计费系统、订单管理、审计、会计、财务、贸易、银行、公安、电商平台、科研单位等。本实施例通过在事务执行过程中建立事务中间表，完整保存一次分布式事务中业务状态数据的最终处理结果，即，最终业务状态数据，并根据事务执行结果，将事务中间表进行删除或保留。应当理解的是，本实施例的系统和方法的应用场景仅仅是本说明书的一些实例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本实施例应用于其他类似情景。虽然本实施例主要以转账、批量代发为例进行了描述，但需要注意的是，本实施例的原理也可应用于其他业务场景，如订单管理、银行汇款、电商服务等。根据本实施例的原理，也可以通过建立事务中间表，完整保存一次事务中业务状态数据的最终处理结果，来处理订单管理事务、银行汇款事务或电商事务等分布式事务。在一些实施例中，常规的分布式事务分为两阶段进行，对业务状态数据的修改需要完整记录原子操作，并针对每个操作进行提交或回滚。在事务一阶段，每个参与者根据事务协调器发送的事务请求，执行完成后向事务协调器返回“成功”或“不成功”的执行结果；在事务二阶段，事务协调器收集所有参与者返回的“成功”或“不成功”的执行结果，并进行进一步的事务处理操作。具体的，基于所有参与者返回“成功”的执行结果，事务协调器发起提交事务的请求，各事务参与者执行提交操作，释放整个事务执行期间占用的资源，并向事务协调器反馈应答完成的信息，完成事务提交；基于参与者中有至少一个返回“不成功”的执行结果，事务协调器向所有参与者发送回滚请求，参与者执行回滚操作，释放整个事务执行期间占用的资源，向事务协调器反馈应答完成的信息，完成事务回滚。

分布式事务遵循“原子性”、“一致性”、“隔离性”、“持久性”四个特性。其中，“原子性”表现为事务操作的整体性，即：一个事务中的所有操作只有两种结果：事务提交和事务回滚。“一致性”表现为事务操作下的数据的正确性，即：保证数据库在事务开始前和事务结束后的一致性约束。“隔离性”表现为保证事务并发操作下的数据的正确性，即：防止多个事务并发执行时由于交叉执行导致数据不一致。具体的，本实施例中存在一个或以上事务，所述一个或以上事务中即为多个并行事务，也称为并发事务。所述并发事务可以处于不同的数据库，并发事务在操作过程中可以对相应的数据进行数据更新操作(如，数据读/写、数据修改等)。“持久性”表现为保证事务对数据修改的可靠性，即：事务处理结束后，对数据的修改是永久的，即使发生断电等系统故障也不会丢失本次事务的处理记录。

图1是根据本说明书一些实施例所示的处理方法的示例性流程步骤图。图2是根据本说明书一些实施例所示的处理方法的示例性流程框图。

如图1、图2所示，一种分布式事务处理方法，所述方法包括，

步骤102，在分布式事务一阶段中，建立事务中间表。

步骤104，将所述事务在一阶段得到的最终业务状态数据存储至所述事务中间表中，所述最终业务状态数据为所述事务的执行结果；

在分布式事务二阶段中执行：

步骤106，当事务回滚时，删除所述事务中间表中的所述最终业务状态数据。

步骤108，当事务提交时，使用所述事务中间表中的所述最终业务状态数据覆盖真实的业务状态数据。

分布式事务操作过程中包括流水数据和状态数据，其中，流水数据是业务处理中基于每次业务情况的记录数据，例如，订单流水、交易流水、帐务流水(入帐/出帐)、会计流水等。各条流水数据之间相互独立，流水数据在生成之后不会更改；状态数据是业务处理中代表一个对象当前的业务状态的数据，如会员信息、客户信息、帐户信息、订单信息等。具体的，如在订单信息中，状态数据可以是“下单”、“付款”、“发货”、“运送”、“收货”、“售后”等多个状态数据。

在步骤102和步骤104中，事务中间表用于存放事务一阶段中的最终业务状态数据，所述最终业务状态数据是所述事务的最终执行结果。在一些实施例中，事务中间表可以与流水记录、事务日志、事务记录表等存储类型相同。事务记录表的存储位置可以是本地存放事务日志、事务记录表的本地数据库，也可以是本地/线上新增的独立数据库或数据库系统。在一些实施例中，最终业务数据可以由流水数据基于当前业务状态更新的数据加载获得，也可以由操作记录等多种方式获得。

在步骤104中，事务一阶段完成后完整记录事务一阶段中所有的业务状态数据，并将最终业务状态数据存储到事务中间表中。

在步骤108中，所述真实的业务状态数据包括基于事务操作完成后的业务流水数据进行合并修改，得到操作后的所述最终业务状态数据。在一些实施例中，所述真实的业务状态数据存储在存储器中。在一些实施例中，所述真实的业务状态数据为业务流水操作中对象发生改变的状态，如会员信息、客户信息、帐户信息、订单信息等。在一些实施例中，账户信息对应的状态数据可以有一个或以上真实的业务状态数据，并基于事务流水的变化而不断更新。在一些实施例中，支付宝账户向余额宝账户转账，二者初始的业务状态数据为“支付宝账户余额2万”、“余额宝账户余额1万”，“支付宝账户余额2万”、“余额宝账户余额1万”即为二者真实的业务状态数据，当支付宝账户向余额宝账户转账1万元并完成后，二者真实的业务状态数据则更新为“支付宝账户余额1万”、“余额宝账户余额2万”。在一些实施例中，支付宝账户真实的业务状态数据为“支付宝账户余额0元人民币”，当支付宝账户收到1万元人民币后，则支付宝账户的真实的业务状态数据更新为“支付宝账户余额1万元人民币”。

在一些实施例中，事务二阶段基于所有参与者返回的事务执行结果执行以下操作：基于各个参与者中至少一个返回“不成功”的执行结果，事务协调器向所有参与者发送回滚请求，所有参与者收到事务回滚信息后，执行步骤106，删除所述事务中间表中的所述最终业务状态数据，释放整个事务过程中占用的资源，中断事务的操作，恢复事务执行前的状态。在一些实施例中，事务二阶段基于各个参与者均返回“成功”的执行结果，事务协调器向所有参与者发出正式的事务提交的请求并执行步骤108，使用事务中间表中的最终业务状态数据覆盖数据库的真实的业务状态数据，覆盖后的数据即为本次事务后最终的业务状态数据，也是新的真实的业务状态数据。

本方案在事务一阶段中将最终业务状态数据储存在在事务中间表中，无需记录每一次业务的所有流水数据，独立于事务业务流水数据和业务操作数据，容错率低，能适应大量数据情况下的数据处理，节约时间和存储资源，且不会因流水数据多而出现乱序造成业务处理的瞬时状态不一致的问题，数据处理更加快速准确。

在一些实施例中，所述最终业务状态数据与所述真实的业务状态数据的存储格式相同。

事务中间表中的最终业务状态数据的存储格式可以有多种形式，包括代码、语句、数字、字符串、表格等或任意组合。最终业务状态数据与真实的业务状态数据存储格式相同，方便应用服务在进行业务处理时，直接对数据模型进行升级，不用考虑升级模型后新的数据操作在分布式事务中不支持的情况。保证事务协调器在执行事务提交时，可以将事务中间表中的最终业务状态数据直接覆盖真实的业务状态数据。

在一些实施例中，所述最终业务状态数据通过以下方式得到：

本地事务操作过程中加载所述真实的业务状态数据，所述真实的业务状态数据基于本次事务操作完成后的业务流水数据进行合并修改，得到本次操作后的所述最终业务状态数据。

在本说明书一个或多个实施例中，事务中真实的业务状态数据基于业务流水数据另外加载，独立于本地数据，并不影响本地事务中真实的业务状态数据。

真实的业务状态数据基于本次事务所有操作的业务流水数据进行合并修改，并生成本次修改后的全量业务状态数据，该全量业务状态数据即为最终业务状态数据。

在一些实施例中，以支付宝转账为例，支付宝账户原有余额三万元人民币，经过一次交易，支付宝账户余额减少一万元人民币，支付宝账户余额剩余两万元人民币。在此实施例中，业务流水数据为“支付宝账户余额减少一万元人民币”，业务状态数据为“支付宝账户余额”。由此，基于业务流水数据加载更新后的业务状态数据，完成了真实的业务状态数据的合并修改，得到“支付宝账户余额为两万元人民币”的最终业务状态数据。

在另一些实施例中，以支付宝转账为例，支付宝账户原有三万元人民币，经过一次交易，支付宝账户余额减少一万元人民币；经过另一次交易，支付宝账户余额增加五千元人民币。对应于两次交易的业务流水数据为“支付宝账户余额减少一万元人民币人民币”、“支付宝账户余额增加五千元人民币”；业务状态数据为“支付宝账户余额”。由此，基于业务流水数据加载两次更新后的业务状态数据，完成了真实的业务状态数据的合并修改，得到“支付宝账户余额为两万五千元人民币”的最终业务状态数据。

图3是根据本说明书一些实施例所示的处理方法存在多个本地事务的示例性流程图。

在一些实施例中，所述本地事务存在多个时，每个所述本地事务均建立独立的所述事务中间表用于存储各自的所述最终业务状态数据。

在一些实施例中，分布式事务常存在多个本地事务并行进行的情况，所述多个本地事务即为并行事务或并发事务，所述并发事务可以处于不同的系统或数据库，并对相应的数据进行数据更新操作(如，数据读/写、数据修改等)。在分布式事务中，每个本地事务在事务一阶段各自记录对应的最终业务状态数据并分别保存在各自单独的事务中间表中，各个事务的事务中间表均互相独立且互不影响。

例如，在支付宝向余额宝转账的实施例中，“支付宝扣钱”和“余额宝加钱”属于两个并发事务，所述并发事务分别处于两个不同的系统或数据库，并由各自的系统或数据库负责管理。在支付宝向余额宝转账1万元人民币的具体事务中，支付宝账户余额减少1万元人民币，余额宝账户余额增加1万元人民币，所述两个并发事务通过更新(如，数据读/写、数据修改等)各自的系统或数据库中相应的数据来执行事务。所述两个本地事务各自建立事务中间表(如，事务中间表1、事务中间表2，或其他形式)用于存储最终业务状态数据，两个事务的事务中间表均相互独立且互不影响。

在另一些实施例中，例如，在订单信息中，“买家下单”、“卖家发货”、“物流运送”等属于三个并发事务，所述并发事务处于不同的系统或数据库，分别由各自的系统或数据库负责管理。所述并发事务通过更新(如，数据读/写、数据修改等)各自的系统或数据库中相应的数据来执行事务。所述三个本地事务各自建立事务中间表(如，事务中间表1、事务中间表2、事务中间表3，或其他形式)用于存储最终业务状态数据，三个事务的事务中间表均相互独立且互不影响。

传统的事务操作方法需要分别定义所述业务的每一次操作及记录对应的初始状态和变更状态。在本说明书的方案中，事务中间表通过记录事务中所有对象的最终业务状态数据，将原子操作数据处理变成业务状态数据处理，可以较好地解决由业务状态变更、操作种类繁多、数据量大带来的衍生问题，可以更好专注于业务型的操作。并发事务通过建立各自的事务中间表来记录各自的最终业务状态数据，并基于事务隔离性，可以防止多个事务并发执行时由于交叉访问数据资源导致数据修改不一致或乱序执行的操作。

图4是根据本说明书一些实施例所示的处理方法中本地事务存在多个分支事务的示例性流程图。

在一些实施例中，所述本地事务中存在多个分支事务时，仅建立一个所述事务中间表用于存储多个所述分支事务操作后的所述最终业务状态数据。

本实施例的本地事务中可能存在一个或以上分支事务。所述分支事务，即从属于本地事务的多个分支操作。分支事务操作的最终业务状态数据可以保存在一个事务中间表中。在事务操作过程中，所述分支事务的状态数据均会发生变更或更新。传统的事务操作方法需要分别定义分支事务的每一次操作并记录对应的初始状态和状态变更。

在一些实施例中，例如，公司向100位员工批量代发工资。在此实施例中，公司向员工批量代发工资为本地事务，向100位员工代发工资即为本地事务中的100个分支事务。传统的方法需要在事务一阶段中对100次转账业务的流水数据进行记录，并对100次转账业务的状态数据进行记录，在事务二阶段对公司账户及员工账户的每一个及每一种账户的真实业务状态数据的更新进行记录。例如，在事务二阶段对公司账户进行100次扣钱的流水操作并记录，对员工账户进行100次加钱的流水操作并记录、对公司账户每一次转账后的账户余额进行记录；并在事务二阶段中对业务执行后公司和员工的账户余额的更新数据进行记录。

在本方案的分布式事务操作中，基于批量代发业务中多个分支事务的每一次流水操作，将每一次流水操作对应的最终业务状态数据，即公司账户在多个分支事务操作完成后的最终余额记录在一份事务中间表中，并基于事务二阶段中事务提交或回滚的处理结果而删除或保留事务中间表。在事务二阶段中，基于多次批量代发业务全部返回“成功”的执行结果，该事务的事务协调器处理事务提交操作，向多位员工批量代发工作；基于多次批量代发业务中至少一个返回“不成功”的执行结果，事务协调器处理事务回滚操作，批量代发事务中断，恢复到事务初始状态。将分支事务的最终状态数据记录在事务中间表中，可以将针对复杂的原子操作记录的处理方式变成针对简单的业务状态数据的处理方式，节省了数据库资源，数据处理更加快速准确，降低了数据操作的复杂度。

在一些实施例中，所述事务中间表存储在所述本地事务的数据库中。

存储事务中间表的本地事务数据库可以是用于存放本地事务日志、业务流水数据、业务状态数据等的数据库；也可以是单独的数据库。

数据库的存储格式需要尽量与上述数据库的存储格式相同，例如，与业务状态数据的数据库存储格式相同，方便应用服务在进行业务处理时，直接对数据模型进行升级，不用考虑升级模型后新的数据操作在分布式事务中不支持的情况。保证事务协调器在执行事务提交时，可以将事务中间表中的最终业务状态数据直接覆盖真实的业务状态数据。

在一些实施例中，所述分布式事务处理方法还包括：当第二阶段判断为回滚时，删除所述事务中间表。

在一些实施例中，分布式事务完成后，采用直接删除事务中间表的方式来删除事务最终状态数据，在下一次事务执行开始时，重新建立新的事务中间表即可。在一些实施例中，基于每个参与者中至少一个返回“不成功”的执行结果，事务协调器向所有参与者发送回滚请求，所有参与者收到回滚请求后，执行回滚操作，删除所述事务中间表，释放整个事务过程中占用的资源，中断事务的操作，恢复事务执行前的状态。

在一些实施例中，本说明书的分布式事务处理方法可以基于通用的分布式事务框架、支付宝XTS(eXtended Transaction Service)事务框架执行。支付宝XTS事务框架是支付宝广泛使用的分布式事务技术框架，用于保证在账务、资金等操作的事务一致性。

图5是根据本说明书一些实施例所示的分布式事务处理系统的示例性流程图。

基于以上分布式事务处理方法，本实施例还公开了一种分布式事务处理系统，所述系统包括：事务中间表建立单元502和执行单元504；

所述事务中间表建立单元502用于在分布式事务一阶段中，建立事务中间表，将所述事务在一阶段得到的最终业务状态数据存储至所述事务中间表中，所述最终业务状态数据为所述事务的执行结果；

所述执行单元504用于在分布式事务二阶段中执行以下操作：

删除所述事务中间表中的所述最终业务状态数据；

或使用所述事务中间表中的所述最终业务状态数据覆盖真实的业务状态数据。

在一些实施例中，事务中间表建立单元502在事务一阶段中建立事务中间表，并将事务一阶段中的最终业务状态数据保存在事务中间表中。所述事务中间表单元502可以用于建立事务一阶段中的事务中间表，并用于存储事务最终的业务状态数据。

在一些实施例中，所述执行单元504可以用于在事务二阶段中处理事务提交或回滚的相关操作，并基于事务的提交或回滚的处理结果而删除或保留事务中间表。

在一些实施例中，所述执行单元504基于事务一阶段中事务参与者返回的“成功”或“不成功”的执行结果确定事务处理结果。

在一些实施例中，所述执行单元504基于各个参与者中至少一个返回“不成功”的执行结果，执行：删除所述事务中间表中的最终业务状态数据，恢复事务执行前的状态。

在一些实施例中，所述执行单元504基于各个参与者全部返回“成功”的执行结果，执行：使用所述事务中间表中的最终业务状态数据覆盖本地数据库真实的业务状态数据。覆盖后的数据即为本次事务后最终的业务状态数据。

在一些实施例中，事务中间表建立单元502还可用于在事务二阶段回滚删除事务中间表后，在下次新事务执行时新建事务中间表。

在一些实施例中，执行单元504还可以用于在事务执行完成后删除事务中间表。

本实施例的分布式事务处理系统可以应用于多种业务场景，包括但不限于转账处理、计费系统、订单管理、审计、会计、财务、贸易、银行、公安、电商平台、科研单位等。

在系统的一些实施例中，所述最终业务状态数据与所述真实的业务状态数据的存储格式相同。

在系统的一些实施例中，所述最终业务状态数据通过以下方式得到：

本地事务操作过程中加载所述真实的业务状态数据，所述真实的业务状态数据基于本次事务操作完成后的业务流水数据进行合并修改，得到本次操作后的所述最终业务状态数据。

在系统的一些实施例中，所述本地事务存在多个时，每个所述本地事务均建立独立的所述事务中间表用于存储各自的所述最终业务状态数据。

在系统的一些实施例中，所述本地事务中存在多个分支事务时，建立所述事务中间表用于存储多个所述分支事务操作后的所述最终业务状态数据。

在系统的一些实施例中，所述事务中间表存储在所述本地事务的数据库中。

在系统的一些实施例中，所述执行单元还执行以下操作：当第二阶段判断为回滚时，删除所述事务中间表。

基于以上分布式事务处理方法，本实施例还提供了一种分布式事务处理装置，所述装置包括至少一个处理器以及至少一个存储器；

所述至少一个存储器用于存储计算机指令；

所述至少一个处理器用于执行所述计算机指令中的至少部分指令以实现上述任一实施例所述的分布式事务处理方法。

分布式事务装置可以用于处理分布式事务执行过程的计算机指令。具体的，分布式事务装置可以存储计算机指令并执行分布式事务操作。

本实施例的分布式事务处理装置可以应用于多种业务场景，包括但不限于转账处理、计费系统、订单管理、审计、会计、财务、贸易、银行、公安、电商平台、科研单位等。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统和装置实施例而言，由于其基本相似于方法实施例或基于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书实施例可能带来的有益效果包括但不限于：(1)本方案在事务一阶段中将最终业务状态数据储存在事务中间表中，可以无需记录每一次业务的所有流水数据，独立于事务业务流水数据和业务操作数据，可以单独运行计算，不影响业务流水数据和业务操作数据的正常运行，在实际操作时容错率低，能适应多个并发情况的事务处理，节约时间和存储资源；(2)将针对复杂的原子操作记录的处理方式变成针对简单的业务状态数据的处理方式，不会出现因流水数据多而出现的乱序操作、业务处理的瞬时状态不一致等问题，数据处理更加快速准确；(3)事务中间表的存储格式与事务状态数据的存储格式相同，可以在配置和模型升级过程中直接操作，不会因数据格式不支持而影响升级，实用性强。

需要说明的是，不同实施例可能产生的有益效果不同，在不同的实施例里，可能产生的有益效果可以是以上任意一种或几种的组合，也可以是其他任何可能获得的有益效果。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

上文已对基本概念做了描述，显然，对于本领域技术人员来说，上述详细披露仅仅作为示例，而并不构成对本说明书的限定。虽然此处并没有明确说明，本领域技术人员可能会对本说明书进行各种修改、改进和修正。该类修改、改进和修正在本说明书中被建议，所以该类修改、改进、修正仍属于本说明书示范实施例的精神和范围。

同时，本说明书使用了特定词语来描述本说明书的实施例。如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本说明书至少一个实施例相关的某一特征、结构或特点。因此，应强调并注意的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一个替代性实施例”并不一定是指同一实施例。此外，本说明书的一个或多个实施例中的某些特征、结构或特点可以进行适当的组合。

此外，本领域技术人员可以理解，本说明书的各方面可以通过若干具有可专利性的种类或情况进行说明和描述，包括任何新的和有用的工序、机器、产品或物质的组合，或对他们的任何新的和有用的改进。相应地，本说明书的各个方面可以完全由硬件执行、可以完全由软件(包括固件、常驻软件、微码等)执行、也可以由硬件和软件组合执行。以上硬件或软件均可被称为“数据块”、“模块”、“引擎”、“单元”、“组件”或“系统”。此外，本说明书的各方面可能表现为位于一个或多个计算机可读介质中的计算机产品，该产品包括计算机可读程序编码。

计算机存储介质可能包含一个内含有计算机程序编码的传播数据信号，例如在基带上或作为载波的一部分。该传播信号可能有多种表现形式，包括电磁形式、光形式等，或合适的组合形式。计算机存储介质可以是除计算机可读存储介质之外的任何计算机可读介质，该介质可以通过连接至一个指令执行系统、装置或设备以实现通讯、传播或传输供使用的程序。位于计算机存储介质上的程序编码可以通过任何合适的介质进行传播，包括无线电、电缆、光纤电缆、RF、或类似介质，或任何上述介质的组合。

本说明书各部分操作所需的计算机程序编码可以用任意一种或多种程序语言编写，包括面向对象编程语言如Java、Scala、Smalltalk、Eiffel、JADE、Emerald、C++、C#、VB.NET、Python等，常规程序化编程语言如C语言、VisualBasic、Fortran2003、Perl、COBOL2002、PHP、ABAP，动态编程语言如Python、Ruby和Groovy，或其他编程语言等。该程序编码可以完全在用户计算机上运行、或作为独立的软件包在用户计算机上运行、或部分在用户计算机上运行部分在远程计算机运行、或完全在远程计算机或处理设备上运行。在后种情况下，远程计算机可以通过任何网络形式与用户计算机连接，比如局域网(LAN)或广域网(WAN)，或连接至外部计算机(例如通过因特网)，或在云计算环境中，或作为服务使用如软件即服务(SaaS)。

此外，除非权利要求中明确说明，本说明书所述处理元素和序列的顺序、数字字母的使用、或其他名称的使用，并非用于限定本说明书流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的说明书实施例，但应当理解的是，该类细节仅起到说明的目的，附加的权利要求并不仅限于披露的实施例，相反，权利要求旨在覆盖所有符合本说明书实施例实质和范围的修正和等价组合。例如，虽然以上所描述的系统组件可以通过硬件设备实现，但是也可以只通过软件的解决方案得以实现，如在现有的处理设备或移动设备上安装所描述的系统。

同理，应当注意的是，为了简化本说明书披露的表述，从而帮助对一个或多个说明书实施例的理解，前文对本说明书实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。但是，这种披露方法并不意味着本说明书对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

最后，应当理解的是，本说明书中所述实施例仅用以说明本说明书实施例的原则。其他的变形也可能属于本说明书的范围。因此，作为示例而非限制，本说明书实施例的替代配置可视为与本说明书的教导一致。相应地，本说明书的实施例不仅限于本说明书明确介绍和描述的实施例。

Claims (15)

1.一种分布式事务处理方法，其特征在于，所述方法包括，

在分布式事务一阶段中，建立事务中间表，将所述分布式事务在一阶段得到的最终业务状态数据存储至所述事务中间表中，所述最终业务状态数据为所述事务的执行结果；

在分布式事务二阶段中执行以下操作：

当事务回滚时，删除所述事务中间表中的所述最终业务状态数据；

当事务提交时，使用所述事务中间表中的所述最终业务状态数据覆盖真实的业务状态数据；

所述真实的业务状态数据包括基于事务操作完成后的业务流水数据进行合并修改，得到操作后的所述最终业务状态数据，所述真实的业务状态数据存储在存储器中。

2.根据权利要求1所述的方法，其特征在于，所述最终业务状态数据与所述真实的业务状态数据的存储格式相同。

3.根据权利要求1所述的方法，其特征在于，所述最终业务状态数据通过以下方式得到：

本地事务操作过程中加载所述真实的业务状态数据，所述真实的业务状态数据基于本次事务操作完成后的业务流水数据进行合并修改，得到本次操作后的所述最终业务状态数据。

4.根据权利要求3所述的方法，其特征在于，所述本地事务存在多个时，每个所述本地事务均建立独立的所述事务中间表用于存储各自的所述最终业务状态数据。

5.根据权利要求4所述的方法，其特征在于，所述本地事务中存在多个分支事务时，建立所述事务中间表用于存储多个所述分支事务操作后的所述最终业务状态数据。

6.根据权利要求3所述的方法，其特征在于，所述事务中间表存储在所述本地事务的数据库中。

7.根据权利要求1所述的方法，其特征在于，所述方法还包括：当第二阶段判断为回滚时，删除所述事务中间表。

8.一种分布式事务处理系统，其特征在于，所述系统包括：事务中间表建立单元和执行单元；

所述事务中间表建立单元用于在分布式事务一阶段中，建立事务中间表，将所述分布式事务在一阶段得到的最终业务状态数据存储至所述事务中间表中，所述最终业务状态数据为所述事务的执行结果；

所述执行单元用于在分布式事务二阶段中执行以下操作：

当事务回滚时，删除所述事务中间表中的所述最终业务状态数据；

当事务提交时，使用所述事务中间表中的所述最终业务状态数据覆盖真实的业务状态数据；所述真实的业务状态数据包括基于事务操作完成后的业务流水数据进行合并修改，得到操作后的所述最终业务状态数据，所述真实的业务状态数据存储在存储器中。

9.根据权利要求8所述的系统，其特征在于，所述最终业务状态数据与所述真实的业务状态数据的存储格式相同。

10.根据权利要求8所述的系统，其特征在于，所述最终业务状态数据通过以下方式得到：

本地事务操作过程中加载所述真实的业务状态数据，所述真实的业务状态数据基于本次事务操作完成后的业务流水数据进行合并修改，得到本次操作后的所述最终业务状态数据。

11.根据权利要求10所述的系统，其特征在于，所述本地事务存在多个时，每个所述本地事务均建立独立的所述事务中间表用于存储各自的所述最终业务状态数据。

12.根据权利要求11所述的系统，其特征在于，所述本地事务中存在多个分支事务时，建立所述事务中间表用于存储多个所述分支事务操作后的所述最终业务状态数据。

13.根据权利要求10所述的系统，其特征在于，所述事务中间表存储在所述本地事务的数据库中。

14.根据权利要求8所述的系统，其特征在于，所述执行单元还用于执行以下操作：当第二阶段判断为回滚时，删除所述事务中间表。

15.一种分布式事务处理装置，其特征在于，所述装置包括至少一个处理器以及至少一个存储器；

所述至少一个存储器用于存储计算机指令；

所述至少一个处理器用于执行所述计算机指令中的至少部分指令以实现如权利要求1～7中任一项所述的方法。