JTA 方案适用于单体架构多数据源时实现分布式事务，但对于微服务间的分布式事务就无能为力了，我们需要使用其他的方案实现分布式事务。

1、本地消息表

本地消息表的核心思想是将分布式事务拆分成本地事务进行处理。

以本电商为例子，在订单系统新增一条消息表，将新增订单和新增消息放到一个事务里完成，然后通过轮询查询方式查询消息表，将消息推送到 MQ，库存系统去消费 MQ。

订单系统，添加一条订单和一条消息，在一个事务里提交。使用定时任务轮询查询状态为未同步的消息表，发送到 MQ，如果发送失败，就重试发送。

库存系统，接收 MQ 消息，修改库存表，需要保证幂等操作。如果修改成功，调用 RPC 接口修改订单系统消息表的状态为已完成或者直接删除这条消息。如果修改失败，可以不做处理，等待重试。

订单系统中的消息有可能由于业务问题会一直重复发送，所以为了避免这种情况可以记录一下发送次数，当达到次数限制之后报警，人工接入处理；库存系统需要保证幂等，避免同一条消息被多次消费造成数据一致。

本地消息表这种方案实现了最终一致性，需要在业务系统里增加消息表，业务逻辑中多一次插入的 DB 操作，所以性能会有损耗，而且最终一致性的间隔主要由定时任务的间隔时间决定。

2、MQ 可靠消息最终一至事务

消息事务的原理是将两个事务通过消息中间件进行异步解耦。
订单系统执行自己的本地事务，并发送MQ 消息，库存系统接收消息，执行自己的本地事务。

乍一看，好像跟本地消息表的实现方案类似，只是省去了对本地消息表的操作和轮询发送 MQ 的操作，但实际上两种方案的实现是不一样的。

消息事务一定要保证业务操作与消息发送的一致性，如果业务操作成功，这条消息也一定投递成功。

消息事务依赖于消息中间件的事务消息，基于消息中间件的二阶段提交实现的，RocketMQ 就支持事务消息。

1、发送 Prepare 消息到消息中间件。发送成功后，执行本地事务。

2、如果事务执行成功，则 Commit，消息中间件将消息下发至消费端。

3、如果事务执行失败，则回滚，消息中间件将这条 Prepare 消息删除。

4、消费端接收到消息进行消费，如果消费失败，则不断重试。

3、最大努力通知

最大努力通知相比前两种方案实现简单，适用于一些最终一致性要求较低的业务，比如支付通知，短信通知这种业务。
以支付通知为例，业务系统调用支付平台进行支付，支付平台进行支付，进行操作支付之后支付平台会尽量去通知业务系统支付操作是否成功，但是会有一个最大通知次数。

如果超过这个次数后还是通知失败，就不再通知，业务系统自行调用支付平台提供一个查询接口，供业务系统进行查询支付操作是否成功。

4、补偿事务 TCC

TCC，Try-Confirm-Cancel 的简称，针对每个操作，都需要有一个对应的确认和取消操作。

当操作成功时调用确认操作，当操作失败时调用取消操作，类似于二阶段提交，只不过是这里的提交和回滚是针对业务上的，所以基于 TCC 实现的分布式事务也可以看做是对业务的一种补偿机制。

TCC 三阶段：

Try 阶段：对业务系统做检测及资源预留，如库存占用。

Confirm 阶段：对业务系统做确认提交，Try 阶段执行成功并开始执行 Confirm 阶段，默认Confirm 阶段是不会出错的。即：只要 Try 成功，Confirm一定成功。

Cancel 阶段：在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。

Try 阶段：订单系统将当前订单状态设置为支付中，库存系统校验当前剩余库存数量是否大于 1，然后将可用库存数量设置为库存剩余数量 -1。

如果 Try 阶段执行成功，开始执行Confirm 阶段，将订单状态修改为支付成功，库存剩余数量修改为可用库存数量。

如果 Try 阶段执行失败，执行 Cancel 阶段，将订单状态修改为支付失败，可用库存数量修改为库存剩余数量。

TCC热门框架：TCC transaction,himly,ByteTCC

其实TCC说白了就是你的一个事务情求，需要提拱三个接口，一下占用库存、一个实际扣减库存、一个返还库存（如果占用失败，本地事务自动回滚，如果占用成功，由事务管理器高用返还接口返还库存占用）。

5、saga事务

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

主要是两种思想，一种是编排模式，一种是命令模式

编排模式：是事件驱动类型的模式，就是每个服务执行成功了自己发布个事件，下一个服务会监听到这个事件，然后继续执行。

优点在于去中心化；缺点在于太麻烦了，如果你有连续几十个服务连续调用，会导致服务对消息的监听非常复杂，而且不好调试和定位问题，服务调用异常，服务调用链的问题排查特别麻烦，引入一个MQ，特别不好，你的服务执行依赖于MQ完成各个服务的调用，引入了复杂性，如果MQ挂掉了以后呢？事务还是会存在问题。

命令模式：其实说白了，就是某个服务如果要开启一个saga分布式事务，那么就得自己搞一个类似saga流程管理器的东西，然后来负责依次调用和执行各个服务，如果某个服务调用失败，就对之前调用成功的服务依次执行补偿接口。

6、seata分布式

这个是由阿里开源的，可以百度一下，其实就是有个seata的管理组件，有点结合了saga和TCC，就是只有一个Confirm，成功了就成功了，如果没成功，构建回滚SQL，执行回滚即可。