七种常见分布式事务
2pc：两阶段提交，准备阶段和提交阶段
准备阶段：由事务协调者询问通知每个事务参与者，是否准备好执行事务
提交阶段：所有参与l参与者都同意，意味着完成事务，要么都commit要么都rollback
问题：可靠性和数据一致性问题
3pc：针对2pc进行改进
协调者和参与者引入超时机制；第一阶段和第二阶段中间插入一个准备阶段，保证在最后提交阶段之前各参与节点的状态保持一致
分为CanCommit，PreCommit，DoCommit阶段
precommit：
- 执行事务：假如所有参与者反馈yes，协调者预执行事务，
- 发送预提交请求：协调者向参与者发送precommit请求，进入准备阶段
- 事务预处理：参与者接收到precommit请求后，执行本地事务操作，并将undo和redo信息记录到事务日志中。（并不提交事务）
- 提交反馈：如果参与者成功的执行了事务操作，返回ack响应，同时等待最终命令
2. 中断事务：假设其中任何一个参与者反馈了no，或者等待超时，那么就执行事务中断。
- 发送中断请求：协调者向所有参与者发送abort请求
- 中断事务：参与者收到abort请求后，执行事务中断
docommit:
- 提交事务：
- 发送提交请求：接收到所有参与者的ack确认，从预提交变为提交，从所有参与者发送docommit
- 本地事务提交：参与者接收到docommit请求之后，执行正式事务，提交之后释放事务资源
- 响应反馈：事务提交完，向协调者发送ack响应
- 完成事务：协调者接收到所有参与者的ack响应之后，完成事务
- 中断事务：任何一个参与者反馈no，或者等待超时
- 发送中断请求：协调者向参与者发送abort请求
- 事务回滚：参与者接收abort之后，利用undo信息回滚，释放资源
- 反馈结果：完成回滚之后，向协调者反馈ack消息
- 中断事务：协调者接收到所有ack消息后，中断事务
3pc依然无法解决数据不一致问题，当参与者收到precommit请求后等待docommit指令时，如果协调者请求中断事务，而协调者因为网络问题无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。
tcc
saga
本地消息表
MQ事务消息
基于mq的分布式事务本质上是对本地消息表的封装，整体流程与本地消息表一致，唯一不同的将本地消息存在了mq内部，而不是业务数据库中
最大努力通知（定期校对）
对mq事务的优化，在事务主动方增加了消息校对的接口，如果事务被动方没有接收到主动方发送的消息，此时可以调用事务主动方提供的消息校对的接口主动获取。
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。