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

最新推荐文章于 2022-02-24 21:33:52 发布

和代码去流浪

最新推荐文章于 2022-02-24 21:33:52 发布

阅读量240

点赞数

分类专栏： # 分布式相关文章标签：微服务分布式

原文链接：https://blog.csdn.net/qq_32423845/article/details/88283803

版权

分布式相关专栏收录该内容

62 篇文章 3 订阅

订阅专栏

分布式事务的实现主要有一下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