XA分布式事务协议 - 两阶段提交 & 三阶段提交

两阶段提交

两阶段提交包括两个角色：事务协调者和事务参与者

正向操作：

第一阶段：
1. 事务协调者向n个事务参与者发出prepare命令。
2. 事务参与者在接收到prepare命令后，每一个参与者会各自执行数据操作，将操作写入undo-log和redo-log，以便后期的事务回滚和重试。
3. 事务参与者执行成功，暂时不提交事务，同时向事务协调者返回“完成”消息。

第二阶段：
1. 事务协调者收到n个“完成”消息，也就是n个事务参与者都执行成功了。
2. 事务协调者向n个事务参与者发出commit命令，事务参与者收到这个命名后，会进行本地事务提交，当事务提交完成后，向事务协调者发出“完成”的消息。

正向第一阶段 正向第二阶段

反向操作：

第一阶段：
1. 事务协调者向n个事务参与者发出prepare命令。
2. 事务参与者在接收到prepare命令后，每一个参与者会各自执行数据操作，将操作写入undo-log和redo-log，以便后期的事务回滚和重试。
3. 事务参与者执行失败，向事务协调者返回“失败”的消息。

第二阶段：
1. 事务协调者收到至少一个失败的消息，也就是n个事务参与者都执行成功了。
2. 事务协调者向n个事务参与者发出abort命令，事务参与者收到这个命名后，会进行本地事务回滚，当事务提交完成后，向事务协调者发出“完成”的消息。

反向第一阶段 反向第二阶段

两阶段提交存在的缺点

1. 性能缺陷：同步阻塞问题
XA协议遵循强一致性，在事务执行过程中，各个节点占用数据库资源，只有当所有节点都准备完毕，才释放资源，存在明显的性能问题。
2. 单点问题
事务协调者是一个单点，一旦事务协调者挂掉，参与者就收不到commit消息或回滚的通知。
3. 消息在网络中流动，容易出现消息丢失的情况。

三阶段提交

二阶段拆分成三阶段：canCommit, preCommit, doCommit

1. canCommit 
和二阶段提交的第一阶段相似，协调者向参与者发出canCommit命令，参与者响应yes或no
2.preCommit
 协调者向参与者发出preCommit命令，进入prepare状态，参与者收到命令后，执行事务操作，记录undo,redo日志。
3. doCommit
协调者向参与者发出doCommit命令，参与者接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。
事务提交完之后，向协调者发送Ack响应。

3pc相对于2pc：
1. 参与者在一定时间范围内，没有收到协调者消息（也就是超时），会自动commit。