CN1199897A - 保证交易一致性的方法 - Google Patents

Abstract

在联机事物处理系统中通过核对和重复提交/撤销来保证数据处理一致性的方法。导致各电脑处理结果不一致的主要原因是网络短时故障引起传输数据丢失,或系统运行短时故障导致结果处理失败,执行一次出现故障的概率是确定的,但是只要重复执行失败的操作就可以使总体失败概率减低至可接受的程度。本发明在保证系统处理结果可靠性、确保系统运行效率和使用方便性方面具有很强的实用性。

Description

保证交易一致性的方法

本发明涉及到在银行、证券和电信等联机事物处理系统中保证数据处理的一致性的方法，特别是涉及到一种在网络和主机系统可能出现故障的情况下通过核对和重复提交/撤销来保证数据处理一致性的方法。

以A、B、C三台电脑为例，它们之间通过网络连接起来，构成一个具有分布式处理能力的计算机网络系统。在这个系统中有一笔业务需要由这三台电脑合作处理，这笔业务的成功是指在每台电脑上处理均成功，业务的失败是指在每台电脑上处理均失败。也就是保证所有处理成功均成功，失败均失败的原则，即保证交易的一致性。由于有网络传输故障和电脑处理故障的可能性存在，会使得一笔业务的处理在有的电脑上成功，在有的电脑上失败。如何保证这笔业务满足前面定义的成功/失败原则，保证交易的一致性是一个重要的问题。解决这一问题的难点在于：1.电脑系统处理的不可靠性

电脑系统由硬件、操作系统、数据库系统、中间件系统、应用处理系统和大量数据组成，由于这些系统本身的复杂性，不可能保证每次处理结果均为成功，其处理失败的可能性是一个必然存在。2.网络传输的不可靠性

一笔业务要由若干(例如三台)电脑协同处理完成，必须依靠网络传输系统把这笔业务的一部分，从一台电脑传送到其它的电脑上去处理，并且每台电脑必须依据其它电脑处理的结果是成功还是失败以决定其自身的处理结果，这样才能保证成功均成功，失败均失败的一致性原则。但不幸的是，在网络故障存在的情况下，从理论上无法保证三台电脑对该业务处理的结果一致。例如，在一个网络系统中，如果电脑A通过网络与电脑B联接，要实现A与B的同步变化，由于网络传输故障的存在，不管A、B之间如何相互发送确认信息，A、B两点的状态都无法保证100％的一致。

综上所述，由于电脑系统处理故障和网络传输故障的存在，在任何情况下均要100％保证一笔业务在A、B、C三台电脑上处理全部成功或全部失败的一致性是无法作到的。解决问题的传统方法及缺陷：1.允许电脑处理结果的不一致性，通过后期手工方式解决不一致性。结果一段时间内数据不一致，可能给银行或其它业务部门带来损失。2.增加握手次数，试图达到保证A、B、C三台电脑的处理结果一致性。结果降低了系统的处理效率，但并未从根本上解决问题。3.两阶段提交协议(2PC)

两阶段提交协议是针对提交分布式事务的握手协议。这种协议把参加提交的各个节点分为一个提交协调者(Coordinator)和多个提交参与者(Participant)，每个提交参与者有三种状态。

非提交状态：此时未对提交或终止提交表决；

中间状态：已经表决但不知道表决结果；

决定状态：已知道提交或终止提交的决定。

在一个分布式事务的提交过程中，协调者和参与者各经过以下两个阶段。

协调者阶段一：

协调者获得参加交易的所有节点清单；

协调者在自己的日志文件中写一个记录，此记录包含节点清单；

协调者给所有参与者发一个“准备提交”消息；

协调者等待各参与者的响应消息，此消息是表示每个参与者能

否提交的表决消息；

若超时时间到但协调者并未收到全部参与者的响应，协调者就

在日志中登记提交终止记录，并给所有提交参与者发送终止提

交消息。

协调者阶段二：

如果一个或多个协调者表决为“不”，协调者在日志中登记提

交终止记录，并给所有交易参与者发送终止提交信息；

如果所有的表决为““是””(包括协调者自己)，协调者在日

志中登记提交记录，并给所有提交参与者发送提交消息；

协调者等待参与者发回的确认消息；

当所有参与者应答后，协调者在日志中登记事务完成信息，表

明此事务提交完成。

参与者阶段一：

等待协调者发来的“准备提交”的消息；

若收到“准备提交”前已超时，或事务已经失败，则本节点在日

志中登记终止记录；

为了回答“准备提交”消息，每个节点把事务的日志记录写在

磁盘上，以便为回答““是””或““否”做准备；

如果本节点表决为““是””，那么它在日志中登记““提交临

近””记录，并向提交协调者发““是””消息；

