CN101706811A

CN101706811A - 一种分布式数据库系统事务提交方法

Info

Publication number: CN101706811A
Application number: CN200910238270A
Authority: CN
Inventors: 付艳艳; 陈驰; 王伏根; 殷佳欣; 张大朋
Original assignee: Institute of Software of CAS
Current assignee: Institute of Software of CAS
Priority date: 2009-11-24
Filing date: 2009-11-24
Publication date: 2010-05-12
Anticipated expiration: 2029-11-24
Also published as: CN101706811B

Abstract

本发明公开了一种分布式数据库系统事务提交方法，属于计算机网络技术领域。本方法为：1)在参与者节点和协调器节点内存中各分配一缓存区域，用来缓存事务日志；2)协调器节点根据事务内容确定参与者节点并与之建立连接，同时确定事务的操作请求信息；3)协调器节点向参与者节点发送事务的单步操作请求消息，同时记录每个操作请求的事务请求日志；4)参与者节点根据每个操作请求的完成情况处理本地日志，并向协调器节点发送相应的消息；5)协调器节点根据接收到的所有参与者节点发送的消息判断事务是否完成，如果完成给出最终决定。与现有技术相比，本发明大大减少了日志操作次数，提高了系统效率和事务效率，具有极高的可用性。

Description

一种分布式数据库系统事务提交方法

技术领域

本发明涉及一种数据库系统事务提交方法，尤其涉及一种分布式数据库系统中事务提交方法，属于计算机网络技术领域。

背景技术

分布式系统是数据被存储于各种数据库中的多节点系统。节点可以是诸如计算机系统之类的任何数据处理系统，可以处于一个位置或者散布于多个位置，通过诸如局域网或者广域网之类的网络彼此连接。分布式系统的示例包括数据库系统、邮件服务器系统等。

由于一个事务可能修改分布式系统中多个节点的数据，为了满足分布式系统的数据一致性，无论是否发生故障(例如供电中断、硬件冲突等)，都必须要满足以下条件：事务是原子的，即事务要么成功执行所有请求，要么没有任何请求被执行。

分布式系统通常利用两阶段提交(2PC)协议来保持数据一致性。在2PC系统中，每个事务的协调器节点、即客户端(例如应用程序)递交事务的节点，为事务中的每个请求识别分布式系统中持有请求对应的资源，负责处理请求的节点。持有请求对应的资源，并被分配用来处理事务中的请求的每个节点被称为参与者节点。这一步骤确定了事务参与者节点，并建立协调器节点到参与者节点的连接，为事务进行准备。

两阶段提交协议中的每个参与者节点投票决定提交还是回退事务，并将其投票发送到协调器节点。然后，协调器节点基于来自每个参与者节点的投票做出提交还是回退事务的最终决定。如果所有参与者节点认可提交，则写入一个日志记录以指示结果并且通知所有参与者节点提交事务。如果有一个或以上的参与者节点认为不能提交，则写入日志记录指示结果并通知所有认可提交的参与者节点将事务回退。

一旦参与者节点投票同意提交，必须等待协调者的最终决定才能进行下一步动作。如果某个参与者投票不能提交，则可自行回退。

参与者节点执行完事务提交或回退后，需回复事务结束消息给协调器节点。协调器节点接到所有参与者节点的反馈消息后，记录事务结束日志，事务正式结束。

两阶段提交协议存在如下的缺点：

1)两阶段提交协议的日志写入操作是频繁的。为了保证事务的原子性和系统的可恢复性，在两阶段提交协议的执行过程中，日志的写入操作必须强制执行。在有n个参与者节点和1个协调者节点组成的2PC系统中，执行一次两阶段提交协议，需要进行2n+1次强制日志操作。

2)两阶段提交协议不是消息高效的。在有n个参与者节点和1个协调者节点组成的2PC系统中，执行一次两阶段提交协议，传递的信息数量为4n条。

