针对2PC的问题引入3PC分布式事务

目录

 

什么是2PC

2PC的问题

3PC

3PC的问题

3PC与2PC的区别

---

什么是2PC

2PC(two phase commit)两阶段提交

一、准备阶段

TM（Transaction Manager，事务管理器）先发送个prepare消息给各个数据库，让各个库先把分布式事务里要执行的各种操作，先准备执行，其实此时各个库会差不多先执行好，就是不提交；然后各个数据库都返回一个响应消息给事务管理器，如果成功了就发送一个成功的消息，如果失败了就发送一个失败的消息。

二、提交阶段

如果阶段一任何一个数据有问题（超时/失败），则通知所有库都回滚，当所有的库都回滚成功通知TM，TM就认为整个分布式事务都回滚了；

如果阶段一所有库都返回成功的消息，TM通知各个数据库提交事务，各个库提交好了通知下TM，TM要是发现所有数据库的事务都提交成功了，就认为整个分布式事务成功了。

 

2PC的问题

一、同步阻塞

在阶段一里执行prepare操作会占用资源，一直到整个分布式事务完成，才会释放资源，这个过程中，如果有其他人要访问这个资源，就会被阻塞住；

二、单点故障

TM在整个二级阶段提交中起到非常重要的作用，一旦TM出现问题，那么整个第二阶段提交流程将无法运转，更为严重的是，TM在阶段二中出现问题的话，那么其他的参与者将会处于锁定事务资源的状态中，而无法继续完成事务操作；

三、事务状态丢失，数据不一致

即使把TM做成一个双机热备的，一个TM挂了自动选举其他的TM出来，但是如果TM挂掉的同时，接收到commit消息的某个库也挂了，此时即使重新选举了其他的TM，压根儿不知道这个分布式事务当前的状态，因为不知道哪个库接收过commit消息；

TM向各个库发送commit请求之后，发生了局部网络异常，这会导致只有一部分数据库接受到了commit请求；而在这部分参与者接到commit请求之后就会执行commit操作；但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据不一致性的现象。

 

3PC

3PC(three-phase commit)即三阶段提交，是2阶段提交的改进版

一、CanCommit阶段

就是TM发送一个CanCommit消息给各个数据库，然后各个库返回个结果，注意一下，这里的话呢，是不会执行实际的SQL语句的，其实说白了，就是各个库看看自己网络环境啊，各方面是否ready。

二、PreCommit阶段

如果各个库对CanCommit消息返回的都是成功，那么就进入PreCommit阶段，TM发送PreCommit消息给各个库，这个时候就相当于2PC里的阶段一，其实就会执行各个SQL语句，只是不提交罢了；

如果有个库对CanCommit消息返回了失败，那么TM发送abort（中断）消息给各个库，结束这个分布式事务。

三、DoCommit阶段

如果各个库对PreCommit阶段都返回了成功，那么发送DoCommit消息给各个库，提交事务，各个库如果都返回提交成功给TM，那么分布式事务成功；

如果有个库对PreCommit返回的是失败，或者超时一直没返回，那么TM认为分布式事务失败，直接发abort消息给各个库，各个库回滚成功之后通知TM，分布式事务回滚。

 

3PC的问题

三阶段提交协议在去除阻塞的同时也引入了新的问题，那就是如果TM在DoCommit阶段发送了abort消息给各个库，因网络问题，某个库没接收到abort消息，超时后执行了commit操作，这必然出现数据的不一致性。

 

3PC与2PC的区别

一、引入了CanCommit阶段

二、在DoCommit阶段，各个库自己也有超时机制

也就是说，如果一个库收到了PreCommit自己还返回成功了，等了一会儿，如果超时时间到了，还没收到TM发送的DoCommit消息或者是abort消息，直接判定为TM可能出故障了，数据库就自己执行DoCommit操作，提交事务了。

因为说如果这个库接收到了PreCommit消息并且返回成功了，说明第一阶段各个库对CanCommit都返回成功了，这样TM才会发送PreCommit来，那么就默认为基本上各个库的PreCommit都会成功，所以大家没接收到DoCommit，直接自己执行提交操作了。

所以这个超时的机制是基于CanCommit的引入来实现的，有了一个CanCommit多了一个阶段，大家才能自己执行超时commit机制。