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。