3)两阶段提交协议的高效执行依赖于包含协调者和所有参与者节点的全网络范围的畅通.在网络拥塞的环境下，任何一个投票同意提交的参与者节点必须等待协调者的最终决定才能完成操作并释放持有的资源.在此期间，任何请求参与者持有的资源的操作均需排队等待.而且，在没有得到参与者节点回复事务结束的消息，协调器节点也不能认为事务已经结束，而必须持有事务记录而不能“遗忘”(释放内存).

目前的技术主要是单一寻求消息高效的解决方案或者日志操作减少的方案，或者仅针对某一类事务的特点进行优化，并不能充分实现分布式系统事务提交的高效处理，因此需要一种比现有的提交技术更有效的分布式事务提交方法。

发明内容

针对目前分布式系统事务提交效率不高的问题，本发明的目的在于提供一种分布式数据库系统事务提交方法，在事务成功提交或者回退的条件下都可以保证较少的信息传递量和强制日志操作次数。

本发明的技术方案为：

一种分布式数据库系统事务提交方法，其步骤为：

1)在参与者节点和协调器节点内存中各分配一缓存区域，用来缓存事务日志；

2)协调器节点根据事务内容确定参与者节点并与之建立连接，同时确定事务的操作请求信息；

3)协调器节点向参与者节点发送事务的单步操作请求消息，同时记录每个操作请求的事务请求日志；

4)参与者节点根据每个操作请求的完成情况处理本地日志，并向协调器节点发送相应的消息；

5)协调器节点根据接收到的所有参与者节点发送的消息进行判断：

a)如果事务需要回退，则协调器节点缓存本地事务日志，并向返回消息中事务的操作请求完成为成功的参与者节点发送事务回退消息；然后参与者节点执行接

收到的事务回退消息并缓存事务日志；

b)如果事务可以提交，则协调器节点缓存本地事务日志，并向本事务的所有参与者节点发送提交消息；然后参与者节点执行接收到的提交消息并缓存事务日志；

c)如果所有参与者节点返回消息中事务的操作请求完成为成功，并且事务尚未完成，则重复步骤3)～5)。

进一步的，所述事务的操作请求信息包括：事务的各个操作请求，以及事务的操作请求总数n。

进一步的，所述协调器节点在每次事务开始时，确定当前协调器节点中是否存在缓存事务日志，如果存在则将其一次性写入磁盘；如果所述参与者节点的缓存区域满或者缓存超过设定时间或者发生强制写入缓存事务日志时，将缓存事务日志一次性写入磁盘。

进一步的，所述事务的操作请求消息包括：事务ID、协调器ID、涉及此操作请求所有参与者ID、事务单步请求内容、i、协调器本地时间戳；所述向协调器节点发送相应的消息包括：协调器ID、协调器事务ID、本地参与者ID、i、vote、协调器节点发送的最新时间戳；所述参与者节点的本地日志包括：本地事务ID、协调器ID、协调器事务ID、涉及此操作请求所有参与者ID、事务单步请求内容、vote、协调器节点发送的最新时间戳；其中i为本次事务的第i步操作请求，vote为本次事务操作请求完成情况。

进一步的，所述协调器节点记录每个操作请求的事务请求日志的方法为：如果事务的操作请求是一个新事务的操作请求，则将该新事务的事务开始日志强制写入磁盘；如果事务的操作请求是当前事务的第i步请求，则缓存本次日志.

进一步的，所述事务开始日志包括：事务ID、协调器ID、涉及事务所有操作的所有参与者ID、事务第1步请求内容、本次事务开始标志、协调器本地时间戳；所述事务的第i步请求的日志包括：事务ID、协调器ID、涉及事务第i步操作所有参与者ID、事务第i步请求内容、i、协调器本地时间戳，其中i＞1。

