集中式与分布式事务的一个重要的不同点在于它们各自所需关注的错误的属性上。
在集中式系统中，错误都是要么不错要么全错(all-or-nothing)，也就是说要么系统正常工作事务正常处理，要么系统出错不会有不论什么事务完毕。
可是在分布式系统中，可能出现部分失败(partial failures)的情况，某些节点正常工作可是其它一些节点出错了。
这种局部失败的情况正是造成分布式系统中非常多难解的问题的根源。
在事务处理中就有这种一个难解问题，即分布式事务的一致性问题。
比方T就可能在某些节点上进行了Commit，而在某些节点上进行了Abort，这样就产生了不一致。
两阶段提交(Two-phase Commit/2PC)就是为了使基于分布式系统架构下的全部节点在进行事务提交时保持一致性而设计的一种算法(Algorithm)。
在分布式系统中，每一个节点尽管能够知晓自己的操作时成功或者失败。却无法知道其它节点的操作的成功或失败。所以当一个事务跨越多个节点时，须要引入一个作为协调者的组件来统一掌控全部节点(称作參与者)的操作结果并终于指示这些节点是否要把操作结果进行真正的提交(比方将更新后的数据写入磁盘等等)。
因此，两阶段提交的算法思路能够概括为： 參与者将操作成败通知协调者，再由协调者依据全部參与者的反馈情报决定各參与者是否要提交操作还是中止操作。
2PC的两个阶段是指投票阶段和决定阶段：
第一阶段(提交请求阶段/投票阶段)
协调者节点向全部參与者节点询问能否够运行提交操作，并開始等待各參与者节点的响应。
參与者节点运行询问发起为止的全部事务操作，并将Undo信息和Redo信息写入日志。
各參与者节点响应协调者节点发起的询问。
假设參与者节点的事务操作实际运行成功，则它返回一个”允许”消息。假设參与者节点的事务操作实际运行失败。则它返回一个”中止”消息。
简单地说，就是各參与者投票是否要继续接下来的提交操作。
第二阶段(提交运行阶段/决定阶段)：
1）成功
当协调者节点从全部參与者节点获得的对应消息都为”允许”时：
协调者节点向全部參与者节点发出”正式提交”的请求。
參与者节点正式完毕操作。并释放在整个事务期间内占用的资源。
參与者节点向协调者节点发送”完毕”消息。
协调者节点受到全部參与者节点反馈的”完毕”消息后，完毕事务。
2）失败
假设任一參与者节点在第一阶段返回的响应消息为”终止”，或者协调者节点在第一阶段的询问超时之前无法获取全部參与者节点的响应消息时：
协调者节点向全部參与者节点发出”回滚操作”的请求。
參与者节点利用之前写入的Undo信息运行回滚。并释放在整个事务期间内占用的资源。
參与者节点向协调者节点发送”回滚完毕”消息。
协调者节点受到全部參与者节点反馈的”回滚完毕”消息后，取消事务。
请注意，在失败情况下有一种情况为超时，由于消息可能会由于故障而无法到达。因此，进程可能会无限等待下去。为避免这个问题，须要使用超时机制。
还是来举个现实生活中的样例吧：
你是个大吃货。发现了聚餐的好地方。想叫上好基友们去尝鲜。于是，你给他们群发短信：“各位亲，我发了个好地儿。如今出来聚聚吧，地址是XXXXXX”。收到信息的小伙伴们，就寻路过去了，边走边记回去的路（写日志）。到了的发短信给你“我到啦”。还有找了半天没找地的小伙伴发短信给你“我没找到地，就不去啦”（投票阶段）
你假设收到全部小伙伴到了的信息。又发信息给他们“我订了紫兰厅，你们去吧”，小伙伴们把车停好（释放资源），来到紫兰厅，又给你发信息“我来啦”，你看大家到齐了。乖乖点菜去了。
假设，你收到了有人不能来的短信，或者有人一个小时都没回短信（关机或者电信故障什么的）。你决定取消这次聚餐。发短信给大家说“小伙伴们，有人不能来啦，你们回去吧”。
于是，大家顺着记的路回家了（回滚），回到家后。把车停好（释放资源），发短信给你“我到啦”。你收到大家的短信，恩。你能够睡觉去了。
总结：
2PC是分布式情况下强一致性算法
协调者发生问题。协调者须要将事务相关信息记录到操作日志并同步到备用协调者，假如协调者发生问题，备用协调者能够接替它完毕兴许的工作。假设没有备用协调者。协调者又发生了永久性故障，事务參与者将无法完毕事务而一直等待下去。
该算法吞吐量较低，两阶段提交协议是堵塞协议，运行过程中须要锁住其它更新，且不能容错，大多数分布式存储系统都採用敬而远之的做法。放弃对分布式事务的支持。