分布式事务处理：原理、不足

http://blog.csdn.net/wdwbw/article/details/4179745

分布式事务处理（  Distributed Transaction Processing  ，  DTP  ）涉及多个分布在不同地方的数据库，但对数据库的操作必须全部被提交或者回滚。只要任一数据库操作时失败，所有参与事务的数据库都需要回滚。
Open  组织定义的分布式事务处理模型X/Open DTP  模型（1994）包括应用程序（  AP  ）、事务管理器（  TM  ）、资源管理器（  RM ，即数据库 ）、通信资源管理器（  CRM  ）四部分。而 XA 是 X/Open DTP 定义的事务管理器与数据库之间的接口规范（即接口函数），事务管理器用它来通知数据库事务的开始、结束以及提交、回滚等。
 XA  接口规范使用两阶段提交协议来完成一个全局事务，保证同一事务中所有数据库同时成功或者回滚。
两阶段提交协议假设每个数据库点都存在一个write-ahead log，每一次的write请求都是先记log后才真正执行写入。
第一阶段为提交请求阶段（Commit-request phase）：
   1. 事务管理器给所有数据库发query to commit消息请求，然后开始等待回应；
   2. 数据库如果可以提交属于自己的事务分支，则将自己在该事务分支中所做的操作固定记录下来（在undo log和redo log中各记一项）；
   3. 数据库都回应是否同意提交的应答。
第二阶段为提交阶段（Commit phase）：
如果事务管理器收到的所有回应都是agreement，
   1. 事务管理器记日志并给所有数据库发commit消息请求；
   2. 各个数据库执行操作，释放所有该事务相关的锁和资源；
   3. 各个数据库给事务管理器回复；
   4.当收到所有回复，事务管理器结束当前事务

如果事务管理器收到的任一回应是abort，
   1. 事务管理器记日志并给所有数据库发rollback消息请求；
   2. 各个数据库执行undo操作，释放所有该事务相关的锁和资源；
   3. 各个数据库给事务管理器回复；
   4.当收到所有回复，事务管理器结束当前事务

两阶段提交协议的问题在于数据库在提交请求阶段应答后对很多资源处于锁定状态，要等到事务管理器收集齐所有数据库的应答后，才能发commit或者rollback消息结束这种锁定。锁定时间的长度是由最慢的一个数据库制约，如果数据库一直没有应答，所有其他库也需要无休止的锁并等待。并且，如果事务管理器出现故障，被锁定的资源将长时间处于锁定状态。无论是任一数据库或者事务管理器故障，其他数据库都需要永久锁定或者至少长时间锁定。并且，分布式系统中节点越多，存在缓慢网络或者故障节点的概率也就越大，资源被长时间锁定的概率指数上升。
两阶段提交协议的另一个问题是只要有任意一个数据库不可用都会导致事务失败，这导致事务更倾向于失败。对于多个副本的备份系统，很多时候我们希望部分副本点失效时系统仍然可用，使用该协议则不能实现。并且，分布式系统中节点越多，存在故障节点的概率也就越大，系统的可用性指数下降。
另外，如果数据库在第一阶段应答后到第二阶段正式提交前的某个阶段网络故障或者节点故障，该协议无法提交或回滚，数据不一致不能绝对避免。