进一步的，所述参与者节点处理本地日志，并向协调器节点发送相应的消息的方法为：如果参与者节点对事务的操作请求完成为失败，则需要缓存事务日志，返回信息给协调器节点并回退事务；如果参与者节点对事务的操作请求完成为成功，则只需缓存事务日志，返回信息给协调器节点并等待协调器节点发送事务的操作请求消息。

进一步的，所述步骤5)中，如果有一个或一个以上的参与者节点在设定时间内没有返回消息或者返回消息中事务的操作请求完成为失败，则协调器节点判断为事务需要回退；如果所有参与者节点返回消息中事务的操作请求完成为成功，并且参与者节点返回消息中事务的操作请求数等于本事务的操作请求总数，则协调器节点判断为事务可以提交。

进一步的，所述步骤5)中，所述事务回退消息包括：事务ID、协调器ID、参与者ID、事务回退决定、事务结束标志、协调器本地时间戳；所述事务提交消息包括：事务ID、协调器ID、参与者ID、事务提交决定、事务结束标志、协调器本地时间戳；协调器节点缓存的本地事务日志包括：事务ID、协调器ID、参与者ID、事务最终决定、事务结束标志、协调器本地时间戳；参与者节点缓存的事务日志包括：本地事务ID、协调器ID、协调器事务ID、参与者ID、事务结束标志、事务最终决定、协调器节点发送的最新时间戳；所述事务最终决定为事务回退决定或事务提交决定。

进一步的，如果所有参与者节点在设定时间内都没有收到协调器节点发出的回退消息或提交消息，则参与者节点首先根据接收到的执行同一事务步骤的参与者名单进行互相询问：

a)如果有参与者的操作请求完成为失败，则所有事务参与者均执行事务回退消息；

b)如果所有参与者的操作请求完成为成功，则参与者节点继续等待协调器节点发出的消息；

c)如果有参与者节点收到回退消息或提交消息，则其余参与者参照执行；

d)如果有参与者节点在限定的时间内无法取得联系，并且无法确定事务是否可回退，则继续等待。

进一步的，如果协调器节点失效，则在协调器节点重启之后首先查找本地最后的事务结束日志的时戳，然后询问所有的参与者节点在此时间之前未结束的本协调器发起的事务记录：

a)如果有一个或以上的参与者节点回复的日志表明事务已自行回退，则协调器节点整理接收到的日志以恢复本地日志，保存事务回退记录并重新通知所有参与者该事务回退；

b)如果所有参与者均回复的日志表明事务仍在等待，则协调器节点整理接收到的日志以恢复本地日志，根据事务的执行情况决定事务提交或者回退；

c)如果有参与者尚未从参与者节点失效中恢复，不具有全部的日志；或者有参与者无法取得联系，则认为事务回退，协调器节点整理接收到的日志以恢复本地日志，写入回退日志并在与参与者节点恢复联系后向参与者节点发送事务决定.

为了减少事务频繁的强制日志操作，本发明首先在系统参与者节点和协调器节点内存中各分配一定的缓存区域，用来缓存事务日志。对于参与者节点，当缓存区域满或者缓存超过一定时间之后或者强制写日志时，将缓存日志一次性写入磁盘。对于协调器节点，则在每次事务开始时，将缓存日志一次性写入。

在事务开始前，协调器节点根据事务内容寻找对应的参与者，将事务各指令发送到对应参与者节点执行。然后通过协调器节点与参与者节点间进行的信息传递和协调器节点时间戳来保证整个事务执行过程的原子性，以及故障时的可恢复性，并增加了系统的灵活性。整个方法分为两个方面：

第一方面进行事务准备。包括：根据事务内容寻找所涉及的资源，确定资源所在的节点；为应用程序建立到多个资源中的每个资源的连接；确定当前事务的上下文。

第二方面为了保证事务的顺利进行，严格执行信息传递的步骤和要求。

具体而言，本发明的分布式事务提交方案可以通过以下步骤实现：

