[转载]分布式事务处理，两段锁协议

之所以转载，因为说得很详细，很多情况都考虑到了。最有价值的部分在各种异常情况的解决方案。

http://langziwt.blog.sohu.com/80446965.html

 

 

 

 

分布式事务处理，两段锁协议

 

随着网络环境的日益普及，新的应用呈现出许多相似的特点那就是开放性和分布性。对于Internet商业应用来说分布性和开放性更是最基本的要求，并且随着人们对电子商务、安全防范等复杂的Web应用需求的增加，Web应用不仅仅是对只读信息的存取，面向商业活动的读取将迅速增加。这意味着，从简单的数据系统全球联网查询，逐步转向更具有分布式数据库系统特色的应用环境。

 

我们知道，研究分布式数据库系统的目的、动机主要是组织目标，即为应用所驱动。开放性、分布性不仅是当前新应用的要求，也同样是分布式数据库系统的优势所在。可以预料在当前的网络、分布、开放的大环境下，分布式数据库系统将会有更加长足的发展和应用。

 

第三章　分布式事务

 

分布式数据库通过两种策略:分布式事务和数据复制，保持各种数据副本的一致性。数据复制主要用于更新多个服务器上的大量数据。除此之外，还需要在本地的数据库服务器之间更新若干表。这时所需更新的数据量不是很大，因此决定采用分布式事务处理的方法来解决。当一个服务器上的数据进行修改时，为了保证数据的一致性，需要引起其它服务器上的数据随之更新，这就要用到分布事务(distributed transaction)的概念，并且要采用分布式的事务处理方法。

 

3．1分布式事务处理

为了更好的说明分布式事务处理的机制，首先介绍一下事务的概念。首先讨论一下分布式事务，分布式事务用两阶段提交协议保证事务的原子性。两阶段提交协议中，各结点采取的是完全同步的方法来保证数据库的一致性。

 

3．1．1事务的概念

事务作为数据库的重要概念，是并发控制的基本单位[10]。所谓“事务”是一系列有单个用户或应用程序提交的数据库操作，这些操作是一个不可分隔的整体。

 

3．1．2事务具有四个特性

原子性(Atomicity)，即一事务的操作要么全部执行，要么全部不执行。当事务非正常终止时，其中间结果将被取消。

一致性(Consistency)，又叫可串行性。并发执行的几个事务，其操作的结果应与以某种次序串行执行它们的结果相同，因此称为可串行性。这种可串行化的并发调度是由数据库系统的并发控制机制来完成，以保证并发事务执行时数据库状态一致，所以这种性质也称为事务的一致性。

隔离性(Isolation)，一个未完成事务不能在提交前就把其中间结果提供给其它事务使用。

耐久性(Durability)，一个事务正常结束即提交后其操作的结果将永久化且与提交后发生的故障无关。

事务的ACID属性[11]对开发可靠的分布式应用起着重要的作用。可串行性和隔离性主要涉及到多个事务对数据库进行存取操作时的并发控制机制;而原子性和持久性更是为了保证数据库状态一致，特别是在出现故障后仍能恢复到前一个数据库一致状态，所以涉及到恢复机制。

 

3．2分布式事务管理

在分布式数据库系统中，分布式事务管理的目的在于保证事务的正确执行及执行结果的有效性，主要解决系统可靠性、事务并发控制及系统资源的有效利用等问题。

 

在分布式数据库中对各种数据项的访问常常通过事务来完成，一个事务可能要访问分布存储在多个站点上的数据，该事务将被划分成多个子事务，每个子事务负责对一个数据存储站点进行访问。在分布式数据库中把事务分为两种类型:局部事务和全局事务。局部事务是那些仅访问和更新一个局部数据库中数据的事务：全局事务是那些访问和更新多个局部数据库中数据的事务。

 

3．3分布式事务的恢复

分布式数据库系统中，各个场地除了可能发生如同集中式数据库的那些故障外，还会出现通信时信息丢失、传送延时、线路中断等事故。因此，情况比集中式数据库更复杂，相应的恢复过程也就复杂些。

为了执行分布事务，通常在每个场地都有一个局部事务管理器，用来管理局部子事务的执行，保证事务的完整性，并且各局部事务管理器之间必须相互协调，保证所有场地对它们所处理的子事务采取相同的策略：确保要么执行，要么回滚[12]。确保这一策略的常用技术是两段提交协议(2-Phase-Commitment Protocol)简称2PC。

 

3．3．1两段提交协议2PC

两段提交协议把一个分布事务的事务管理分为两类:一个是协调者，所有其他的是参与者。协调者负责做出最后的提交或夭折决定。参与者负责本地子事务的动作。2PC的基本思想是为全部参与者做出关于提交或夭折全部本地子事务的唯一决定。如果其中有一个参与者不能本地提交其子事务，则全部参与者必须本地天折。此协议有两阶段组成，第一阶段的目的是达到一共同的决定，第二阶段的目的是实现这个决定。协议的原理如下[13]：

 

采用两段提交协议后，当系统发生故障时，各场地利用各自相关的日志信息便可执行恢复操作[14]。针对站点故障、丢失报文及网络分割等常见故障的恢复操作过程描述如下：

