分布式事务

TCC *

核心接口要提供3个接口服务。
1 Try ： 对各个服务的资源做检测已经对资源进行锁定或者预留
2 Confirm ： 在各个服务中进行实际的操作
3 Cancle ： 进行补偿，就是对执行成功的业务进行回滚的操作

链路里面， 有任何一个服务调用失败， 则全部接口调用 cancle掉。
如果全部成功， 则全部调用confirm，全部提交。

很多实际用2个。
1 执行事务的方法
2 回滚 的方法
使用分布式事务框架去做， 如果事务中发生异常， 则会调用回滚的方法

实现方案：
使用分布式事务的框架
阿里开源的框架： Seata
这个框架的原理：
独立部署一个 Seata-server
一个分布式事务， 包含很多分支事务。

发起分布式事务， 申请一个分布式事务的ID
XID传递到各个服务里面。

能不能支持高并发？稳定性怎么样？
也需要部署集群和进行分库分表来保证高可用和高并发。

可靠消息最终一致性 *

基于队列封装一个可靠性方案服务。

消息消费后，回调接口，通知消费成功。 一定时间没有消费成功， 就重新发送一个消息到队列。

直接使用RocketMQ，直接提供了分布式事务的相关服务实现。

1 向RocketMQ发送一个 half message，一定要等MQ确认收到(告诉服务收到)才进行下一步。这个消息不能被消费。

2 执行链路的流程(各个微服务的方法和自己本系统的方法)。

3 如果链路执行失败， 向MQ发送 rollback message 。 废弃之前的消息。

4 如果链路执行成功，向MQ发送commit message。 消费者就可以对消息进行消费。 消费处理完了， 需要发送一个ACK消息给MQ ， 确认这个消息已经被成功消费了。

5 如果MQ长时间没有收到rollback 或 commit （通过定时扫描）。超时后，就要进行回调， 需要微服务提供一个接口给MQ回调, 接口需要告诉MQ是回滚还是执行.

6 消费者进行消费的时候消费失败了。 返回一个ACK消息，告诉MQ消费失败了， MQ就会重新发送消息给消费者。

消费者一定要保证消费消息的幂等性。

XA 两阶段提交事务。

常见于 1个系统，跨多个数据库。

XA事务，事务管理器进行事务管理。
第一阶段：询问每个事务是否可以进行操作。

第二阶段： 如果得到回复都没问题，则进行事务提交，执行事务，再次通知各个系统进行事务提交。
如果有任何一个事务回复有问题， 则通知各个事务进行回滚。

Spring+JTA可以做。
严重依赖数据库，不适合并发高的系统。

最大努力通知

通知到一定的次数，就不通知了。

本地消息表

各个系统在本地数据库维护一个消息表，记录事务的状态(是否完成)。

依赖数据库消息表。 高并发，难于维护。 可以使用Redis维护？

尽量不做分布式事务， 直接调用相关服务即可。
可以采用， 监控，记录错误日志， 时候快速定位、排查问题， 然后修复数据 。

做这些工作的成本， 比做分布式事务的成本要低。

分布式事务会增加系统的复杂性， 性能会降低比较多， 可用性比较低。