1)协调器节点根据事务内容查找需要使用的资源，确定资源所在的节点(即确定参与者节点)；建立到资源的连接；确定当前协调器节点中是否存在缓存日志，确定事务的各个操作请求，以及请求总数。

2)协调器节点向参与者节点发送事务的操作请求消息。在此消息中，包含协调器ID，协调器本地时间戳TimeStamp，事务单步请求内容，以及涉及此单步请求的所有参与者ID，协调器本地的事务ID。消息格式如下：

事务ID

协调器ID

参与者ID

事务单步请求内容

i

TimeStamp

其中i表明本次请求为事务第i步操作。

同时，协调器节点根据事务请求情况写日志：

①如果是一个新的事务，则强制写入事务开始日志。如果在1)中确认当前协调器节点中存在事务缓存日志，则将缓存日志与事物开始日志一同刷新入磁盘。如果在1)中确认当前协调器节点不存在事务缓存日志，只需强制写入事务开始日志。

事务开始日志格式如下：

事务ID

协调器ID

参与者ID

事务单步请求内容

start

TimeStamp

其中，start为本次事务开始标志，表明本次事务开始，也可以用“1”表示。参与者ID为参与此事务所有步骤的所有参与者ID。

②如果是事务的第i步请求，则缓存本次日志。

事务第i步请求日志格式

事务ID

协调器ID

参与者ID

事务单步请求内容

i

TimeStamp

其中，i＞1。参与者ID为参与事务第i步的参与者ID。

3)参与者根据事务的操作请求完成情况处理本地日志，并向协调器节点发送消息。本地日志和消息均需根据步骤2)中接收到的消息加入相应信息。

消息格式如下：

协调器ID

协调器事务ID

本参与者ID

i

vote

TimeStamp

其中，“协调器事务ID”是步骤2)中传递的本次事务在协调器节点对应的“事务ID”；“本参与者ID”即为本地参与者的ID信息；“i”表明本次操作请求为事务的第i次请求，根据步骤2)中传递的信息可得；“vote”为事务的操作请求完成情况说明，可为“yes”或“no”，分别对应事务的操作请求成功或失败；“TimeStamp”为本消息对应的协调器消息中包含的时间戳。

日志格式如下：

本地事务ID

协调器ID

协调器事务ID

参与者ID

OP

vote

TimeStamp

其中，“本地事务ID”为本次事务的操作请求在参与者节点本地对应的事务ID。“OP”为事务单步请求内容，从协调器节点传递的消息可得。

如果参与者节点没有完成事务的操作请求，则需要缓存日志，返回信息给协调器节点并立即回退事务。如果参与者节点完成了事务的操作请求，则只需缓存日志，返回信息给协调器节点并等待协调器节点的进一步指示。

如果在缓存日志之前，检查到本地日志缓存区域已满，或者最陈旧的日志到达最长缓存时间，则强制写入日志，再向协调器节点发送对应消息。

4)协调器节点接收参与者节点信息，分析投票结果，并向参与者节点发送消息。

①如果有一个或以上的参与者节点没有及时投票或者投票结果为“no”，事务需要回退。在这种情况下，协调器节点缓存本地日志，向所有投票“yes”的参与者节点传送事务回退消息。本缓存日志可随下一次协调器节点的强制日志记录操作一起写入。进入步骤5)。消息格式如下：

事务ID

协调器ID

参与者ID

Abort

end

TimeStamp

日志格式如下：

事务ID

协调器ID

参与者ID

Abort

end

TimeStamp

其中，“end”表明事务结束，可以用“0”表示。

②如果所有参与者均投票为“yes”，并且参与者节点返回的信息中表明的事务的操作请求数i也符合1)中确定的本事务的操作请求总数，则事务可以提交。在这种情况下，协调器节点缓存本地日志，向本事务的所有参与者节点发送提交消息。本缓存日志可随下一次协调器节点的强制日志记录操作一起写入。进入步骤5)。

消息格式如下：

事务ID

协调器ID

参与者ID

Commit

end

