两阶段提交协议

两阶段提交协议可以保证数据的强一致性，许多分布式关系型数据管理系统采用此协议来完成分布式事务。

######################################################################################################

当所有参与者都处于init状态时

1. 组织者 尚未发送Vote_Request请求就 宕机:这时所有参与者超时等待进入Abort状态
2. 组织者 只向部分参与者发送Vote_Request请求，这时部分参与者进入abort，部分参与者为ready，ready的参与者会询问其他参与者，最后也变成abort。

以上两种情况，组织者并没有完成向所有组织者发送Vote_Request请求，所以最后参与者都会变成abort

#####################################################################################################

组织者完成向所有参与者发出Vote_Request请求，宕机出现情况：

• 只有组织者宕机，参与者没有宕机：所有参与者都处于ready状态，等待组织者恢复。
• 只有参与者宕机，组织者等待超时，终止表决，向所有参与者发出Global_abort消息。参与者变成abort，事务终止
  
• 组织者宕机和部分参与者都有宕机：其他处于ready的参与者处于ready状态，等待组织者恢复。或者变成abort状态

以上情况为第一阶段尚未结束，组织者已经完成向所有组织者发送Vote_Request请求，但出现了宕机

######################################################################################################

组织者向所有参与者发出Vote_Request请求->并获得所有参与者回复:

组织者尚未发送global消息，宕机：所有参与者都是ready，等待组织者恢复。

组织者发送部分global消息，宕机：部分参与者可以知道最终是commit还是abort。

组织者发送全部global消息，宕机：所有参与者都变成commit或者abort

第二阶段尚未结束,

组织者和参与者从故障中恢复后，怎么做？：

根据日志中记录的状态，采取不同的策略。

对于参与者：init:终止，并通知组织者,ready:询问其他参与者；commit和abort:向协作者重发他的消息

对于组织者：WAIT:重发request，commit和abort:重发一次commit或者abort

总结：

1. 协议的产生就是要包容各种故障
   
2. 两阶段协议分成两个阶段，由组织者推进，
3. 有几个等待状态，在参与者和协作者处于这几个等待状态时，对方都有可能宕机，为了解决故障，增加超时机制，这个时候，自己应该通过超时机制做一些处理：，参与者需要询问其他参与者，是继续等待还是abort或者commit。
4. 当参与者自己处于ready状态时，这时参与者自己第一阶段结束了，如果超时就要询问其他参与者处于什么状态。