1. 流程
1) Coordinator (协调者) 广播 VOTE-REQ 给所有 Participant (参与者)
2) Coordinator 等待 Participant 的结果
3) Participant 回复 YES or NO 给 Coordinator
4) Coordinator 收集所有结果后, 广播 COMMIT or ABORT 给所有 Participant
其中, 当 Participant 处于 状态 3 与 状态 4 之间的时候(已经发送 YES 并等待 Coordinator 的回复)称之为不确定状态, 这个状态处于阻塞状态
2. 超时协议
Participant 与 Coordinator 可能会处于无法通信的状态, 这时候可以有不同的处理策略
1) Termination Protocol
在与协调者的通信恢复之前p始终保持阻塞。之后，协调者通知p对应的决定结果。协调者肯定支持这样做，因为它没有不确定区间。该terminaion protocol满足AC5，因为如果所有的故障都修复了的话，p就能与协调者通信，然后就能达到决定状态。
这种简单的terminaion protocol缺点在于，p可能要经历不必要的阻塞。比如，假设现在有两个参与者p和q。协调者先给q发送了一个COMMIT或ABORT消息，但是在发送给p之前发生了故障。因此，尽管p是不确定的，但是q不是。如果p可以与q进行通信，那么它就可以从q那得知最终的决定结果。并不需要一直等待着协调者的恢复。
2) Cooperative Termination Protocol
参与者p如果在不确定区间超时，它会发送一个DECISION-REQ消息给所有其他进程，设为q，问下q是否知道决定结果或者能否单方面地做出决定。在这个场景中，p是initiator，q是responder。有如下三种情况：
1. q已经决定进行Commit(或Abort)：q简单地发送一个COMMIT(或ABORT)消息给p，然后p进行相应动作
2. q还未进行投票：q可以单方面地决定进行Abort。然后它发送ABORT消息给p，p会因此决定进行ABORT
3. q已经投了Yes但是还未做决定：q也是处于不确定状态，因此无法帮助p达成决定。
对于该协议来说，如果p可以同某个进程q通信并且上述1或2成立，那么p就可以不经阻塞地达成决定。另一方面，如果p通信的所有进程都是3成立，那么p就会被阻塞。那么p将会一直阻塞，直到故障修复的出现了某个进程q满足条件1或2为止。
3. 故障
Coordinator 和 Participant 有可能会发生故障, 故障恢复后, 需要根据发生故障时的状态来决定, 所以需要将各个状态写入 DT log
* 如果DT log包含一个start-2PC记录，那么说明S就是协调者所在节点。如果它还有commit(或abort)记录，那么说明在发生故障前协调者已经做出了决定。如果这两种记录(commit或abort)都没有找到，那么协调者可以通过向DT log中插入一条abort记录来单方面地决定进行Abort。这样可以工作的关键在于，协调者是先将commit记录写入DT log，然后再发送COMMIT消息的(上面的第3点)。
* 如果DT log中没有start-2PC记录，那么S就是参与者节点。那么有如下三种可能：
* DT log中包含一个commit(或abort)记录。那么说明在发生故障之前，参与者已经达成了决定。
* DT log中没有yes记录。那么要么是参与者是在投票前发生的故障，要么投的是No(但是在发生故障前还没有完成abort记录的写入)。(这也是为何yes记录必须要在发送YES消息前写入日志的原因；参考上面的第2点。)因此，它可以单方面地通过向DT log中写入一条abort记录决定进行Abort。
* DT log中包含了yes记录，但是没有commit(或abort)记录。那么说明参与者是在不确定区间内发生的故障。它可以通过使用terminaion protocol来达成决定。回想一下，yes记录中包含了协调者名称以及所有的参与者，这正是terminaion protocol所需要的。
整理自
http://duanple.blog.163.com/blog/static/70971767201311810939564
http://research.microsoft.com/en-us/people/philbe/chapter7.pdf