TimeStamp

日志格式如下：

事务ID

协调器ID

参与者ID

Commit

end

TimeStamp

其中，“end”表明事务结束，可以用“0”表示。

③如果所有参与者节点投票均为“yes”并且事务尚未完成，则回到步骤2)。

5)参与者节点按照最终决定执行并缓存日志。日志结构如下：

本地事务ID

协调器ID

协调器事务ID

参与者ID

end

fi

TimeStamp

其中，“end”表明事务结束；“fi”为事务最终决定，为“commit”或者“abort”。

如果在缓存日志之前，检查到本地日志缓存区域已满，或者最陈旧的日志到达最长缓存时间，则强制写入日志，再执行要求的操作。

分布式系统中出现的故障分为两类：一类为网络原因造成的通信故障，另一类为协调器节点或参与者节点失效(site failure)。以下分别介绍这两种故障的处理方法。

对于通信故障，如果出现在步骤2)中，参与者节点可能全部接受不到协调器节点的请求，协调器节点待等待超时后，可自主决定回退事务；或者部分参与者节点没有接收到请求，这种情况下，协调器节点会认为没有应答的参与者节点已经回退事务，所以，协调器节点决定回退事务。

如果出现在步骤3)中，则可能协调器节点不能接收到所有参与者节点的投票，在这种情况下，协调器节点认为，没有投票的参与者节点已经回退事务，所以决定回退事务。

如果出现在步骤4)中，则可能所有参与者节点都没有收到最终决定，在这种情况下，参与者节点首先会根据接收到的执行同一事务的参与者名单进行互相询问：如果有参与者的投票为回退事务，则所有事务参与者均可依此回退事务，并向询问过此消息的参与者回复事务回退消息；如果可取得联系的所有参与者的投票均为提交事务，由于参与者节点不能判断事务是否已执行完全部请求，也不能判定自己持有的参与者名单是否包括所有参与者，所以需要继续等待协调器节点的最终决定；或者有部分参与者收到最终决定，则其余参与者可依此执行最终决定，并向询问过此消息的参与者回复事务最终决定；如果有部分参与者节点在限定的时间内无法取得联系，并且无法确定事务是否可回退，则应继续等待。

协调器节点失效的情况，可分成两类来讨论。

如果协调器节点失效，在协调器节点重启之后，会首先查找本地最后的事务结束日志的时戳.然后询问所有的参与者节点在此时间之前未结束的本协调器发起的事务记录.各参与者节点返回此事务相关的日志，情况可分为三种：①日志表明事务已自行回退.由于长时间无法获得协调器节点的消息，参与者节点必然等待超时，然后互相发起询问，如果有任何一个参与者节点的投票结果为no，此事务可自行回退.如果协调器节点接到一个或以上参与者节点回复的事务回退消息，协调器节点整理接收到的日志以恢复本地日志，并重新通知所有参与者该事务回退即可.②日志表明事务仍在等待.如果所有参与者节点均回复事务等待中，此时，协调器节点整理接收到的日志以恢复本地日志，并根据事务的执行情况决定事务提交或者回退.③如果有参与者尚未从参与者节点失效中恢复，不具有全部的日志，或者无法取得联系，则认为事务回退，协调器节点整理接收到的日志以恢复本地日志，写入回退日志并在与参与者节点恢复联系后向参与者节点发送决定.

在此过程中，如果有参与者节点被通知某事务回退，但是此参与者自身已经遗失了事务相关的记录，需再次请求协调器节点事务相关日志。

如果参与者节点失效，在参与者节点重启之后，会首先查找本地静态日志的最后时戳，然后询问协调器节点在此时间之后的事务情况。根据协调器节点的日志记录进行恢复即可。

同传统2PC相比，本事务提交方法具有以下优点：

1)对于有n个参与者节点和1个协调器节点的分布式系统，只需要进行1次强制日志记录，对比传统2PC需要2n次强制日志记录，大大减少了日志操作次数，提高了系统效率。

