2PC和3PC分布式事务

两阶段提交（2PC）

优点：尽量保证了数据的强一致性，各大主流数据库本身支持（XA协议）

缺点：

• 单点问题：阶段一完成以后，事务管理器宕机，导致无法进行阶段二，资源管理器一直处于阻塞状态。

• 同步阻塞：阶段一完成以后，所有的资源管理器都属于阻塞状态，直到事务提交或回滚才能释放资源。

• 数据不一致：在第二阶段中，事务管理器发送commit指令，由于网络等原因，部分资源管理器没有收到指令，导致数据不一致。

总结：2PC由于锁定资源时间长，对性能影响大，基本不适用分布式事务问题

三阶段提交（3PC）

1. 阶段一:canCommit

   • 事务询问：事务协调者向所有参与者发送一个canCommit请求，询问是否可以执行事务
   • 等待参与者响应：参与者收到canCommit请求，可以执行事务返回yes,否则返回no
   • 此阶段不执行事务操作

2. 阶段二：preCommit

   事务协调者收到所有参与者响应后，如果全为yes执行preCommit,如果有no中断事务

   preCommit:

   • 向所有参与者发送preCommit请求，进入prepared状态。

   • 参与者收到preCommit请求后，开始执行事务操作，也会将undo和redo信息记录到事务日志中。

   • 各参与者向事务协调者响应执行结果：成功执行返回ack,同时等待指令：commit或abort。

   中断事务

   • 向所有参与者发送中断请求：abort指令

   • 参与者收到abort指令或超时，都会中断事务

3. 阶段三：doCommit

   事务协调者收到所有参与者ack,从预提交preCommit变为doCommit状态

   doCommit:

   事务协调者向所有参与者发送doCommit指令，事务参与者提交事务后,向事务协调者发送ack响应，协调者收到所有参与者的ack，完成事务。

   abort中断事务：

   • 事务协调者收到no或者有参与者超时，向所有参与者发送abort

   • 事务参与者收到abort后，根据undo log回滚事务,完成事务释放资源，向事务协调者发送ack

   • 事务协调者收到所有参与者ack后，中断事务

2PC和3PC区别

3PC在阶段三由于协调者出问题或网络出现故障，参与者无法收到doCommit或abort请求，参与者在等待一段时间后会自动提交。

3PC在阶段一不阻塞

3PC在单点故障后会根据协调者状态进行提交或回滚

mysql–XA

XA BEGIN '123';

-- 具体要执行的sql
update t_test set num=2 WHERE pKey=1;

XA END '123';

XA PREPARE '123';

XA COMMIT '123';

XA ROLLBACK '123';

-- XA PREPARE id以后才会查询到状态
-- formatID  gtrid_length bqual_length data 
-- 1					2						0							123
XA RECOVER ;