如果本节点表决为““否””，那么它在日志中登记““终止提

交””记录，并向提交协调者发““否””消息。

参与者阶段二：

处于““提交临近””状态的节点等待提交协调者根据各参与者

的表决结果决定提交或终止提交的消息；

若在收到协调者的表决结果前已超时，就启动一个终止协议；

若收到了决定提交的消息，则登记提交记录，更改数据，登记

完成提交记录，打开锁，释放资源，向协调者发确认信息。

即使是在两阶段实现的方案中，对于协调者表决结果超时的处

理，仍有可能造成参与者的状态不一致。

本发明针对前面提到的问题，提出了一种比较实用的解决方法。总体原则是，承认要保证一笔业务在三台电脑上的处理结果一致性是不可能100％实现的，但可以通过一整套办法减少三台电脑出现处理结果不一致情形的概率，当不一致的概率低于业务系统本身对系统不可靠性的要求时，便认为这个解决方案在保证三台电脑上处理结果不一致性的问题得到了解决。基本设计思想为：导致各电脑处理结果不一致的主要原因为网络短时故障引起传输数据丢失，或系统运行短时故障导致结果处理失败，执行一次出现故障的概率是确定的，则重复执行失败的操作就可以使总体失败概率减低至可接受的程度。本发明的实现首先是基于以下的条件：A.电脑系统处理过程(即应用系统的运行过程)的故障是可以自动恢复的，即当前处理失败后，在以后处理时会成功。B.电脑系统本身的故障是可以自动恢复的，即电脑通过重新启动或其它方式可以继续运行。C.网络故障是短时间的，能自动恢复，即网络故障在工作时间内会自动消除，此类故障主要指通讯线路受外界干扰或通讯系统忙导致在某一段时间内传输数据失败，不包括因某种原因导致线路完全断掉的情况。D.处理结果以某一台电脑为准，如在事例中处理结果以电脑A为准。

基于上述条件，本发明在一个通过网络连接起来的具有分布式处理能力的计算机网络系统中提供了一种用核对和重复提交/撤销来保证交易一致性的方法，该方法包括以下步骤：

1.请求方电脑A将交易请求发往各服务电脑；

2.各服务电脑收到交易请求后进行服务处理，并记录处理结果；

3.各服务电脑将交易的处理结果返回给电脑A；

4.电脑A汇总各电脑的交易处理结果，若均处理成功则认为该业务处理成功，若有一电脑处理失败则认为业务处理失败，并且记录该交易最终处理结果；

5.电脑A将交易的最终处理结果通知各服务电脑；

6.各服务电脑等待接收交易的最终处理结果；

7.各服务电脑在限定时间T1内未收到交易的最终处理结果(可能是由于电脑A的系统故障或网络通讯故障)，则判断是否超过了一个预定的门限值；

8.如果未超过上述门限值，则转到步6，向电脑A核对该业务处理结果；

9.若是超过了门限值，就表示不能核对到结果；

10.在各服务电脑上显示步9中的核对失败结果；

11.各服务电脑接收业务的最终汇总结果，并且根据交易结果的成功/失败来执行提交/撤销过程处理。

步骤7-10用于解决电脑系统A或网络传输的可恢复故障。思想是一次传输失败无法获取交易结果的概率为n％，则通过N次进行核对还无法获取交易结果的概率为n％的N次方，就能小于系统设计目标。

本发明的方法还包括进一步的步骤：

12.如果步11中判断的交易结果为成功，就进行提交过程处理；

13.若交易结果为失败，进行撤销过程处理；

14.判断提交过程是否成功，若成功或提交过程被取消则结束交易，否则重复进行提交过程直到完成；以及

15.判断撤销过程是否成功，若成功或撤销过程被取消则结束交易，否则重复进行撤销过程直到完成。

步骤14和15用于解决各服务电脑系统的可恢复故障。思想是一次提交/撤消处理过程失败的概率为s％，则通过S次提交/撤消处理过程还无法成功的概率为s％的S次方，就能小于系统设计目标。

本发明通过交易结果核对和提交/撤消过程重做来保证交易的一致性，在保证系统处理结果可靠性、确保系统运行效率和使用方便性方面具有很强的实用性。

以下要结合附图对本发明的实施例作出进一步的详细说明，在附图中：

图1是系统的结构示意图；

图2表示一台电脑的交易处理过程；

图3表示在请求方电脑直接与各个服务电脑通信的情况下处理一笔交易的过程；

图4表示请求方电脑通过间接转发与各个服务电脑通信的情况下处理一笔交易的过程；以及

图5是整个交易过程的流程图。

图1表示了本发明所采用的系统结构。各电脑上由中间件系统、资源管理系统和应用程序构成完整的应用系统，各电脑间通过网络连接，在所有电脑中一台作为请求方，其它作为服务方。各台电脑之间的连接可以是网状结构、树状结构或其它结构，这是本领域的技术人员所公知的。

