分布式数据库（2）——事务

转载地址：http://vlinux.iteye.com/blog/1131464

1、事务的定义

       一系列由单个用户或者应用程序提交的数据库操作，这些操作是一个不可分可的整体。

2、事务的特性ACID：

      原子性，一致性持久性和隔离性。

3、分布式事务处理：

     分布式事务用两个阶段提交协议保证事务的原子性。两阶段提交协议中，各个节点采取的是完全同步的方法来保证数据库一致性。

4、为什么要引入分布式事务呢？

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

5、分布式事务恢复

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

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

6、分布式事务管理

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

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

7、两阶段提交协议2pc

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

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

1．站点故障、

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

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

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

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

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


2.丢失报文


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


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


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


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


3.网络分割


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

三阶段提交协议3PC

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


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




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


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


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


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


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


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