2)信息交换的数量从4n条变为2n_op+n，其中n_op是事务总共进行的操作数。例如，假设事务请求总共为k步，每次请求大约有60％的参与者节点参与此事务，则n_op＝k*60％*n。对于通常情况下的只包含一个请求的事务，n_op＝60％*n，此时的信息交换数量为2.2n，要远远小于传统2PC的4n条的信息交换量。

3)利用参与者名单在参与者之间互相进行询问，可以减少通信故障中一些情况下参与者的等待时间，提高事务效率，并具有极高的可用性，对于可确定事务回退的情况，可有效解决传统2PC在网络拥塞的情况下，事务排队等待的状况。将消息中传递的参与者名单限制在参与同一事务步骤的参与者中，也很好的控制了询问规模。

参与者节点的日志均采用缓存策略，当缓存空间满，或者到达缓存时间上限时，即可一次性写入磁盘。日志的安全性简单说明如下：

设一台主机出现故障的概率为常数λ，则主机的平均无故障时间(MTTF)为1/λ。由于主机间出现故障的概率是相互独立的，主机数为n，则在时间0到t内，所有主机出现故障的概率应当为p＝(1-e^-λt)ⁿ。设单台主机的MTTF为T，则λ＝1/T，所以

假设单台主机的无故障时间为100小时，事务进行时间为1分钟，在此时间内所有主机均故障，日志丢失，无法查询的概率为：

p＝(0.00016665277854932547)ⁿ≈(2×10^-4)ⁿ由于协调器节点每次强制日志记录操作会将系统中所有的缓存日志一并写入磁盘，日志缓存的时间被缩短，相应日志丢失的概率更小。

附图说明

图1是传统两阶段提交协议的流程。

图2是本发明的事务提交流程。

具体实施方式

下面结合附图和一个范例对本发明做进一步详细的说明，但不以任何方式限制本发明的范围。

考虑如下例子。一个商业连锁店，有一个中央机构和n个不同的销售店。中央机构用来保存员工数据，整个连锁店的货物种类及各个销售点的存货种类等；销售店保存本店的销售和存货数据。如果经理要查询所有商店，找出所有店中牙刷的存货数量，并将所有存货不足300的商店存货补足300。

假设数据情况如下：

商店1，2，3，4，5存货中包含牙膏，存量分别为100，200，300，400，500。协调器节点事务ID为654321；每个参与者节点事务ID分别为154321，254321，354321，454321，554321；协调器节点ID为″X″，其余参与者节点ID依次为“A”“B”“C”“D”“E”；事务请求可分为两次完成，分别为查询请求op_1和更新请求op_2。参与者节点的投票结果为yes或no。

事务的执行步骤如下：

1)提交事务的节点，即经理所在的节点自动成为协调器节点。协调器节点根据自己保存的记录确定哪些商店的存货种类包含牙膏，建立到这些数据库的连接。也就是确定商店1，2，3，4，5为参与者节点并建立到这些节点的连接。查看自身日志缓存区域，确定是否有缓存的日志尚未写入静态存储系统。

2)协调器节点向所有参与者节点发送事务消息。消息格式为：

654321

X

A，B，C，D，E

Op_1

1

TimeStamp

同时，协调器节点强制写入日志。日志结构

654321

X

A，B，C，D，E

Op_1

start

TimeStamp

如果在1)中确定有缓存的日志未写入静态存储系统，则一同写入。

3)如果参与者节点完成Op_1事务请求，则缓存本地日志并将投票发送给协调器节点。各个参与者节点的日志结构和发送的消息分别如下：

参与者节点1：

日志格式：

154321

X

654321

A，B，C，D，E

Op_1

yes

TimeStamp

消息格式：

X

654321

A

1

yes

TimeStamp

参与者节点2：

日志格式：

254321

X

654321

A，B，C，D，E

Op_1

yes

TimeStamp

