分布式事务解决方案 微服务分布式事务解决方案 TX-LCN TCC 3PC XA Paxos TxManager TxClient netty 补偿机制 强一致性

分布式事务的实现主要有一下5中方案：
1、XA方案
2、TCC 方案
3、本地消息表
4、可靠消息最终一致性方案
5、最大努力通知方案

1、两阶段提交XA方案【distributed-transacion-XA】【挂好操作】
概念：所谓的XA方案，，有一个事务管理器的概念，负责协调多个数据库的事务。事务管理器先问问各个数据库你准备好了么？如果每个数据库 能回复OK，那么就正式提交事务。在各个数据库上执行操作；如果任何其中一个数据库回答不OK，那么就回滚事务。
使用场景：比较适合单块应用里、跨多个库的事务里，而且正是因为严重依赖数据库层面搞定复杂的事务，效率很低，绝对不适合高并发的场景。如果要玩，那么基于Spring+JPA就可以搞定。
这个方案我们很少用，一版来说某个系统内部如果出现了跨多个库的这么一个操作，是不合规的，我可以给大家介绍一下：现在微服务，一个大系统分成一百个微服务 ，几十个微服务一般来说 我的规定和规范是要求每个服务智能操作自己对应的一个数据库。
如果你要操作别的服务对应的数据库，不允许直接别的服务的数据库，违反微服务架构的规范。你随便交叉胡乱访问，几百个服务的话，全体乱套，这样的一套微服务是没法管理的，没法治理的，可能会出现数据被别人改错，自己的库被别人写挂等情况。
如果你要操作别人的服务的数据库，必须是通过调用别的服务接口实现。

2、TCC 方案【强一致性】【微信支付demo】
TCC的全称是：Try、Confirm、Cancel
Try阶段：对各个服务的资源做检测以及对资源进行锁定或者预留。
Confirm阶段：在各个服务中执行实际的操作。
Cancel阶段：进行补偿：如果任何一个服务的方法执行出错，那么这里就需要进行补偿，就是执行已经执行成功的业务逻辑的回退操作。【把执行成功的回滚】。
这种方案使用的比较少、几乎没人使用，但是也有使用的场景。因为这个事务回滚实际上是严重依赖与你自己写代码回滚和补偿了，会造成补偿代价巨大，非常之恶心。

3、本地消息表【distributed-transaction-local-message-table】
1、A系统在本地一个事务里操作同时、插入一条数据到消息表
2、接着A系统将这个消息发送到MQ中
3、B系统接收到消息之后，在一个事务里，自己本地消息表里插入一条数据，同时执行其他的业务操作，如果这个消息已经被处理过了，那么此时这个事务会回滚，这样保证不会重复处理消息。
4、B系统执行成功之后，就会更新自己本地消息表的状态以及A系统消息表的状态；
5、如果B系统执行失败了，那么就不会更新消息表的状态。那此时A系统会定时扫描自己的消息表，如果有未处理的消息，会再次发送到MQ中，让B去处理；
6、这个方案保证了最终一致性，哪怕B事务失败了，但是A会不断重发消息，直到B那边成功为止。
这个方案最大的问题在于 严重依赖数据库的消息表来管理事务。会导致如果高并发场景咋办呢？咋扩展呢？所以很少用。

4、可靠消息最终一致性方案
不用本地的消息表了，直接基于MQ来实现的事务。比如阿里的RocketMQ就支持消息事务。
1、A系统发送一个prepared消息到MQ，如果这个prepared消息发送失败那么就直接取消操作别执行了。
2、如果这个消息发送成功了、就接着执行本地事务，如果成功就告诉MQ发送确认消息，如果失败，就告诉MQ发送回滚消息。
3、如果发送了确认消息、那么B系统会接收到确认消息，然后执行本地事务。
4、Mq 会自动定时轮询所有prepared消息回调你的接口，问你，这个消息是不是本地事务处理失败了，所有没有发送确认的消息，是继续重试还是回滚？一版来说这里你就可以查下数据库看之前本地事务是否执行，如果回滚了，那么这里也回滚吧。这个就是避免可能本地事务执行成功了，而确认消息却发送失败了。

5、最大努力通知方案
1、系统A本地事务执行完成之后，发送个消息到MQ
2、这里有个专门消费MQ的最大努力通知服务，这个服务会消费MQ然后写入数据库中记录下来，或者是放入个内存对垒也可以，接着调用系统B的接口；
3、要是系统B执行成功就OK了；要是系统B执行失败了，那么最大努力通知服务就定时尝试重新调用系统B，反复了N次，最后还是不行就放弃。
6、LCN

LCN分布式事务框架的核心功能是对本地事务的协调控制，框架本身并不创建事务，只是对本地事务做协调控制。因此该框架与其他第三方的框架兼容性强，支持所有的关系型数据库事务，支持多数据源，支持与第三方数据库框架一块使用（例如 sharding-jdbc），在使用框架的时候只需要添加分布式事务的注解即可，对业务的侵入性低。LCN框架主要是为微服务框架提供分布式事务的支持，在微服务框架上做了进一步的事务机制优化，在一些负载场景上LCN事务机制要比本地事务机制的性能更好，4.0以后框架开方了插件机制可以让更多的第三方框架支持进来.
https://github.com/codingapi/tx-lcn
tx-lcn分布式事务框架 (5.0.0.RC2)
5.0完全拥抱springboot体系,JDK版本为1.8开发，将不仅仅支持LCN事务模式，也引入了TCC，TXC模式，同时把分布式事务协调的模式抽象出来，让各种模式可以嵌套使用。
版本主要特点：
将基于springboot 2.0研发,将替换groupId传递机制，由sleuth机制处理。
将抽离LCN封装业务，提出业务接口层与通讯层，将可支持自定义分布式事务模式与通讯模式。
将支持LCN TXC TCC 三种事务模式，且可混合支持。
性能继续优化，去掉线程等待机制，提高吞吐量。

---

官方文档:

https://txlcn.org/zh-cn/docs/demo/env.html

其中 @TxTransaction(isStart = true) 为lcn 事务控制注解，其中isStart = true 表示该方法是事务的发起方例如，服务A 需要调用服务B,服务B 需要调用服务C，此时 服务A为服务发起方，其余为参与方，参与方只需@Transaction 即可.
在测试时需要将 事务管理服务启动 txManager.

LCN事务控制原理是由事务模块TxClient下的代理连接池与TxManager的协调配合完成事务协调控制。
TxClient的代理连接池实现了javax.sql.DataSource接口，并重写了close方法，事务模块提交关闭以后，TxClient连接池执行“假关闭”操作，等待TxManager协调完成事务以后在关闭连接。

TxManager是LCN分布式事务框架的事务协调器，框架基于Netty做消息通讯，事务控制数据存储在redis中。TxManager采用高可用集群化部署方案，多个TM通过eureka集群完成服务注册，各个TxClient通过服务名称向TxManager发送事务信息。.
Redis采用集群化配置方案（也可采用哨兵模式配置方案），保证事务控制数据的一致性及准确性.
LCN通讯是基于TCP长连接的socket通讯，TxMansager与事务控制方是基于netty框架完成的。该协议只描述参与Socket通讯的协议。LCN分布式事务框架其本身并不创建事务，而是基于对本地事务的协调从而达到事务一致性的效果。
LCN 核心采用3PC+TCC补偿机制，采用强一致性方案，保证了事务的一致性。

参考地址：

https://blog.csdn.net/u010882691/article/details/82256587