分布式事务参考

原先的单机系统，所有的逻辑都在同一台机子、同一个运行环境中，事务的提交相对比较简单。

而在微服务的架构中，由于不同的服务层（或能力层）被分开，虽然公开的都是API接口，但是由于服务已经被拆分部署，实际上事务已经无法简单在单机中提交和回滚了。

1、理论阶段

　　1.1、二阶段提交（2PC）

　　　　第一阶段（Prepare）

　　　　　　1、协调者（事务管理TM）记录日志并向所有参与者（RM）发送准备提交信息

　　　　　　2、参与者收到信息后，记录日志；返回就绪或撤销信息

　　　　　　3、协调者如果在规定的时间内收到所有参与者的就绪信息，就做出提交的决定；否则做出撤销的决定

　　　　第二阶段 执行阶段（Commit/Rollback）

　　　　　　1、协调者先将决定记录到日志，然后把这个决定发送给所有的参与者

　　　　　　2、参与者收到命令后先记录日志，并向协调者发送应答消息，然后执行决定的命令

　　　　　　3、协调者收到应答消息后，则事务结束。有关日志可以自行决定如何存储

　　1.2、三阶段提交（3PC）

　　　　第一阶段（Prepare）：

　　　　　　1、协调者（事务管理TM）向所有参与者（RM）发出准备信息

　　　　　　2、若任一参与者返回Abort，则执行第三阶段，Rollback

　　　　　　3、若所有参与者返回vote-commit，则进入第二阶段

　　　　第二阶段（Prepare To Commit）

　　　　　　1、协调者（事务管理TM）向所有参与者（RM）发送准备提交信息

　　　　　　2、参与者收到信息后，记录日志，并回复确认消息ACK

　　　　第三阶段 执行阶段（Commit/Rollback）

　　　　　　1、协调者根据第一阶段回复的Abort执行Rollback或者根据第二阶段回复的ACK消息向参与者发送Commit或Rollback

　　　　　　2、参与者根据协调者发送的信息决定执行Commit或Rollback操作

　　重点：

• 参考mysql innoDB的redo和undo日志的二阶段提交，日志利用了命令模式的do 和 undo，即命令的执行和回滚
• 2PC和3PC都存在锁定资源的情况，只是3PC锁定的时间会更短些
• 2PC和3PC都存在事务最终失败，需要回滚或补偿的情况（指的并非正常收到通知之后做出的Rollback决策，而是指服务突然宕机造成的A服务执行成功，B服务宕机，造成事务失败的情况），只不过这种情况相对几率较小；一般的系统采用2PC或3PC即可

2、实战阶段，待补

分布式事务参考

原文：https://www.cnblogs.com/gabin/p/13765442.html