事务和两阶段提交,三阶段提交协议（有限状态自动机）

转自：http://blog.csdn.net/it_man/article/details/9730559

事务和两阶段提交,三阶段提交协议（有限状态自动机）

•1 事务的ACID

事务是保证数据库从一个一致性的状态永久地变成另外一个一致性状态的根本，其中，ACID是事务的基本特性。

A是Atomicity，原子性。一个事务往往涉及到许多的子操作，原子性则保证这些子操作要么都做，要么都不做，而不至于出现事务的部分操

作成功，而另外一部分操作没有成功。如果事务在执行的过程中发生错误，那么数据库将回滚到事务发生之前的状态。比如银行的转账服务

，这个事务的最终结果一定是：某个账户的余额增加了x，而另外一个账户的余额减少了x，或者两个账户的余额未发生变化。而不会出现其

他情况。

C是Consistency，一致性。一致性是指事务发生前和发生以后，都不会破坏数据库的约束关系，保证了数据库元素的正确性、有效性和完整

性。这种约束关系可以是数据库内部的约束，比如数据库元素的值必须在一定的范围内，也可以是应用带来的约束，比如转账以后银行账户

的余额不能为负数。

I是Isolation，隔离性。一个事务的操作在未提交以前，是不会被并行发生的其他事务访问到的。也就是说，数据库操作不会看到某个事务

的中间操作结果，比如转账过程中，用户是不能查询到一个账户余额减少了，而另外一个账户余额未发生变化的情况。

D是Durability，持久性。事务完成以后，它对数据库的影响是永久性的，即使在数据库系统发生宕机或者其他故障的情况下，这种影响也

会得到保持。
•2 两阶段提交
应用在分布式系统中。
在分布式系统中，事务往往包含有多个参与者的活动，单个参与者上的活动是能够保证原子性的，而多个参与者之间原子性的保证则需要通

过两阶段提交来实现，两阶段提交是分布式事务实现的关键。

很明显，两阶段提交保证了分布式事务的原子性，这些子事务要么都做，要么都不做。而数据库的一致性是由数据库的完整性约束实现的，

持久性则是通过commit日志来实现的，不是由两阶段提交来保证的。至于两阶段提交如何保证隔离性，可以参考Large-scale Incremental

Processing Using Distributed Transactions and Notifications中两阶段提交的具体实现。

两阶段提交的过程涉及到协调者和参与者。协调者可以看做成事务的发起者，同时也是事务的一个参与者。对于一个分布式事务来说，一个

事务是涉及到多个参与者的。具体的两阶段提交的过程如下：

第一阶段：

首先，协调者在自身节点的日志中写入一条的日志记录，然后所有参与者发送消息prepare T，询问这些参与者（包括自身），是否能够提

交这个事务；

参与者在接受到这个prepare T 消息以后，会根据自身的情况，进行事务的预处理，如果参与者能够提交该事务，则会将日志写入磁盘，并

返回给协调者一个ready T信息，同时自身进入预提交状态状态；如果不能提交该事务，则记录日志，并返回一个not commit T信息给协调

者，同时撤销在自身上所做的数据库改；

参与者能够推迟发送响应的时间，但最终还是需要发送的。

第二阶段：

协调者会收集所有参与者的意见，如果收到参与者发来的not commit T信息，则标识着该事务不能提交，协调者会将Abort T 记录到日志中

，并向所有参与者发送一个Abort T 信息，让所有参与者撤销在自身上所有的预操作；

如果协调者收到所有参与者发来prepare T信息，那么协调者会将Commit T日志写入磁盘，并向所有参与者发送一个Commit T信息，提交该

事务。若协调者迟迟未收到某个参与者发来的信息，则认为该参与者发送了一个VOTE_ABORT信息，从而取消该事务的执行。

参与者接收到协调者发来的Abort T信息以后，参与者会终止提交，并将Abort T 记录到日志中；如果参与者收到的是Commit T信息，则会

将事务进行提交，并写入记录

一般情况下，两阶段提交机制都能较好的运行，当在事务进行过程中，有参与者宕机时，他重启以后，可以通过询问其他参与者或者协调者

