标签：
一、二阶段提交协议
一般分为协调器C和若干事务执行者Si两种角色：
当执行某一事务T的所有站点Si都通知C事务执行完成，C即启动二阶段提交协议。
(1) 首先C向所有Si发<prepare>消息(C先将<prepare>消息写到本机日志) ，Si收到<prepare>消息后，根据本机T的执行情况，如果成功返回<ready T>，不成功返回<abort T>。(返回前都应把要返回的消息写到日志里)
(2) C收集完所有Si的返回消息后(或经过一个超时周期后) ，如果都返回的是<ready T>，则事务成功，发送给所有站点<commit T>，否则事务失败发送<abort T>。发送前还是应把消息写到日志里。站点Si接收到C的<commit T>或<abort T>后先把消息写到日志里，然后再根据消息提交或回滚。
注：C或Si把发送或接收到的消息先写到日志里，主要是为了故障后恢复用。如某一Si从故障中恢复后，先检查本机的日志，如果已收到<commit T>，则提交，如果<abort T>则回滚。如果是<ready T>，则再向C询问一下，确定下一步。如果什么都没有，则很可能在<prepare>阶段Si就崩溃了，因此需要回滚。
二阶段提交的缺陷在于如果C崩溃，所有Si可能都需要等待C，从而产生阻塞。
二、二阶段提交过程
第一阶段：
首先，协调者在自身节点的日志中写入一条的日志记录，然后所有参与者发送消息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信息，则会将事务进行提交，并写入记录。
一般情况下，两阶段提交机制都能较好的运行，当在事务进行过程中，有参与者宕机时，他重启以后，可以通过询问其他参与者或者协调者，从而知道这个事务到底提交了没有。当然，这一切的前提都是各个参与者在进行每一步操作时，都会事先写入日志。
标签：
原文地址：http://www.cnblogs.com/chy2055/p/5200592.html
