分布式事务（5）分布式事务常见解决方案

5.1 TCC方案

TCC：Try、Confirm、Cancel。

Try阶段：对各个服务的资源做监测以及对资源进行锁定或者预留。

Confirm阶段：在各个服务中执行实际的操作。

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

TCC方案.png

适用场景：大量的同步服务调用的复杂的事务场景，如果要用TCC来保证分布式事务的执行，尽量确保每个服务的调用都比较快，确保一个TCC分布式事务的执行，大概需要总共1秒以内的时间。

常用框架：

1、TX-LCN框架

https://www.txlcn.org/zh-cn/

2、tcc-transaction框架

https://github.com/changmingxie/tcc-transaction

3、himly框架

https://github.com/yu199195/hmily

4、ByteTCC框架

https://github.com/liuyangming/ByteTCC

5.2 本地消息表

本地消息表.png

适用场景：业务数据量不大的情况。

5.3 可靠消息最终一致性方案

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

适用场景：适合比较耗时的操作，通过这个消息中间件做成异步调用，发送一个消息出去，人家服务消费消息来执行业务逻辑。
可用RocketMQ的分布式事务实现可靠消息最终一致性方案。（RocketMQ = 可靠消息服务+MQ）

5.4 最大努力通知方案

最大努力通知方案.png

适用场景：跟可靠消息最终一致性方案类似，可靠消息最终一致性方案，会保证最终必须要让那个执行成功的，但是最大努力通知方案，不一定保证最终一定会成功，可能会失败，但是会尽力给你去给你通知那个服务的执行。

5.5 saga事务

saga事务：saga是将每个接口，拆分为2个接口，一个是业务接口，另外一个是补偿接口，相当于就是说将tcc里面的try和confirm合并为一个接口，就是先执行业务接口，直接就尝试完成整个业务逻辑的操作。然后如果在服务调用链条里面，某个服务的业务接口执行失败了，那么直接对已经执行成功的所有服务都调用其补偿接口，将之前执行成功的业务逻辑给回滚。

saga事务的核心和本质：就是把每个操作分为实际的业务逻辑以及补偿业务逻辑，正常情况下，就依次执行各个服务的业务逻辑就好了，如果某个服务调用失败的话，直接对之前执行成功的那些服务都依次执行补偿逻辑。

saga事务的思想：就是将一个长的分布式事务，拆分为一连串的每个服务的本地事务，然后每个服务对每个接口提供两个接口，一个是业务接口，一个是回滚的补偿接口，正常情况下就是依次的进行调用。异常情况下，就对之前已经执行成功的服务执行补偿接口，回滚业务逻辑。