知识贴：分布式事务的两阶段提交协议(2PC)

Posted 2021-04-25 我们全都爱学习

两阶段提交协议

两阶段提交协议(2PC：Two-Phrase Commit)的目标是在分布式系统中保证数据的一致性；顾名思义，该协议将一个分布式系统的事务过程拆分成两个阶段：投票阶段和事务提交阶段。

该协议定义两类成员：

1. 一个协调者，用于协调整个分布式事务运行。

   有些系统把它叫做事务管理器TM(Transaction Manager)。

2. 多个参与者，分布式系统的各个具体参与节点。

   有些系统把它叫做资源管理器RM(Resource Manager)。

第一阶段：投票阶段

该阶段的主要目的是确定分布式系统的各个参与者是否能够正常的执行事务，包括如下步骤：

1. 协调者向所有参与者发送事务执行请求，并等待事务执行结果。
   

2. 参与者收到请求之后，执行事务，记录事务日志，但不提交。

3. 参与者将执行情况反馈给协调者，同时阻塞等待协调者的后续指令。

 

第二阶段：事务提交阶段

协调者等待参与者的执行结果，会有三种情况：

1. 所有的参与者回复能够正常执行事务。
   

2. 一个或多个参与者回复事务执行失败。

3. 协调者等待超时。

• 对于第一种情况，协调者将向所有的参与者发出提交事务的请求：

1. 协调者向各个参与者发送事务提交(commit)请求。
   

2. 参与者收到事务提交通知之后，执行提交操作，然后释放占有的资源。

3. 参与者向协调者返回事务提交结果信息。

• 对于第二种情况，协调者将向所有的参与者发出回滚事务的请求：

1. 协调者向各个参与者发送事务回滚(rollback)请求。

2. 参与者收到事务回滚通知之后，执行回滚操作，然后释放占有的资源。

3. 参与者向协调者返回事务回滚结果信息。

• 对于第三种情况，和第二种情况一样处理，即回滚事务。

两阶段提交协议的优点是：原理简单，易于实现；但缺点也有：

• 单点问题

  协调者的单点问题，协调者在整个两阶段提交过程中扮演着举足轻重的作用，一旦协调者所在服务器宕机，那么就会影响整个数据库集群的正常运行，比如在第二阶段中，如果协调者因为故障不能正常发送事务提交或回滚通知，那么参与者们将一直处于阻塞状态，整个数据库集群将无法提供服务。

• 同步阻塞

  两阶段提交执行过程中，所有的参与者都需要听从协调者的统一调度，期间处于阻塞状态而不能从事其他操作，这样效率及其低下。

• 数据不一致性

  两阶段提交协议是为分布式数据强一致性所设计，在一般情况下都能较好的运行，即使有参与者宕机时，重启以后，可以通过询问其他参与者或者协调者，从而知道一个事务的最终状态，是提交了还是回滚了(当然，这一切的前提都是各个参与者在进行每一步操作时，都会事先写入日志)；但是仍然存在数据不一致性的可能，比如在第二阶段中，假设协调者发出了事务提交的请求，但是因为网络问题该通知仅被一部分参与者所收到并执行了提交操作，其余的参与者则因为没有收到通知一直处于阻塞状态，这时候就产生了数据的不一致性。因为此时这个事务就处于一个未知的状态，没有人知道这个事务到底是提交了还是未提交，从而需要数据库管理员的人工介入，防止数据库进入一个不一致的状态。当然，如果所有节点或者网络的异常最终都会恢复，那么这个问题就不存在了，协调者和参与者最终会重启，其他节点也最终会收到提交的信息。这也符合CAP理论。

三阶段提交协议

三阶段提交协议(3PC：Three-Phrase Commit)是针对两阶段提交协议中存在的问题而提出的：三阶段提交协议通过引入一个“预询盘”阶段，以及超时策略来减少整个集群的阻塞时间，提升系统性能。三阶段提交协议的三个阶段分别为：cancommit，precommit，docommit。

第一阶段：cancommit

协调者去询问各个参与者是否能够正常执行事务，参与者根据自身情况回复，但并不真正的执行事务。

第二阶段：precommit

协调者向所有参与者发送事务执行请求，参与者执行事务，并记录日志，但不提交事务。

第三阶段：docommit

协调者向所有参与者发送事务提交请求，参与者提交事务，并返回提交结果。

三阶段提交协议理论上是为了解决两阶段的问题，但实际上也不能完全解决，而且引入了三次交换，复杂化了提交过程，所以在真实系统中很少被采用。