分布式事务：2PC、3PC协议

两阶段提交协议-2PC

两阶段提交协议(2PC)：是一种原子承诺协议，一种分布式算法，它协调参与分布式事务的所有应用（进程）是否提交或终止（回滚）事务，

2PC基本算法

• 阶段一：提交事务询问请求（或投票）阶段

  1. 事务协调者（TM）向所有参与该事务的进程发送事务内容，询问是否可以执行该事务的提交，并等待所有AP的响应
  2. 每个AP节点执行事务操作，将undo和redo信息记录到事务日志中，尽量把提交过程中所消耗时间的操作和准备都提前完成后确保后续事务提交的成功率（undo log-回滚日志，redo log-重做日志）
  3. 每个AP向TM回复协议消息（投票），如果AP执行成功则投票赞成，如果AP回复协议消息失败或者出现无法预知的错误则投票不赞成

  

• 阶段二：提交事务阶段

  • 阶段一成功执行事务：协调者（TM）在提交事务请求阶段收到来自所有AP的协议消息
    1. TM向所有AP发送事务提交消息
    2. 每个AP执行事务操作，并释放事务期间所有持有的锁和资源
    3. 每个AP向TM发送事务确认的协议消息
    4. TM收到所有AP的确认消息完成本次事务
  • 阶段一失败中断事务：任何AP投票否或者TM超时
    1. TM向所有AP发送事务回滚消息
    2. 每个AP根据回滚日志（undo log）撤销事务，并释放事务期间所有持有的锁和资源
    3. 每个AP向TM发送确认消息
    4. TM收到所有的确认消息后撤销该事务
       

2PC的缺点

1. 同步堵塞：两阶段提交协议最大的缺点就是它是一种堵塞协议，在事务询问阶段AP向TM发送协议消息后，AP将堵塞，直到AP收到TM提交或回滚事务

2. 数据一致性：如果在执行阶段二时TM或者部分AP不可用，部分AP执行事务不成功，导致数据不一致

三阶段提交协议-3PC

3PC是2PC的升级版，与2PC最大的不同就是3PC它是非堵塞的，具体就是在事务提交或者中止之前增加了一种超时机制，当超过这个时间上限还未提交事务，就会把该事务绑定的资源释放掉

3PC算法

• 阶段一：canCommit（投票）

  1. TM接收到事务请求后，向所有事务参与者发送canCommit请求，等待参与者返回信息，如果TM在接收事务请求时出现故障或者不可用，TM将直接中止事务。
  2. 事务参与者接收到一个来自TM的canCommit请求后，如果参与者都同意后会向TM回复yes消息并进入准备状态，如果参与者获取资源失败或者出现不可用会回复no中止事务。

• 阶段二：preCommit（预提交）

  1. TM在超时时间内收到yes消息后，会向所有的参与者发送preCommit消息，如果出现故障，超时或者TM收到no消息，TM将向所有参与者发送中止事务的消息。
  2. 所有等待中的参与者如果收到preCommit消息会发挥ACK消息并等待最终提交或中止事务，如果搜道协调者中止消息，失败或者超时等待则会中止事务。

• 阶段三：doCommit（提交）

  1. 如果协调者正常工作并收到了所有参与者的ACK消息，它会向所有的参与者发送doCommit消息，如果超时时间范围内未收到或者部分未收到等情况，协调者向所有的参与者发送中止事务消息。

  2. 如果参与者接收到doCommit消息，会正式提交事务，并释放整个事务期间占用的资源，然后向TM反馈ACK消息，如果收到来自TM的中止消息参与者会根据阶段一的undo log回滚事务，并释放所有的事务资源并向TM反馈ACK信息。完成事务。。

     

3PC的缺点

在阶段三如果协调者在超时范围内未提交doCommit消息或者中止消息，参与者在超时后会继续进行事务的提交，如果doCommit没问题但是如果是中止服务的话参与者还会自动提交事务这样可能导致本来的事务回滚变成了事务提交。

参阅：
https://en.wikipedia.org/wiki/Two-phase_commit_protocol
https://en.wikipedia.org/wiki/Three-phase_commit_protocol

个人博客