介绍
首先用一张图说明2PC所处的背景知识
- 左边的图表明在同一台机器上，几个进程要完成一个事务，由于在同一台机器上共享内存，只有进程间的同步互斥操作，不存在消息的传递。
- 中间的图表明客户端进程要完成一个事务（多个客户端之间也有自己要完成的并发事务），但是事务（Lock）的管理由一台服务器管理，这里只存在客户端和锁服务之间的消息传递，不存在锁服务器之间的一致。
- 中间的情况必然存在Lock服务器的不安全性，因此需要backup机器，而多个机器之间需要相互同步（当然不理解成备份机，理解成一个事务就是要跨server执行也是可以的）。这种情况下就需要用到分布式环境下的事务提交协议或者consensus协议。
在事务进行过程中，除了参与者在加入分布式事务时通知协调者之外，协调者和参与者之间没有其他通信。客户的事务提交（或放弃）请求直接发送给协调者。如果客户请求abortTransaction，或者事务已经被某个参与者放弃，那么协调者可以立即通知所有参与者放弃事务。只有当客户请求协调者提交事务时，两阶段提交协议才开始使用。
维基百科的解释：
为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法。通常，二阶段提交也被称为是一种协议(Protocol)。在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的[ACID]特性，需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。因此，二阶段提交的算法思路可以概括为： 参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。
因此两阶段提交协议也可以认为是一种consensus问题的解决方式
角色：
- 客户端：请求发起事务的一方
- 协调者：决定事务能够commit或者abort的中间节点，顾名思义，协调其他参与者的情况
- 参与者：参与客户端提交的决议（对为什么要有多参与者，我觉得有以下两种场景可以理解：1 为了保证系统可靠，需要有replication，因此各个备份节点如何达成一致？ 2 典型的银行事务。一个账号给另一个账号汇钱，但是这两个账号不在同一台机器，不同的机器就是不同的参与者）
算法
算法假设
- 该分布式系统中，存在一个节点作为协调者(Coordinator)，其他节点作为参与者(Cohorts)。且节点之间可以进行网络通信。
- 所有节点都采用预写式日志，且日志被写入后即被保持在可靠的存储设备上，即使节点损坏不会导致日志数据的消失。
- 所有节点不会永久性损坏，即使损坏后仍然可以恢复。
算法描述
第一阶段：
- 协调者节点向所有参与者节点询问是否可以执行提交操作，并开始等待各参与者节点的响应。
- 参与者节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。
- 各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功，则它返回一个"同意"消息；如果参与者节点的事务操作实际执行失败，则它返回一个"中止"消息。
第二阶段：
成功，当协调者节点从所有参与者节点获得的相应消息都为"同意"时： - 协调者节点向所有参与者节点发出"正式提交"的请求。
- 参与者节点正式完成操作，并释放在整个事务期间内占用的资源。
- 参与者节点向协调者节点发送"完成"消息。
- 协调者节点收到所有参与者节点反馈的"完成"消息后，完成事务。
失败，如果任一参与者节点在第一阶段返回的响应消息为"终止"，或者 协调者节点在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时： - 协调者节点向所有参与者节点发出"回滚操作"的请求。
- 参与者节点利用之前写入的Undo信息执行回滚，并释放在整个事务期间内占用的资源。
- 参与者节点向协调者节点发送"回滚完成"消息。
- 协调者节点收到所有参与者节点反馈的"回滚完成"消息后，取消事务。
存在的缺陷
在分布式系统的设计里面，一致性和可用性往往存在矛盾，如果要求所有的机器都要完成一件事情才能认为完成，那么这样的系统必然存在可用性的问题。假设当一台机器发生crash或者消息不能够及时传递，就会导致整个系统阻塞。2PC就是一种典型的阻塞式协议（在除第一个极端的每一个通信阶段都会有阻塞的情况发生），解决阻塞的最好办法就是引入超时机制。
- 阶段1中协调者要等待所有的参与者反馈，此时如果有参与者没有反馈（消息丢失，网络分区，进程crash），则协调者将一直等待下去。加入超时判断时候，一定时间内没有收集齐则发送消息认定操作失败，全局广播取消事务。
- 协调者无法服务，这个时候参与者有两种情况。此时参与者会一直阻塞，等待协调者回复。此时解决办法通常都是重新选举一个协调者。
- 现在重新考虑协调者无法服务（协调者crash，网络分区），如果是第二阶段，协调者已经发出表决之后的决定（commit or abort）之后发生错误，此时参与者可以询问其他参与者Q来决定自己的状态：1. 如果Q已经commit，则自己可以放心commit。 2. 如果Q已经abort，则自己可以放心aboirt。 3. 如果Q处于INIT状态（就是阶段1刚开始的情况），此时表明协调者在阶段1发送投票请求的时候crash或者是协调者和Q之间存在通信故障，则此时可以说明协调者不可能commit，则自己可以放心标记为abort即可。 4. 如果Q与自己状态相同，则需要询问其他参与者。
- 另外我们发现如果出现网络分区，可能会出现脑裂现象，此时无法确定谁才是真正的协调者。
下图是《大数据日知录》提供的2PC有限状态机
正因为2PC存在问题，所以之后有3PC和Paxos的方式
感觉分布式事务也可以理解成广义的consensus问题，其实就是多个机器要完成一件All or noting的事情，多个机器的状态必然是要同步的。
