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

什么是分布式事物

分布式系统中保证不一样节点之间的数据一致性的事物，叫作分布式事物。

为何要用分布式事物

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

service多个节点

resource多个节点

 

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

如何用分布式事物

分布式事物解决方案

XA二阶段提交

1.性能问题

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

2.协调者单点故障问题

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

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

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

XA三阶段提交

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

MQ事务

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

 

本地消息表

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

 

Saga事务

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

 

LCN事务

LCN模式是经过代理Connection的方式实现对本地事务的操做，而后在由TxManager统一协调控制事务。当本地事务提交回滚或者关闭链接时将会执行假操做，该代理的链接将由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操做功能需业务提供，开发成本高。

到底要不要使用TCC到底要不要使用TCC事务，取决于如下几点：

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

Fescar

优势

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

缺点

存在一些局限，好比：事务隔离级别最高支持到 读已提交 的水平，SQL 的解析还不能涵盖所有的语法等。

分为AT模式和MT模式，默认的是AT模式，可是最好是AT模式和MT模式结合使用，由于MT模式能够将非关系型数据库也归入全局事务管理中。

AT模式的行为分支

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

MT模式的行为分支

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

 

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