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