分布式事务常见的解决方案

资料：

　　1.分布式事务 CAP 理解论证 解决方案

　　https://www.cnblogs.com/bluemiaomiao/p/11216380.html

　　2.***聊聊分布式事务，再说说解决方案

　　https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html

　　3.分布式事务解决方案之可靠消息最终一致性

　　https://www.cnblogs.com/zeussbook/p/11798658.html

　　4.****微服务分布式事务4种解决方案实战

　　https://blog.csdn.net/qq_21118431/article/details/103769435

方案

　一、本地消息表（异步确保）

　　　　本地消息表这种实现方式应该是业界使用最多的，其核心思想是将分布式事务拆分成本地事务进行处理，这种思路是来源于ebay。我们可以从下面的流程图中看出其中的一些细节：

 

　　基本思路就是：

　　　　消息生产方，需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交，也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送失败，会进行重试发送。

　　　　消息消费方，需要处理这个消息，并完成自己的业务逻辑。此时如果本地事务处理成功，表明已经处理成功了，如果处理失败，那么就会重试执行。如果是业务上面的失败，可以给生产方发送一个业务补偿消息，通知生产方进行回滚等操作。

　　　　生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一遍。如果有靠谱的自动对账补账逻辑，这种方案还是非常实用的。

　　　　这种方案遵循BASE理论，采用的是最终一致性，笔者认为是这几种方案里面比较适合实际业务场景的，即不会出现像2PC那样复杂的实现(当调用链很长的时候，2PC的可用性是非常低的)，也不会像TCC那样可能出现确认或者回滚不了的情况。

　　　　优点： 一种非常经典的实现，避免了分布式事务，实现了最终一致性。在 .NET中 有现成的解决方案。

　　　　缺点： 消息表会耦合到业务系统中，如果没有封装好的解决方案，会有很多杂活需要处理。

　二、MQ 事务消息　　

　　　　有一些第三方的MQ是支持事务消息的，比如RocketMQ，他们支持事务消息的方式也是类似于采用的二阶段提交，但是市面上一些主流的MQ都是不支持事务消息的，比如 RabbitMQ 和 Kafka 都不支持。

　　　　以阿里的 RocketMQ 中间件为例，其思路大致为：

　　　　　　第一阶段Prepared消息，会拿到消息的地址。
　　　　　　第二阶段执行本地事务，第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。

　　　　也就是说在业务方法内要想消息队列提交两次请求，一次发送消息和一次确认消息。如果确认消息发送失败了RocketMQ会定期扫描消息集群中的事务消息，这时候发现了Prepared消息，它会向消息发送者确认，所以生产方需要实现一个check接口，RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。

 

　　遗憾的是，RocketMQ并没有 .NET 客户端。有关 RocketMQ的更多消息，大家可以查看这篇博客

　　优点： 实现了最终一致性，不需要依赖本地数据库事务。

　　缺点： 实现难度大，主流MQ不支持，没有.NET客户端，RocketMQ事务消息部分代码也未开源。

　三、补偿事务（TCC）

　　TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。它分为三个阶段：

• Try 阶段主要是对业务系统做检测及资源预留

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

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

　　举个例子，假入 Bob 要向 Smith 转账，思路大概是：
　　我们有一个本地方法，里面依次调用
　　　　1、首先在 Try 阶段，要先调用远程接口把 Smith 和 Bob 的钱给冻结起来。
　　　　2、在 Confirm 阶段，执行远程调用的转账的操作，转账成功进行解冻。
　　　　3、如果第2步执行成功，那么转账成功，如果第二步执行失败，则调用远程冻结接口对应的解冻方法 (Cancel)。

　　优点： 跟2PC比起来，实现以及流程相对简单了一些，但数据的一致性比2PC也要差一些

　　缺点： 缺点还是比较明显的，在2,3步中都有可能失败。TCC属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，在一些场景中，一些业务流程可能用TCC不太好定义及处理。

　四、最大努力通知型

　　资料：分布式事务解决方案之最大努力通知 

　　https://www.cnblogs.com/zeussbook/p/11799017.html

　　最大努力通知与可靠消息一致性有什么不同

　　　　可靠消息一致性，发起通知方需要保证将消息发出去，并且将消息发送到接收通知方，消息的可靠性由发起通知方保证
　　　　最大努力通知，发起通知方尽最大的努力将业务处理结果通知为接收通知方，但是消息可能接收不到，此时需要接收通知方主动调用发起通知方的接口查询业务，通知可靠性关键在于接收通知方
　　两者的应用场景
　　　　可靠消息一致性关注的是交易过程的事务一致，以异步的方式完成交易
　　　　最大努力通知关注的是交易后的通知事务，即将交易结果可靠的通知出去

 　五，2PC和3PC

　　资料： 关于2PC(二阶段提交)和3PC(三阶段提交)的理解

　　　　https://blog.csdn.net/xj15010735572/article/details/86233456

 

Seata分布式事务方案

　　Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案，提供了 AT、TCC、Saga 和 XA 事务模式

　　阿里 开源分布式方案