分布式事务

1.
2PC/XA方案​

所谓的XA方案，即两阶段提交，有一个事务管理器的概念，负责协调多个数据库的事务，事务管理器先访问各个数据库​

1.
若每个数据库都回复OK，就正式提交事务，在各个数据库上执行操作​

2.
若其若其中有个数据库回不OK，那么就回滚事务​

分布式事务方案，比较适合单块应用里，跨多个库的分布式事务，而且因为严重依赖于数据库层面来搞定复杂的事务，效率低且不适合高并发场景​

一般来说，若某个系统内部出现跨多个库的操作是不合规的，当要操作别人服务的库时，一般是调用别人的服务接口来实现，绝对不允许交叉访问别人数据库​

2.
TCC强一致性方案​

TCC全称：Try、Confirm、Cancel

•
Try阶段：这个阶段说的是对各个服务的资源做检测以及对资源进行 锁定或者预留​

•
Confirm阶段：这个阶段说的是在各个服务中执行实际的操作​

•
Cancel阶段：如果任何一个服务的业务方法执行出错，那么这里就需要 进行补偿，就是执行已经执行成功的业务逻辑的回滚操作。（把那些执行成功的回滚）​

这种方案说实话几乎很少人使用，但是也有使用的场景。因为这个事务回滚实际上是严重依赖于你自己写逻辑来实现回滚和补偿，会造成巨大的补偿代码量​

3.
可靠消息最终一致性方案​

基于 MQ 来实现事务。比如阿里的 RocketMQ 就支持消息事务

1.
A系统先发送一个prepared消息到MQ，若这个prepared消息发送失败就直接取消操作不执行​

2.
若消息发送成功，接着执行本地事务，若成功就告诉MQ发送确认消息，若失败就告诉MQ回滚消息​

3.
如果发送了确认消息，此时B系统会接收到确认消息，然后执行本地事务​

4.
mq会自动定时轮询所有prepared消息回调你的接口，确认消息是不是本地事务处理失败，所有没发送确认的消息，继续重试或回滚​

4.
最大努力通知方案​

1.
系统A本地事务执行完毕之后，发送消息到MQ​

2.
有专门消费MQ的最大努力通知服务，这个服务会消费MQ然后写入数据库中记录下来，或是放入内存队列，调用系统B的接口​

3.
系统B执行成功回复OK；若系统B执行失败，最大努力通知服务就定时尝试重新调用系统B，反复N次，最后还是不行就放弃​

参考资料

分布式事务​