各服务电脑上将处理过程分为请求处理过程和提交/撤销处理过程两个阶段，如图2所示。

一笔交易的完整过程为一台电脑(例如A)发起请求，其它电脑进行服务并返回应答给请求电脑，最后请求电脑通知各服务电脑处理结果，共三个阶段，如图3所示。数据的传递可以是请求电脑直接与各服务电脑通讯，例如图3的情况，也可以通过某些电脑间接转发，例如图4的情况。

图5是整个交易过程的流程图。在解释整个交易过程之前首先需要对本发明中的几个基本概念加以说明：请求处理过程：是具体的业务逻辑处理以决定该业务是否能完成，

          若能完成则进行逻辑处理，处理结果记录在缓存区

          中。提交处理过程：使在缓存区中记录的处理结果变成实际有效。撤消处理过程：取消在缓存区中记录的处理结果核对过程：各电脑通过网络查询某一业务的处理结果，可以直接向

      电脑A查询，也可以向其它电脑查询。重复过程：提交/撤消过程的再一次进行。

如图5所示，首先由请求方电脑A在步1中将交易请求发往各服务电脑。各服务电脑(B，C等等)在步2中接收交易请求后进行服务处理，并记录处理结果。各服务电脑在步3将交易的处理结果返回给请求方电脑A。请求方电脑A在步4中汇总各电脑的交易处理结果，若均处理成功则认为该业务处理成功，若有一电脑处理失败则认为业务处理失败，并且记录该交易最终处理结果。接着，请求方电脑A在步5中将交易的最终处理结果通知各服务电脑。各服务电脑在步6中等待接收交易的最终处理结果，并且判断该项业务处理是成功还是失败，如果在规定的时间T1内成功就执行判断交易结果成功/失败的步骤11；反之，若是在时间T1内未收到交易的最终处理结果(可能是由于电脑A的系统故障或网络通讯故障)，就判定业务处理失败，并且转向步骤7，测试是否超过了一个门限值，这种门限值可以是一个预定的时间T2，或者是通过一个计数器获得的规定的核对次数N。如果未超过上述门限值，就通过步骤8转到步骤6，再次向电脑A核对该业务处理结果。若是在步骤7中超过了门限值，就表示不能核对到结果，在服务电脑上登记核对失败。然后在步骤10中在各服务电脑上显示步骤9的核对失败结果。

上述过程中的时间T1表示等待请求方最终结果或等待核对结果的时间，时间T2表示最多可等待交易结果的时间，并且T2＞T1。

另一方面，如果在步骤6中判定业务处理是成功的，各服务电脑接收业务的最终汇总结果，并在步骤11中判断交易的结果。若交易结果为成功，由步骤12进行提交过程处理。如果交易结果为失败，就在步骤13进行撤销过程处理。步骤14用于判断步骤12的提交过程是否成功，若成功或提交过程被取消则结束交易，否则重复进行提交过程直到完成。步骤15用于判断步骤13的撤销过程是否成功，若成功或撤销过程被取消则结束交易，否则重复进行撤销过程直到完成。

上述的步骤7-10用于解决电脑系统A或网络传输的可恢复故障。思想是一次传输失败无法获取交易结果的概率为n％，则通过N次进行核对还无法获取交易结果的概率为n％的N次方，就能小于系统设计目标。步骤14和15用于解决各服务电脑系统的可恢复故障。思想是一次提交/撤消处理过程失败的概率为s％，则通过S次提交/撤消处理过程还无法成功的概率为s％的S次方，就能小于系统设计目标。

实施例一(本地交易)

下面参照图5以两台电脑合作完成一笔取款业务为例来说明本发明的一个最简单的实施例。一台电脑放在储蓄所作客户机(A)，它发起取款请求(步骤1)，S帐户需要取款1000元；一台作为服务器(B)，它接收从A机发来的请求作记帐处理(步骤2)，S帐户的余额为6000元。现将S帐户的余额减掉1000元，并将处理结果返回A机(步骤3)，通知储蓄柜台营业员可以给客户1000元，B机将S帐户的余额5000元记录在缓冲区中。A机接收到B机的处理结果(步骤4)，客户取走1000元(或是不取了，该笔交易作废)，这样A机再将最终交易处理结果(客户取走了钱或是不取了)发送到B机(步骤5)。B机根据该结果提交或是撤销(即该笔交易作废)交易处理过程(步骤11)。如果交易提交则帐户的余额5000元被写入到磁盘上，否则其余额仍是6000元，假设在此期间不出现任何故障，则交易顺利完成，交易结果在A机和B机保持一致(步骤12-16)，也就是说客户实际存款与银行户头上的记录是一致的。实施例二(异地转帐交易)

