讨论
2PC/3PC并不是严格意义上的一致性协议，很少被用在处理一致性上；但另一方面又经常看到2PC/3PC和分布式事务放在一起讨论，并且大部分的关系型数据库通过两阶段提交（2 Phase Commit 2PC）算法来完成分布式事务。
先大致了解一下分布式事务和一致性
分布式事务
分布式事务：是指会涉及到操作多个数据库的事务。其实就是将对同一库事务的概念扩大到了对多个库的事务。目的是为了保证分布式系统中的数据一致性。分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作，提交或回滚事务的决定必须产生统一的结果（全部提交或全部回滚）。
两类一致性
说到一致性大家更多的应该想到的是CAP里面的C表示的一致性(一个数据分片的多个副本之间的数据一致性)就是数据一致性；但我觉得还可以有另外一种理解就是ACID中的C(一个事务在执行之前和执行之后，数据库都必须处于一致性状态)就是状态一致性或者叫操作原子性。
其实这里说的状态一致性或者叫操作原子性就是分布式事务，大范围来讲，其实一致性其实是包含分布式事务的，只不过我们提到一致性更多情况下讲的就是数据一致性。
2PC/3PC由来：XA规范
X/Open 组织（即现在的 Open Group ）定义了分布式事务处理模型。 X/Open DTP 模型（ 1994 ）包括应用程序（ AP ）、事务管理器（ TM ）、资源管理器（ RM ）、通信资源管理器（ CRM ）四部分。一般，常见的事务管理器（ TM ）是交易中间件，常见的资源管理器（ RM ）是数据库，常见的通信资源管理器（ CRM ）是消息中间件。
XA 就是 X/Open DTP 定义的交易中间件与数据库之间的接口规范（即接口函数），交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。 XA 接口函数由数据库厂商提供。
二阶提交协议和三阶提交协议就是根据这一思想衍生出来的。可以说二阶段提交其实就是实现XA分布式事务的关键(确切地说：两阶段提交主要保证了分布式事务的原子性：即所有结点要么全做要么全不做)。
所以大部分的关系型数据库通过两阶段提交（2 Phase Commit 2PC）算法来完成分布式事务就不足为奇了。
讨论总结
2PC/3PC提交其实就是实现XA分布式事务的关键，而分布式事务从广义上来讲也是一致性的一种表现，所以2PC/3PC也可以叫一致性协议；其实在表示数据一致性的环境下，2PC/3PC代表的含义：要么所有备份数据同时更改某个值，要么都不更改，以此来达到数据的强一致性。在真实的应用中，尽管有系统使用2PC/3PC协议来作为数据一致性协议，但是比较少见，更多的是作为实现数据更新原子性手段出现。
为什么2PC/3PC没有被广泛用在保证数据的一致性上，主要原因应该还是它本身的缺陷，所有经常看到这句话：there is only one consensus protocol, and that’s Paxos” – all other approaches are just broken versions of Paxos. 意即世上只有一种一致性算法，那就是Paxos。
下面大概介绍一下2PC/3PC
2PC/3PC
2PC/3PC全称:Two/Three Phase Commit,中文名叫叫两阶段/三阶段提交；为了使基于分布式系统架构下的所有节点在进行事务处理的过程中能够ACID特性而设计的一种算法，需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交。两阶段提交的算法如下：
第一阶段：提交事务阶段(投票阶段)
1.事务询问：协调者会问所有的参与者结点，是否可以执行提交操作
2.执行事务：各个参与者执行事务操作 如：资源上锁，将Undo和Redo信息记入事务日志中
3.参与者向协调者反馈事务询问的响应：如果参与者成功执行了事务操作，反馈给协调者Yes响应，否则No响应
第二阶段：执行事务提交(执行阶段)
假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务提交
1.发送提交请求：协调者向参与者发送Commit请求
2.事务提交：参与者接受到Commit请求后，会正式执行事务提交操作，并在完成提交之后释放事务资源
3.反馈事务提交结果：参与者在完成事务提交之后，向协调者发送Ack消息
4.完成事务：协调者接受到所有参与者反馈的Ack消息后，完成事务
假如任何一个参与者向协调者反馈了No响应，或者在等待超时之后，协调者尚无接收到所有参与者的反馈信息，那么就会中断事务
1.发送回滚请求：协调者向参与者发送Rollback请求
2.事务回滚：参与者利用Undo信息来执行事务回滚，并释放事务资源
3.反馈事务回滚结果：参与者在完成事务回滚之后，向协调者发送Ack消息
4.中断事务：协调者接收到所有参与者反馈的Ack消息之后，中断事务
网上看来的西方教堂结婚一个桥段很好的描述了2PC协议：
1.牧师分别问新郎和新娘：你是否愿意……不管生老病死……（投票阶段）
2.当新郎和新娘都回答愿意后（锁定一生的资源），牧师就会说：我宣布你们……（执行阶段）
2PC存在的问题
1.阻塞问题
二阶段提交的第一阶段中，协调者需要等待参与者的响应，如果没有接收到任意参与者的响应，这时候进入等待状态，而其他正常发送响应的参与者，将进入阻塞状态，将无法进行其他任何操作，只有等待超时中断事务，极大的限制了系统的性能。
2.单点问题
协调者处于一个中心的位置，一旦出现问题，那么整个二阶段提交将无法运转，更为严重的是，如果协调者在阶段二中出现问题的话，那么其他参与者将会一直处于锁定事务资源的状态中，将无法继续完成操作
以上提到的2个问题都在3PC中得到了解决
1.解决阻塞问题：将2PC中的第一阶段一分为二，提供了一个CanCommit阶段，此阶段并不锁定资源，这样可以大幅降低了阻塞概率
2.解决单点问题：在参与者这边也引入了超时机制
3PC
3PC是2PC的改进版本，将2PC的第一阶段：提交事务阶段一分为二，形成了CanCommit、PreCommit和doCommit三个阶段组成的事务处理协议，具体看一张流程图(来源网上)：
三段提交的核心理念是：在询问的时候并不锁定资源，除非所有人都同意了，才开始锁资源。
3PC具体的流程步骤就不在描述了，在二阶段的基础上加了事务询问的过程(CanCommit)
3PC虽然解决了2PC存在的2个问题，但是不管是2PC还是3PC都存在数据一致性的问题：
2PC：比如协调者在只给部分参与者发送了Commit请求，那就会出现部分参与者执行了Commit，部分没有提交，出现不一致问题。
3PC：一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态，但是这种机制也会导致数据一致性问题。
总结
2PC/3PC用来处理分布式事务： 能够很好的提供强一致性和强事务性，但相对来说延迟比较高，比较适合传统的单体应用，在同一个方法中存在跨库操作的情况，不适合高并发和高性能要求的场景。
2PC/3PC用来处理数据一致性：很少使用，更多的是Paxos或者基于Paxos的变体。