消息格式：

X

654321

B

1

yes

TimeStamp

参与者节点3：

日志格式：

354321

X

654321

A，B，C，D，E

Op_1

yes

TimeStamp

消息格式：

X

654321

C

1

yes

TimeStamp

参与者节点4：

日志格式：

454321

X

654321

A，B，C，D，E

Op_1

yes

TimeStamp

消息格式：

X

654321

D

1

yes

TimeStamp

参与者节点5：

日志格式：

554321

X

654321

A，B，C，D，E

Op_1

yes

TimeStamp

消息格式：

X

654321

E

1

yes

TimeStamp

如果参与者节点没有完成事务请求，则缓存事务回退日志并回退事务。日志结构和消息格式同上，只需要将对应的yes换成no即可。

在缓存日志之前，检查是否需要强制写入日志，如果需要，则先强制写入日志，再进行其他操作。

4)协调器节点分析投票结果。如果第3)步中所有的参与者节点都返回yes消息，事务进入步骤5)；否则进入步骤7)。

5)协调器节点向所有参与者节点发送事务消息。消息格式为：

654321

X

A，B

Op_2

2

TimeStamp

同时，协调器节点缓存日志。日志结构

654321

X

A，B

Op_2

2

TimeStamp

6)如果参与者节点完成Op_2事务请求，则缓存本地日志并将投票发送给协调器节点。各个参与者节点的日志结构和发送的消息分别如下：

参与者节点1：

日志格式：

154321

X

654321

A，B

Op_2

yes

TimeStamp

消息格式：

X

654321

A

2

yes

TimeStamp

参与者节点2：

日志格式：

254321

X

654321

A，B

Op_2

yes

TimeStamp

消息格式：

X

654321

B

2

yes

TimeStamp

如果参与者节点没有完成Op_2事务请求，则缓存事务回退日志并回退事务。日志结构和消息格式同上，只需要将对应的yes换成no即可。

7)协调器节点根据投票结果决定事务下一步操作。

如果有一个或以上的参与者节点没有及时投票或者投票为“no”，则事务需要回退。在这种情况下，协调器节点缓存本地日志，向所有投票yes的节点传送事务回退消息。本缓存日志可随下一次协调器节点的强制日志记录操作一起写入。

消息格式如下：

654321

X

A，B，C，D，E

Abort

end

TimeStamp

日志格式如下：

654321

X

A，B，C，D，E

Abort

end

TimeStamp

如果所有参与者节点均投票“yes”，并且为事务步骤数为2，则事务可以提交。在这种情况下，协调器节点缓存本地日志，向所有参与者节点发送提交消息。

消息格式如下：

654321

X

A，B，C，D，E

Commit

end

TimeStamp

日志格式如下：

654321

X

A，B，C，D，E

Commit

end

TimeStamp

8)参与者节点按照最终决定缓存日志并执行。日志结构如下：最终决定为提交时：

参与者节点1：

154321

X

654321

A，B，C，D，E

end

Commit

TimeStamp

其余参与者节点只需替换本地事务ID即可。

如果最终决定为回退事务，只需将Commit替换为Abort即可。

按照此流程，成功执行此事务需要交换信息数量为19条，强制日志记录1次。若按照传统2PC，除去事务请求发送阶段的通信，还需要交换信息20条，强制日志记录11次。由此可见，本发明采用的方法具有明显的优势。

Claims

1.一种分布式数据库系统事务提交方法，其步骤为：

a)如果事务需要回退，则协调器节点缓存本地事务日志，并向返回消息中事务的操作请求完成为成功的参与者节点发送事务回退消息；然后参与者节点执行接收到的事务回退消息并缓存事务日志；

2.如权利要求1所述的方法，其特征在于所述事务的操作请求信息包括：事务的各个操作请求，以及事务的操作请求总数n。

