分布式事务

https://blog.csdn.net/qq_31854907/article/details/92796788
两个服务也存在分布式事务，a做了，b没做
分布事务，用的地方很少，也尽量避免没必要的分布式事务
什么事分布式事务：多个不同请求，并发访问不同服务，一个以及多个请求失败，则回滚。
分布式事务应理论基础： CAP BASE 理论。 CAP、BASE理论.note

两阶提交（2PC）
两段提交就是分两个阶段提交
第一阶段询问各个事务数据源是否准备好
如果各个事务源都同意则进行第二次提交，否则发消息回滚。

存在的问题：
1.都在阻塞等同步，性能差
2.需要协调者，协调者挂了，会出问题
3.在同步时一个事务数据源挂了会导致数据不一致
4.不符合微服务规范，操作多个数据库

三阶提交（3PC）
第一阶段向各个事务数据源询问是否可以提交事务，参与者同意则进入预备状态，都同意则进入阶段二否则中断事务
第二阶段协调者向参与者发出preCommit，参与者执行但不提交并发送消息
第三阶段协调者接收到所有参与者发送的消息后，发送doCommit，各个参与者提交事务

避免单点提交问题，只要发送doCommit，协调者挂了也能提交事务
降低了阻塞范围

补偿事务（TCC）
手写回滚方法和补偿方法
Try阶段：对各个服务的资源进行检查以及对资源进行锁定（实现转账时，要冻结资金）
Confirm阶段：各个服务进行实际的操作（A转账给B，A减少，B增加）
Cancel阶段：进行事务补偿（回滚）

严重依赖于回滚和补偿的代码

本地消息表（消息队列）
每个系统里都有一个本地消息表，记录事务处理信息。
A系统完成一个事务后，写入本地消息表，并放到消息队列，让其他分布式系统进行同步。
B系统从消息队列里拿到后执行事务并往自己的本地消息表里写入，如果已经执行过了，则回滚，不重复执行。
B系统执行成功后会更新本地消息表和A系统的本地消息表。如果失败了，则不处理。A系统定时扫描自己的本地消息表，对未处理的数据进行重发。
保证最终一致性（A会不断重发，直到B成功）

最终一致性方案
不使用本地消息表，通过消息队列实现事务。
A系统先把消息发送给消息队列，如果发送失败则事务直接中断。
A系统执行完本地执行事务后，向MQ发送信息，然后在提交事务。
B系统接收到消息后进行幂等性处理，执行事务，失败则重复执行。

最大努力通知方案
A系统先把消息发送给消息队列，如果发送失败则事务直接中断。
A系统执行完本地执行事务后，向MQ发送信息，然后在提交事务。
有一个服务专门消费MQ，调用别的系统进行事务
如果执行成功则改变状态结束，如果失败则继续调用，反复N次后进行回滚逻辑