《从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）保守。

                   参与者出现故障，协调者无法获得所有参与者的响应信息的时候，参与者只能靠超时机制判断是否需要中断事务。没有完善的容错机制，任意一个节点失败都会导致整个事务的失败。