3.如权利要求1或2所述的方法，其特征在于所述协调器节点在每次事务开始时，确定当前协调器节点中是否存在缓存事务日志，如果存在则将其一次性写入磁盘；如果所述参与者节点的缓存区域满或者缓存超过设定时间或者发生强制写入缓存事务日志时，将缓存事务日志一次性写入磁盘。

4.如权利要求2所述的方法，其特征在于所述事务的操作请求消息包括：事务ID、协调器ID、涉及此操作请求所有参与者ID、事务单步请求内容、i、协调器本地时间戳；所述向协调器节点发送相应的消息包括：协调器ID、协调器事务ID、本地参与者ID、i、vote、协调器节点发送的最新时间戳；所述参与者节点的本地日志包括：本地事务ID、协调器ID、协调器事务ID、涉及此操作请求所有参与者ID、事务单步请求内容、vote、协调器节点发送的最新时间戳；其中i为本次事务的第i步操作请求，vote为本次事务操作请求完成情况。

5.如权利要求4所述的方法，其特征在于所述协调器节点记录每个操作请求的事务请求日志的方法为：如果事务的操作请求是一个新事务的操作请求，则将该新事务的事务开始日志强制写入磁盘；如果事务的操作请求是当前事务的第i步请求，则缓存本次日志。

6.如权利要求5所述的方法，其特征在于所述事务开始日志包括：事务ID、协调器ID、涉及事务所有操作的所有参与者ID、事务第1步请求内容、本次事务开始标志、协调器本地时间戳；所述事务的第i步请求的日志包括：事务ID、协调器ID、涉及事务第i步操作所有参与者ID、事务第i步请求内容、i、协调器本地时间戳，其中i＞1。

7.如权利要求1或4所述的方法，其特征在于所述参与者节点处理本地日志，并向协调器节点发送相应的消息的方法为：如果参与者节点对事务的操作请求完成为失败，则需要缓存事务日志，返回信息给协调器节点并回退事务；如果参与者节点对事务的操作请求完成为成功，则只需缓存事务日志，返回信息给协调器节点并等待协调器节点发送事务的操作请求消息.

8.如权利要求2所述的方法，其特征在于所述步骤5)中，如果有一个或一个以上的参与者节点在设定时间内没有返回消息或者返回消息中事务的操作请求完成为失败，则协调器节点判断为事务需要回退；如果所有参与者节点返回消息中事务的操作请求完成为成功，并且参与者节点返回消息中事务的操作请求数等于本事务的操作请求总数，则协调器节点判断为事务可以提交。

9.如权利要求1所述的方法，其特征在于所述步骤5)中，所述事务回退消息包括：事务ID、协调器ID、参与者ID、事务回退决定、事务结束标志、协调器本地时间戳；所述事务提交消息包括：事务ID、协调器ID、参与者ID、事务提交决定、事务结束标志、协调器本地时间戳；协调器节点缓存的本地事务日志包括：事务ID、协调器ID、参与者ID、事务最终决定、事务结束标志、协调器本地时间戳；参与者节点缓存的事务日志包括：本地事务ID、协调器ID、协调器事务ID、参与者ID、事务结束标志、事务最终决定、协调器节点发送的最新时间戳；所述事务最终决定为事务回退决定或事务提交决定。

10.如权利要求1所述的方法，其特征在于如果所有参与者节点在设定时间内都没有收到协调器节点发出的回退消息或提交消息，则参与者节点首先根据接收到的执行同一事务步骤的参与者名单进行互相询问：

11.如权利要求1所述的方法，其特征在于如果协调器节点失效，则在协调器节点重启之后首先查找本地最后的事务结束日志的时戳，然后询问所有的参与者节点在此时间之前未结束的本协调器发起的事务记录：

c)如果有参与者尚未从参与者节点失效中恢复，不具有全部的日志；或者有参与者无法取得联系，则认为事务回退，协调器节点整理接收到的日志以恢复本地日志，写入回退日志并在与参与者节点恢复联系后向参与者节点发送事务决定。