2PC&3PC
在分布式系统中，每一个机器节点虽然都能够明确地知道自己在进行实物操作过程中的结果是成功或失败，但却无法直接获取到其他分布式节点的操作结果。为了保持实物处理的ACID特性，就需要引入一个称为“协调者（Coordinator）”的组件来统一调度所有分布式节点的执行逻辑，这些被调度的分布式节点则被称为“参与者（Participant）”。协调者负责调度参与者的行为，并最终决定这些参与者是否要把事务真正进行提交。
2PC（Two-Phase Commit）
二阶段提交，是一种一致性协议，用来保证分布式系统数据的一致性。绝大多数的关系型数据库都是采用二阶段提交协议来完成分布式事务处理的，利用该协议能够非常方便地完成所有分布式事务参与者的协调，统一决定事务的提交或回滚，从而能够有效的保证分布式数据一致性。
阶段一：提交事务请求
事务询问
协调者向所有参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
执行事务
各参与者结点执行事务操作，并将Undo和Redo信息记入事务日志中。
各参与者向协调者反馈事务询问的响应
如果参与者成功执行了事务操作，那么就反馈给协调者Yes响应，表示事务可以执行；如果参与者没有成功执行事务，那么就反馈给协调者No响应，表示事务不可以执行。
由于上面讲述的内容在形式上近似是协调者组织各参与者对一次事务曹组的投票表态过程，因此二阶段提交协议的阶段一也被称为“投票阶段”，即各参与者投票表明是否要继续执行接下去的事务提交操作。
阶段二：执行事务提交
可能一：执行事务提交
假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务提交。
1. 发送提交请求
协调者向所有参与者节点发出Commit请求
2. 事务提交
参与者接收到Commit请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占用的事务资源。
3. 反馈事务提交结果
参与者在完成事务提交之后，向协调者发送Ack消息
4. 完成事务
协调者接收到所有参与者反馈的Ack消息后，完成事务
可能二：中断事务
假如任何一个参与者向协调者反馈了No响应，或者在等待超时之后，协调者尚无法接收到所有参与者的反馈响应，那么就会中断事务。
1. 发送回滚请求
协调者向所有参与者节点发出Rollback请求
2. 事务回滚
参与者接收到Rollback请求后，会利用其再阶段一中记录的Undo信息执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源。
3. 反馈事务回滚结果
参与者在完成事务回滚之后，向协调者发送Ack消息
4. 中断事务
协调者接收到所有参与者反馈的Ack消息后，完成事务中断
简单地讲，二阶段提交讲一个事务的处理过程分成了投票和执行两个阶段，其核心是对每个事务都采用先尝试后提交的处理方式。
优缺点
二阶段提交协议的优点：原理简单、实现方便
二阶段提交协议的缺点：同步阻塞、单点问题、脑裂、太过保守
同步阻塞
执行过程中，所有参与该事务操作的逻辑都处于阻塞状态，也就是说，各个参与者在等待其他参与者响应的过程中，将无法进行其他任何操作。
单点问题
协调者的角色在整个二阶段提交协议中起到了非常重要的作用。一旦协调者出现问题，那么整个二阶段提交流程无法运转，更为严重的是，如果协调者是在阶段二中出现问题的话，那么其他参与者将会一直处于锁定事务资源的状态中，而无法继续完成事务操作。
数据不一致
在二阶段提交协议的阶段二，即执行事务提交的时候，当协调者向所有的参与者发送Commit请求之后，发生了局部网络异常或者是协调者在尚未发送完Commit请求之前自身发生了崩溃，导师最终只有部分参与者收到了Commit请求，于是，这部分收到了Commit请求的参与者就会进行事务的提交，而其他没有收到Commit请求的参与者则无法进行事务提交，于是整个分布式系统便出现了数据不一致性现象。
太过保守
二阶段提交协议没有涉及较为完善的容错机制，任意一个节点的失败都会导致整个事务的失败。
二阶段无法解决的问题：协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。
3PC（Three-Phase Commit）
三阶段提交，是2PC的改进版，其将二阶段提交协议的“提交事务请求”过程一分为二，形成了由CanCommit、PreCommit和DoCommit三个阶段组成的视乎处理协议。
三个阶段
阶段一：CanCommit
事务询问
协调者向所有的参与者发送一个包含事务内容的CanCommit请求，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
各参与者向协调者反馈事务询问的响应
参与者在接收到来自协调者的CanCommit请求后，正常情况下，如果其自身认为可以顺利执行事务，那么会反馈Yes响应，并进入准备状态，否则反馈No响应。
阶段二：PreCommit
在阶段二中，协调者会根据各参与者的反馈情况来决定是否可以进行事务的PreCommit操作，正常情况下，包含两种可能：
执行事务预提交
假如协调者从所有参与者获得的反馈都是Yes响应，那么就会执行事务预提交
发送预提交请求
协调者向所有参与者节点发出PreCommit的请求，并进入Prepared阶段。
事务预提交
参与者接收到PreCommit请求后，会执行事务操作，并将Undo和Redo信息记录到事务日志中
各参与者向协调者反馈事务执行的响应
如果参与者成功执行了事务操作，那么就会反馈给协调者Ack响应，同时等待最终的指令：提交（commit）或终止（abort）
中断事务
假如任何一个参与者向协调者反馈了No响应，或者在等待超市之后，协调者尚无法接受所有参与者的反馈响应，那么就会中断事务。
发送中断请求
协调者向所有参与者节点发出abort请求
中断事务
无论是收到来自协调者的abort请求，或者是在等待协调者请求过程中超时，参与者都会中断事务。
阶段三：DoCommit
该阶段将进行真正的事务提交，会存在以下两种情况：
提交阶段
1. 发送提交请求
2. 事务提交
3. 反馈事务提交结果
4. 完成事务
中断事务
进入这一阶段，假设协调者处于正常工作状态，并且有任意一个参与者向协调者反馈了No响应，或者在等待超时之后，协调者尚无法接收到所有参与者的反馈响应，那么就会中断事务
1. 发送中断请求
2. 事务回滚
3. 反馈事务回滚结果
4. 中断事务
需要注意的是，一旦进入阶段三，可能会存在以下两种故障：
- 协调者出现问题
- 协调者和参与者之间的网络出现故障
无论出现哪种情况，最终都会导致参与者无法及时接收到来自协调者的DoCommit或者abort请求，针对这样的异常情况，参与者都会在等待超时之后，继续进行事务提交。
三阶段提交协议优缺点
优点：相较于二阶段提交协议，三阶段提交协议最大的优点就是降低了参与者的阻塞范围，并且能够在出现单点故障后继续达成一致。
缺点：
在参与者接收到PreCommit消息后，如果网络出现分区，此时协调者所在的节点和参与者无法进行正常的网络通信，在这种情况下，该参与者依然会进行事务的提交，这必然出现数据的不一致性。
在doCommit阶段，如果参与者无法及时接收到来自协调者的doCommit或者rebort请求时，会在等待超时之后，会继续进行事务的提交。所以，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。
相对于2PC，3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，因为，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。
当协调者和参与者都挂的时候：
第二阶段协调者和参与者挂了，挂了的这个参与者在挂之前已经执行了操作。但是由于他挂了，没有人知道他执行了什么操作。
- 这种情况下，当新的协调者被选出来之后，他同样是询问所有的参与者的情况来觉得是commit还是roolback。这看上去和二阶段提交一样啊？他是怎么解决一致性问题的呢？
- 看上去和二阶段提交的那种数据不一致的情况的现象是一样的，但仔细分析所有参与者的状态的话就会发现其实并不一样。我们假设挂掉的那台参与者执行的操作是commit。那么其他没挂的操作者的状态应该是什么？他们的状态要么是prepare-commit要么是commit。因为3PC的第三阶段一旦有机器执行了commit，那必然第一阶段大家都是同意commit。所以，这时，新选举出来的协调者一旦发现未挂掉的参与者中有人处于commit状态或者是prepare-commit的话，那就执行commit操作。否则就执行rollback操作。这样挂掉的参与者恢复之后就能和其他机器保持数据一致性了。（为了简单的让大家理解，笔者这里简化了新选举出来的协调者执行操作的具体细节，真实情况比我描述的要复杂）
简单概括一下就是，如果挂掉的那台机器已经执行了commit，那么协调者可以从所有未挂掉的参与者的状态中分析出来，并执行commit。如果挂掉的那个参与者执行了rollback，那么协调者和其他的参与者执行的肯定也是rollback操作。
所以，再多引入一个阶段之后，3PC解决了2PC中存在的那种由于协调者和参与者同时挂掉有可能导致的数据一致性问题。
