一阶段提交、二阶段提交、三阶段提交

原文参考:http://blog.csdn.net/bluishglc/article/details/7612811


[b]数据库要求:ACID[/b]
原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。


原子性：所有的改变要么都做了，要么都没做。
一致性：数据保持一致性状态。
隔离性：其它用户看不到部分改变。
持久性：一旦向用户确认了事务，数据就处于安全的状态（通常存在硬盘上）。

[b]一阶段提交[/b]
一阶段提交非常直白，就是从应用程序向数据库发出提交请求到数据库完成提交或回滚之后将结果返回给应用程序的过程。一阶段提交不需要“协调者”角色，各结点之间不存在协调操作，因此其事务执行时间比两阶段提交要短，但是提交的“危险期”是每一个事务的实际提交时间，相比于两阶段提交，一阶段提交出现在“不一致”的概率就变大了。但是我们必须注意到：只有当基础设施出现问题的时候(如网络中断，当机等)，一阶段提交才可能会出现“不一致”的情况，相比它的性能优势，很多团队都会选择这一方案。

可以通过事务补偿机制使数据达到最终一致性（就是数据已经记录在部分节点上了，在后面的一个时间段后进行数据同步更新到所有的节点上，使所有的节点上的数据是一致的）。


[b]两阶段提交[/b]
两阶段提交主要保证了分布式事务的原子性：即所有结点要么全做要么全不做
所谓的两个阶段是指：
第一阶段：准备阶段。
第二阶段：提交阶段。

1.准备阶段：事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的redo和undo日志，但不提交，到达一种“万事俱备，只欠东风”的状态。

2.提交阶段：如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)


[b]三阶段提交[/b]
就是在两阶段提交中间再放一个prepare_commit的过程保证各个节点的数据的一致性。