，从而知道这个事务到底提交了没有。当然，这一切的前提都是各个参与者在进行每一步操作时，都会事先写入日志。

唯一一个两阶段提交不能解决的困境是：当协调者在发出commit T消息后宕机了，而唯一收到这条命令的一个参与者也宕机了，这个时候这

个事务就处于一个未知的状态，没有人知道这个事务到底是提交了还是未提交，从而需要数据库管理员的介入，防止数据库进入一个不一致

的状态。当然，如果有一个前提是：所有节点或者网络的异常最终都会恢复，那么这个问题就不存在了，协调者和参与者最终会重启，其他

节点也最终也会收到commit T的信息。
•3 日志

数据库日志保证了事务执行的原子性和持久性，日志类型可以分为redo log，undo log，undo/redo log。关于这几种日志形式的具体介绍

，可以参照：

http://nosql-wiki.org/foswiki/bin/view/Main/TransactonLog

--------------------\
两阶段提交协议（two phase commit protocol，2PC）可以保证数据的强一致性，许多分布式关系型数据管理系统采用此协议来完成分布式

事务。它是协调所有分布式原子事务参与者，并决定提交或取消（回滚）的分布式算法。同时也是解决一致性问题的一致性算法。该算法能

够解决很多的临时性系统故障（包括进程、网络节点、通信等故障），被广泛地使用。但是，它并不能够通过配置来解决所有的故障，在某

些情况下它还需要人为的参与才能解决问题。参与者为了能够从故障中恢复，它们都使用日志来记录协议的状态，虽然使用日志降低了性能

但是节点能够从故障中恢复。

在两阶段提交协议中，系统一般包含两类机器（或节点）：一类为协调者（coordinator），通常一个系统中只有一个；另一类为事务参与

者（participants，cohorts或workers），一般包含多个，在数据存储系统中可以理解为数据副本的个数。协议中假设每个节点都会记录写

前日志（write-ahead log）并持久性存储，即使节点发生故障日志也不会丢失。协议中同时假设节点不会发生永久性故障而且任意两个节

点都可以互相通信。

当事务的最后一步完成之后，协调器执行协议，参与者根据本地事务能够成功完成回复同意提交事务或者回滚事务。

顾名思义，两阶段提交协议由两个阶段组成。在正常的执行下，这两个阶段的执行过程如下所述：

阶段1：请求阶段（commit-request phase，或称表决阶段，voting phase）

在请求阶段，协调者将通知事务参与者准备提交或取消事务，然后进入表决过程。在表决过程中，参与者将告知协调者自己的决策：同意（

事务参与者本地作业执行成功）或取消（本地作业执行故障）。

阶段2：提交阶段（commit phase）

在该阶段，协调者将基于第一个阶段的投票结果进行决策：提交或取消。当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提

交事务，否则协调者将通知所有的参与者取消事务。参与者在接收到协调者发来的消息后将执行响应的操作。

注意 两阶段提交协议与两阶段锁协议不同，两阶段锁协议为一致性控制协议。

-------------
XA
XA是X/Open DTP组织（X/Open DTP group）定义的两阶段提交协议，XA被许多数据库（如Oracle和DB2）和中间件等工具(如CICS 和

Tuxedo).本地支持 。
X/Open DTP模型（1994）包括应用程序（AP）、事务管理器（TM）、资源管理器（RM）、通信资源管理器（CRM）四部分。在这个模型中，

通常事务管理器（TM）是交易中间件，资源管理器（RM）是数据库，通信资源管理器（CRM）是消息中间件。

一般情况下，某一数据库无法知道其它数据库在做什么，因此，在一个DTP环境中，交易中间件是必需的，由它通知和协调相关数据库的提

交或回滚。而一个数据库只将其自己所做的操作（可恢复）影射到全局事务中。

XA就是X/Open DTP定义的交易中间件与数据库之间的接口规范（即接口函数），交易中间件用它来通知数据库事务的开始、结束以及提交、

回滚等。XA接口函数由数据库厂商提供。通常情况下，交易中间件与数据库通过XA 接口规范，使用两阶段提交来完成一个全局事务，XA规

范的基础是两阶段提交协议。

-------------
三阶段提交协议（有限状态自动机）
http://my.oschina.net/picasso/blog/36572