两阶段提交协议
- 两阶段提交协议把分布式事务分为两个阶段，一个是准备阶段，另一个是提交阶段；
- 准备阶段和提交阶段都是由事务管理器发起的；
- 我们可以将事务管理器称为协调者，将资源管理器称为参与者。
流程
准备阶段：
协调者向参与者发起指令，参与者评估自己的状态，如果参与者评估指令可以完成，则会写redo或者undo日志（Write-Ahead Log的一种），然后锁定资源，执行操作，但是并不提交。
提交阶段：
- 如果每个参与者明确返回准备成功，也就是预留资源和执行操作成功，则协调者向参与者发起提交指令，参与者提交资源变更的事务，释放锁定的资源；
- 如果任何一个参与者明确返回准备失败，也就是预留资源或者执行操作失败，则协调者向参与者发起中止指令，参与者取消已经变更的事务，执行undo日志，释放锁定的资源。
存在问题
两阶段提交协议在准备阶段锁定资源，这是一个非常损耗资源的操作，能保证强一致性，但是实现起来复杂、成本较高、不够灵活，更重要的是它有一些致命的问题
阻塞：
从上面的描述来看，对于任何一次指令都必须收到明确的响应，才会继续进行下一步，否则处于阻塞状态，占用的资源被一直锁定，不会被释放。
单点故障：
如果协调者宕机，参与者没有协调者指挥，则会一直阻塞，尽管可以通过选举新的协调者替代原有协调者，但是如果协调者在发送一个提交指令后宕机，而提交指令仅仅被一个参与者接收，并且参与者接收后也宕机，则新上任的协调者无法处理这种情况。
脑裂：
协调者发送提交指令，有的参与者接收到并执行了事务，有的参与者没有接收到事务就没有执行事务，多个参与者之间是不一致的。
数据状态不确定
协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。
小结
上面的问题发生的概论比较小，但都需要人工干预处理，没有自动化的解决方案，因此两阶段提交协议在正常情况下能保证系统的强一致性，但是在出现异常的情况下，当前处理的操作处于错误状态，需要人工干预解决，因此可用性不够好。