以下参照图4以三台电脑合作完成一笔转帐业务为例来说明本发明的另一实施例。一台电脑放在储蓄所作客户机(A)，它发起转帐请求(1.请求)，从本地服务器B机的S帐户上转1000元到异地服务器C机的P帐户；(B)机接收从A机发来的请求作记帐处理，将S帐户上记录的余额6000元减去1000元，现有余额是5000元，将S帐户的记录暂存在缓冲区内。B机将重组交易请求，发往C机(2.请求)，在P帐户上增加1000元，假设其原有余额是10000元，则现在余额为11000元，P帐户的记录也暂存在缓冲区中。C机将P帐户的处理结果(应答信息)返回B机(3.应答)，B机又将S帐户的处理结果(应答信息)返回A机(4.应答)，由A机决定是否确认转出这笔账。一旦A机确认转帐，A机就将提交信息发送给B机(5.提交)，B机将提交信息发送给C机(6.提交)，这样，P帐户的余额被永久地变为11000元，S帐户的余额永久地变为5000元；反之，如果A机又不想转这笔账了，它就向B机发送撤销信息(5.撤销)，B机接收到撤销信息后也向C机发送撤销信息(6.撤销)，使S和P帐户的余额均保持不变。假设在此期间不出现任何故障，则交易顺利完成，交易结果在A、B、C机上保持一致(步骤12-16)，也就是说客户实际存款与银行户头上的记录是一致的。

但是，如果在图4中的第3、4、5、6步中的任何一步中出现网络或是应用系统故障，C机就不能知道最终处理结果，此时C机需向B机核对结果，如果有必要，B机还要向A机核对结果。如果B机没有收到应答信息，A机当然也不会收到B机发送来的应答信息，B机和C机也收不到相应的确认信息，在这种情况下，B机和C机就撤销该笔交易，S帐户和P帐户的余额不变。如果A、B机都收到了应答信息，但是B机没有收到A机发送回来的交易最终结果信息(提交或是撤销)，或者是B机已收到A机发送的交易最终结果信息，唯独C机没有收到B机发送的交易最终结果信息，C机就根据核对到的结果执行相应的提交或是撤销。这样就能使交易结果在三台电脑上保持一致。

如果核对不到交易结果(如网络不通等等原因)，就在服务电脑上显示核对失败结果，在这种情况下通常需要人工干预，以保证其一致性，但是这种情况不属于本发明所要解决的问题。

本发明用三台电脑上的交易处理过程作为实例，这已经足以说明问题，实际可用于超过任意台数电脑的系统。

Claims (6)

1.在一个通过网络连接起来的具有分布式处理能力的计算机网络系统中，各电脑上由中间件系统、资源管理系统和应用程序构成完整的应用系统，一种保证交易一致性的方法包括以下步骤：

a)请求方电脑(A)将交易请求发往各服务电脑；

b)各服务电脑收到交易请求后进行服务处理，并记录处理结果；

c)各服务电脑将交易的处理结果返回给电脑(A)；

d)电脑(A)汇总各电脑的交易处理结果，若均处理成功则认为该业务处理成功，若有一电脑处理失败则认为业务处理失败，并且

记录该交易最终处理结果；

e)电脑(A)将交易的最终处理结果通知各服务电脑；

其特征是：

f)各服务电脑等待接收交易的最终处理结果；

g)各服务电脑在限定时间(T1)内未收到交易的最终处理结果，则判断是否超过了一个预定的门限值；

h)如果未超过上述门限值，则转到步f)，向电脑(A)核对该业务处理结果；

i)若是超过了上述门限值，就表示不能核对到结果；

j)在各服务电脑上显示步i)中的核对失败结果；

k)各服务电脑接收业务的最终汇总结果，并且根据交易结果的成功/失败来执行提交/撤销过程处理。

2.如权利要求1所述的方法，其特征是还包括以下步骤：

l)如果步k)中判断的交易结果为成功，就进行提交过程处理；

m)若交易结果为失败，进行撤销过程处理；

n)判断提交过程是否成功，若成功或提交过程被取消则结束交易，否则重复进行提交过程直到完成；以及

o)判断撤销过程是否成功，若成功或撤销过程被取消则结束交易，否则重复进行撤销过程直到完成。

3.如权利要求1所述的方法，其特征是上述限定时间(T1)表示等待请求方最终结果或等待核对结果的时间。

4.如权利要求1所述的方法，其特征是上述门限值是一个预定的时间(T2)。

5.如权利要求4所述的方法，其特征是上述预定时间(T2)表示最多可等待交易结果的时间，并且T2＞T1。

6.如权利要求1所述的方法，其特征是上述门限值是一个规定的核对次数(N)。

Images