本文主要是介绍《从Paxos到ZooKeeper》读书笔记--两阶段提交 2PC，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
两种角色：参与者（Participant）： 被调度的分布式节点
协调者（Coordinator）：同意调度所有分布式节点的执行逻辑，并最终决定参与者是否把事务真正进行提交。
一、两个阶段
2PC就是把事务的提交郭晨共分为两个阶段进行处理
（1）提交事务请求
也成为“投票阶段”， 即各参与者投票标明是否要继续执行接下去的事务提交操作。
（i） 协调者向参与者发送事务内容，询问是否可以提交并等待各参与者响应
（ii）执行事务：参与者执行操作写日志（包括undo redo等）
（iii）各参与者想协调者返回事务询问的响应。 （参与者成功执行事务操作）？Yes:No
（2）执行事务提交
（i）发送提交请求：协调者向所有参与者发送commit请求
（ii）参与者收到commit请求，会执行事务提交。提交后，释放事务资源
（iii）参与者向协调者返回事务提交结果（Ack消息）
（iv）完成事务:协调者收到所有参与者反馈的Ack消息后，完成事务。
二、中断事务
任何一个参与者向协调者发送了No响应，或者在等待超时之后，协调者无法收到所有参与者对的反馈响应，就会中断事务
（1）协调者向所有参与者发送回滚请求
（2）事务回滚：利用undo日志信息，回滚完之后释放执行事务期间占用的资源
（3）中断事务：协调者收到所有参与者反馈的Ack，完成事务中断
三、缺点
（1）同步阻塞
所有参与该事物操作的逻辑都出于阻塞状态：各个参与者等待其他参与者响应过程中，无法进行其他操作
（2）单点问题
协调者出现问题后果严重。 如果是阶段二出现问题，其他参与者会一直处于锁定事务资源的状态，无法继续完成事务。
（3）数据不一致
如果协调者发送Commit请求，但是发生局部网络异常或者协调者未发完就出现故障，导致最终只有部分参与者收到Commit并提交，于是分布式系统数据不一致
（4）保守。
参与者出现故障，协调者无法获得所有参与者的响应信息的时候，参与者只能靠超时机制判断是否需要中断事务。没有完善的容错机制，任意一个节点失败都会导致整个事务的失败。
这篇关于《从Paxos到ZooKeeper》读书笔记--两阶段提交 2PC的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