1．站点故障

(1)当参与者在写入“准备提交”前发生故障时，该参与者无法向协调者发回答信息，因此当协调者等待超时后，将决定天折事务。当该故障恢复后，重启动过程无须收集其它站点的信息即可夭折事务。

(2)参与者在写入“准备提交”后发生故障，这时其它的参与者可以正常的结束该事务“提交”或“天折”，因为协调者可以根据收到的应答决定“提交”或“天折”。因此，故障恢复后，重启动过程要访问协调者或参与者，以了解事务己做出的决定，然后执行相应的操作。这里我们假设在日志中写入“准备提交”记录和发送“准备提交”信息给协调者这两个动作具有原子性。

(3)协调者在日志中写入“预提交”记录后，写入“全部提交”或“全部夭折”前发生故障，这时己发出“准备提交”的参与者将等待协调者恢复。协调者的重启动过程从头恢复提交协议，从“预提交”记录中读出参与者的标志符，重发“预提交”报文给参与者，重新执行提交过程。

(4)协调者在写入“全部提交”或“全部夭折”记录后，在写入“事务结束”记录前发生故障。在这种情况下，协调者恢复时必须给所有的参与者重发其决定，未收到信息的参与者不得不等待协调者的恢复。和(3)一样，参与者不应因收到两次一样的命令而受影响。

(5)协调者在日志中写入“事务结束”记录后发生故障，这种情况下事务己结束，不需恢复处理。

2.丢失报文

(1)来自参与者的回答报文(“准备提交”或“夭折”)至少丢失一个。在这种情况下，协调者将等待回答而超时，整个事务被夭折。但它无法决定是站点故障还是通讯故障，而参与者正确执行，它不会启动恢复过程。

(2)丢失“预提交”报文，由于至少一个参与者收不到“预提交”命令，因此参与者处于等待状态，而协调者也等待参与者的回答，所以协调者会因为等待超时而夭折事务。

(3)丢失“提交”或“天折”报文，这种情况下参与者处于等待协调者命令的状态下，当未收到命令时会因等待而超时，这时向协调者发请求重发该命令的信息。

(4)丢失了“己执行”报文，当协调者未收到全部的“己执行”报文时，协调者会因等待而超时，这时协调者重发命令报文给参与者，这时参与者必须给予“执行”报文回答，即使此时相应的子事务己不在活动也要重发。

 

3.网络分割

假设在出现网络分割时，整个网络分为两个组，包含协调者的组称为协调者组，其它的则组成参与者组。这种情况对于协调者来说相当于参与者组中的多个参与者同时发生故障，这时协调者可以做出决定，然后把命令发给协调者组中的参与者，因此这些站点上的子事务可以结束。这与站点故障中的(1)和(2)两种情况类似。对于参与者失去联系，这时它们认为出现故障。这种情况与站点故障中的(3)和(4)相似。

 

3．3．2三阶段提交协议3PC

在基本的2PC协议中，当参与者等待协调者的回答时，可能因为网络故障或协调者故障使之收不到回答信息而出现等待超时，这时事务进入等待状态。当故障一直持续时，则事务就一直处于阻塞状态，因此降低了整个系统的可用性。为此，我们引入了3PC协议，这是一种非阻塞提交协议[15]。这里所说的非阻塞的提交协议只是相对一定的故障模型，到目前为止还没有一种协议可以完全避免阻塞，但是我们可以通过一定的处理减少阻塞。

在2PC协议中，参与者的提交是在它知道了其它所有的参与者均发生了“准备提交”的报文后进行的。若在2PC中增加一阶段使得参与者的提交不仅要等到它知道所有的参与者均发出了“准备提交”的报文，而且还知道所有参与者的状态(如：故障状态或已经恢复)以后才执行。这时2PC变成3PC协议。在3PC协议中，报文有三次接收和发送，协调者第二次向参与者发出的报文不是“提交报文”，而是提交前的预备报文，告诉所有的参与者均可以自己做出决定或夭折或提交，而不必因等待协调者恶意问答而进入阻塞状态，因为即使此时发生故障，系统的恢复机制迟早也要恢复故障前的一刻，即个参与者的子事务都要提交，因此，参与者可以自行决定先执行下去而不是处于等待状态，从而减少了阻塞。

 

3PC可以避免阻塞是基于一定的故障模型的。一般来说，在下列故障出现时3PC不会进入阻塞状态:

(1)只允许出现场地故障而不会出现网络分隔的情况。

(2)场地故障但不影响通讯功能，即它仍能进行正常的收发工作且信息是正确的。

(3)场地故障使得系统必须进行恢复处理，恢复机制应能知道已发生过故障且其它场地进行通信，了解故障前的情况是参与者恢复到提交状态中去。

(4)场地五故障时必须在超时以前向曾求助于它的场地发回答报文。

(5)网络不会丢失报文且场地间传送报文的次序和接收报文的次序一样。

 

3．4小结

本章主要讨论了分布式事务的概念，分布式事务提交，并具体分析了两阶段提交协议(2PC)中针对站点故障、丢失报文及网络分割等常见故障等常见故障的恢复操作做了介绍。最后引入了三阶段提交协议(3PC)。