分布式事务一致性：二阶段提交协议（2PC）

版权声明：转载请注明出处。 https://blog.csdn.net/Yeomer/article/details/85319473

分布式系统开发不可避免会遇到分布式事务，目前业界都没有彻底解决的方案，只有各种协议（XA、TCC、Paxos、zab等）、衍生的框架（LCN、tcc-transaction等），最近一直在看相关的书籍和资料，想尽量简单的整理下相关内容。先整理个最基础、也是比较重要的、基于XA协议的二阶段提交（2PC）。

“2PC可以说是种算法，也可以说是一种协议。” — —百度百科

一、概念

二阶段提交协议把分布式事务分为两个阶段，1准备阶段，2提交阶段，准备阶段和提交阶段都是事务 管理器发起的（协调者），参与事务的资源（协调者）。

1. 准备阶段： 协调者像参与者发起指令，参与者评估自己的状态，如果参与者评估指令可以完成，则会 写redo或者undo日志（redo日志记录数据修改后的值，以应对数据库修改数据过程中宕机，恢复后可以通过redo日志将缓冲区的修改后的值刷到磁盘上，undo日志记录数据修改前的值，是用来回滚的）。然后锁定资源，执行操作，但不会提交。
2. 提交阶段： 如果每个参与者明确返回准备成功，协调者会向参与者发起提交指令，参与者提交资源变更的事务，释放锁定的资源。如果任何一个参与者明确返回失败， 则协调者向参与者发起中止指令，参与者取消已经变更的事务，执行undo日志，释放锁定的资源。

二、优缺点

优点：

原理简单。

缺点：

二阶段提交协议在准备阶段锁定资源，这是一个重量级的操作，能保证强一致性，但是实现起来复杂，成本较高，不够灵活，更重要的是它有如下几个致命的问题：

1. 阻塞：节点在等待消息时，什么都做不了。
2. 单点故障：协调者宕机，参与者没有协调者指挥，会一直被阻塞。尽管可以通过选举新的协调者替代原有协调者，但还是有其他情况处理不了。
3. 脑裂：协调者发送提交命令，有的参与者接受到并执行了事务，有的没接收到就没执行事务，多个参与者之间产生不一致。

三、总结

正常情况下能保证系统的强一致性，但异常后，需要人工干预，可用性不够好。