Atomikos和GTS-Fescar和TCC-Transaction和TX-LCN分布式事物的比较

什么是分布式事物

分布式系统中保证不同节点之间的数据一致性的事物,叫做分布式事物。

为什么要用分布式事物

微服务,SOA等服务架构模式,一个是service产生多个节点,另一个是resource产生多个节点。

service多个节点

Atomikos和GTS-Fescar和TCC-Transaction和TX-LCN分布式事物的比较

resource多个节点

Atomikos和GTS-Fescar和TCC-Transaction和TX-LCN分布式事物的比较

系统故障、网络错误等情况下,都会导致数据存储不一致的情况,这种情况就需要分布式事物来处理。

如何用分布式事物

分布式事物解决方案

XA二阶段提交

1.性能问题

XA协议遵循强一致性。在事务执行过程中,各个节点占用着数据库资源,只有当所有节点准备完毕,事务协调者才会通知提交,参与者提交后释放资源。这样的过程有着非常明显的性能问题。

2.协调者单点故障问题

事务协调者是整个XA模型的核心,一旦事务协调者节点挂掉,参与者收不到提交或是回滚通知,参与者会一直处于中间状态无法完成事务。

3.丢失消息导致的不一致问题。

在XA协议的第二个阶段,如果发生局部网络问题,一部分事务参与者收到了提交消息,另一部分事务参与者没收到提交消息,那么就导致了节点之间数据的不一致。

XA三阶段提交

XA三阶段提交在两阶段提交的基础上增加了CanCommit阶段,并且引入了超时机制。一旦事物参与者迟迟没有接到协调者的commit请求,会自动进行本地commit。这样有效解决了协调者单点故障的问题。但是性能问题和不一致的问题仍然没有根本解决。

MQ事务

利用消息中间件来异步完成事务的后一半更新,实现系统的最终一致性。这个方式避免了像XA协议那样的性能问题。不过由于会出现网络延迟的问题,消息重复、消息顺序无法保证的情况也会出现。需要业务机制进行补偿。

本地消息表

将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列,再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景,通过对账系统对事后问题的处理。

Atomikos和GTS-Fescar和TCC-Transaction和TX-LCN分布式事物的比较

Saga事务

将长事务拆分为多个本地短事务,由Saga事务协调器协调,如果正常结束那就正常完成,如果某个步骤失败,则根据相反顺序一次调用补偿操作。saga模式没有隔离性的影响还是较大。

LCN事务

LCN模式是通过代理Connection的方式实现对本地事务的操作,然后在由TxManager统一协调控制事务。当本地事务提交回滚或者关闭连接时将会执行假操作,该代理的连接将由LCN连接池管理。

该模式对代码的嵌入性为低

该模式仅限于本地存在连接对象且可通过连接对象控制事务的模块。

该模式下的事务提交与回滚是由本地事务方控制,对于数据一致性上有较高的保障

该模式缺陷在于代理的连接需要随事务发起方一共释放连接,增加了连接占用的时间

Atomikos和GTS-Fescar和TCC-Transaction和TX-LCN分布式事物的比较

Atomikos和GTS-Fescar和TCC-Transaction和TX-LCN分布式事物的比较

Atomikos事务

优点:

1.   全面崩溃 / 重启恢复
2.  兼容标准的SUN公司JTA API
3.  嵌套事务
4.  为XA和非XA提供内置的JDBC适配器

缺点:

1.   Atomikos从池里取得connection时,每次都会去进行select test,这个对获取连接的影响很大,取消这个测试,TPS大概能提高近1倍;

2.   Atomilos对池中connection的管理效率随着连接数的上升,呈现指数级的下降,测试环境中,连接最大配置为300,但实际上最大值没有超过70,线程dump发现连接池管理对象上存在激烈的锁竞争,导致很多线程等待前面的线程释放锁对象;

3.   由于Atomikos支持JTA事务,而c3p0则不支持,这导致atomikos在获取connection时,首先需要从线程上下文去检索是否已经存在着connection,这个检测从atomikos的实现上看,会遍历连接池中所有connection对象,所以当连接数上升时,连接池的效率显著下降;

TCC事务

TCC事务是Try、Commit、Cancel三种指令的缩写,其逻辑模式类似于XA两阶段提交,但是实现方式是在代码层面来人为实现。

该模式对代码的嵌入性高,要求每个业务需要写三种步骤的操作。

该模式对有无本地事务控制都可以支持使用面广。

数据一致性控制几乎完全由开发者控制,对业务开发难度要求高

TCC事务机制相比于上面介绍的XA,解决了其几个缺点:

1.解决了协调者单点,由主业务方发起并完成这个业务活动。业务活动管理器也变成多点,引入集群。

2.同步阻塞:引入超时,超时后进行补偿,并且不会锁定整个资源,将资源转换为业务逻辑形式,粒度变小。

3.数据一致性,有了补偿机制之后,由业务活动管理器控制一致性 。

TCC事务的缺点,主要就一个:

  • TCC的Try、Confirm和Cancel操作功能需业务提供,开发成本高。

Atomikos和GTS-Fescar和TCC-Transaction和TX-LCN分布式事物的比较

到底要不要使用TCC到底要不要使用TCC事务,取决于以下几点:

  • 是否真正有保证跨应用业务操作的原子性需求。
  • 研发上能否投入资源开发相对应的TCC接口。
  • 当然还有最后一点,能否搞定一个稳定的、高可用的、扩展性强的TCC事务管理器。

Fescar

优点

高效 并且对业务 0 侵入 的方式,解决 微服务 场景下面临的分布式事务问题。

缺点

存在一些局限,比如:事务隔离级别最高支持到 读已提交 的水平,SQL 的解析还不能涵盖全部的语法等。

分为AT模式和MT模式,默认的是AT模式,但是最好是AT模式和MT模式结合使用,因为MT模式可以将非关系型数据库也纳入全局事务管理中。

AT模式的行为分支

业务逻辑不需要关注事务机制,分支与全局事务的交互过程自动进行。

Atomikos和GTS-Fescar和TCC-Transaction和TX-LCN分布式事物的比较

MT模式的行为分支

业务逻辑需要被分解为 Prepare/Commit/Rollback 3 部分,形成一个 MT 分支,加入全局事务。

Atomikos和GTS-Fescar和TCC-Transaction和TX-LCN分布式事物的比较

MT 模式一方面是 AT 模式的补充。另外,更重要的价值在于,通过 MT 模式可以把众多非事务性资源纳入全局事务的管理中。

详细了解网址https://blog.csdn.net/qq924862077/article/details/86556559

参考网址:

https://blog.csdn.net/bjweimengshu/article/details/79607522
https://www.cnblogs.com/bigben0123/p/9453830.html

https://blog.csdn.net/jl19861101/article/details/54864019

上一篇:更改input【type=file】样式


下一篇:SpringEL 表达式错误记录