分布式事物实现之二阶段提交
什么是二阶段提交事物？
2PC（Two Phase Commitment Protocol）
两阶段提交协议
实现分布式事务的关键就是两阶段提交协议。在此协议中，一个或多个资源管理器的活动均由一个称为事务协调器的单独软件组件来控制。此协议中的五个步骤如下：
• 应用程序调用事务协调器中的提交方法。
• 事务协调器将联络事务中涉及的每个资源管理器，并通知它们准备提交事务（这是第一阶段的开始）。
• 为 了以肯定的方式响应准备阶段，资源管理器必须将自己置于以下状态：确保能在被要求提交事务时提交事务，或在被要求回滚事务时回滚事务。大多数资源管理器会 将包含其计划更改的日记文件（或等效文件）写入持久存储区中。如果资源管理器无法准备事务，它会以一个否定响应来回应事务协调器。
• 事务协调器收集来自资源管理器的所有响应。
• 在 第二阶段，事务协调器将事务的结果通知给每个资源管理器。如果任一资源管理器做出否定响应，则事务协调器会将一个回滚命令发送给事务中涉及的所有资源管理 器。如果资源管理器都做出肯定响应，则事务协调器会指示所有的资源管理器提交事务。一旦通知资源管理器提交，此后的事务就不能失败了。通过以肯定的方式响 应第一阶段，每个资源管理器均已确保，如果以后通知它提交事务，则事务不会失败。
该协议将一个分布式的事务过程拆分成两个阶段：投票阶段和事务提交阶段。
为了让整个数据库集群能够正常的运行，该协议指定了一个“协调者”单 点，用于协调整个数据库集群的运行，为了简化描述，我们将数据库里面的各个节点称为“参与者”，
三阶段提交协议中同样包含“协调者”和“参与者”这两个定 义。
第一阶段：投票阶段
该阶段的主要目的在于打探数据库集群中的各个参与者是否能够正常的执行事务，具体步骤如下：
-
协调者向所有的参与者发送事务执行请求，并等待参与者反馈事务执行结果。
-
事务参与者收到请求之后，执行事务，但不提交，并记录事务日志。
-
参与者将自己事务执行情况反馈给协调者，同时阻塞等待协调者的后续指令。
第二阶段：事务提交阶段
在第一阶段协调者的询盘之后，各个参与者会回复自己事务的执行情况，这时候存在三种可能：
-
所有的参与者回复能够正常执行事务
-
一个或多个参与者回复事务执行失败
-
协调者等待超时
对于第一种情况，协调者将向所有的参与者发出提交事务的通知，具体步骤如下：
-
协调者向各个参与者发送commit通知，请求提交事务。
-
参与者收到事务提交通知之后，执行commit操作，然后释放占有的资源。
-
参与者向协调者返回事务commit结果信息。
对于第二、三种情况，协调者均认为参与者无法正常成功执行事务，为了整个集群数据的一致性，所以要向各个参与者发送事务回滚通知，具体步骤如下：
-
协调者向各个参与者发送事务rollback通知，请求回滚事务。
-
参与者收到事务回滚通知之后，执行rollback操作，然后释放占有的资源。
-
参与者向协调者返回事务rollback结果信息。
两阶段提交协议解决的是分布式数据库数据强一致性问题，其原理简单，易于实现，但是缺点也是显而易见的，主要缺点如下：
-
单点问题
协调者在整个两阶段提交过程中扮演着举足轻重的作用，一旦协调者所在服务器宕机，那么就会影响整个数据库集群的正常运行，比如在第二阶段中，如果协调者因为故障不能正常发送事务提交或回滚通知，那么参与者们将一直处于阻塞状态，整个数据库集群将无法提供服务。 -
同步阻塞
两阶段提交执行过程中，所有的参与者都需要听从协调者的统一调度，期间处于阻塞状态而不能从事其他操作，这样效率及其低下。 -
数据不一致性
两阶段提交协议虽然为分布式数据强一致性所设计，但仍然存在数据不一致性的可能，比如在第二阶段中，假设协调者发出了 事务commit的通知，但是因为网络问题该通知仅被一部分参与者所收到并执行了commit操作，其余的参与者则因为没有收到通知一直处于阻塞状态，这 时候就产生了数据的不一致性。
