Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

第二期 作业五:理解并完成 ShardingSphere 5.x 对 JTA 事务支持 #13

Open
mercyblitz opened this issue Apr 16, 2023 · 3 comments

Comments

@mercyblitz
Copy link
Owner

要求

  1. (必须)ShardingSphere 5.x 是如何支持 JTA (分布式)事务

  2. (可选)ShardingSphere 5.x 是如何整合 JTA 框架 Atomikos

提示:参考代码:https://github.com/apache/shardingsphere

@liqi19950722
Copy link

liqi19950722 commented Apr 18, 2023

https://github.com/liqi19950722/Work/tree/master/work-2-05
我的理解:
只要把任何资源实现为XAResource,比如OSS存储,NoSQL,Message等等
再通过javax.transaction.Transaction#enlistResourcejavax.transaction.Transaction#delistResource,把XAResource交由JTA管理,即可实现通用事务管理
我的理解没错的话ShardingSphere其实没必要DecoratorJTA的实现,实现XAResource即可
JTA4.2Transaction Association and Connection RequestFlow
image

说句题外话 通过学习EJB JDBC JTA规范有如下感受:

  1. 在Java领域,分布式事务从EJB出现之后一直都存在,解决了EJB分开部署的问题,但是不好理解,也有IBM和Oracle等厂商提供实现(付费)
  2. 在之后的某一段时间内(可能是硬件高速发展), 所有的Bean都能在一个容器下部署,分布式事务变成本地事务(Spring)
  3. 现阶段,面对数据量大幅增长的情况,又不得不通过微服务等方式分开部署,分布式事务又重新回到开发的视野中
  4. 根据文献,JTA实现需要事务状态与线程绑定,可能没法应对高并发场景,,或者像大多数文章说的,可能有单点问题,需要通过别的方式解决
    article

其实还有一个比较有意思的事情:
我曾经在海澜之家买过衣服,场景很简单就是我买完衣服3天内送积分。
如果按照JTA事务,是不是会发生下完单等支付,支付完等积分发送(最多3天),最后才完成整个流程。这样是不是有点傻呢~~~可能缓存双写用JTA还适合一点
我觉得开发要做的是合理划分事务边界,而不是扯怎么去实现分布式事务

@Owenxh
Copy link

Owenxh commented Apr 18, 2023

有小伙伴已经对 ShardingSphere JTA 部分相了相对应的源码分析。以下内容,作为个人观点,对 ShardingSphere 为什么会这样实现做相对应的分析。

ShardingSphere 作为一个数据库层面的中间件,其关注点在于:
● 灵活适配数据库协议,如 MySQL、MariaDB、PostgreSQL 等;
● 连接应用程序和异构数据库;
● 数据库访问入口的能力增强,如数据安全、数据治理以及可观测性能力的增强;
● 微内核以及可插拔模式,开发者可根据自身需求高度定制。

其目标愿景决定了其产品的特点。
● 多数据库协议的兼容
从多数据库协议的适配兼容上来说,决定了其代码需要具备高度可扩展性,或者说需要提供可配制化的能力,而所谓的配置化,将选择权交给了用户。其对 Java 原生 SPI 增强的 TypedSPILoader 为用户提供了这样选择权,选择什么样的数据库在于用户。

X/Open XA 作为标准的分布式事务协议,像 MySQL 实现了这样的能力。JTA 规范也有针对 XA 事务的实现提供了 API 约定,不同的厂商针对 JTA 提供了不同的产品实现,ShardingSphere 本身并不实现 JTA 标准,但其提供了对 JTA 能力的支持,如 Atomikos,ShardingSphere 定义了其内部统一的 ShardingSphereTransactionManager 接口,对应的有 XAShardingSphereTransactionManager,ShardingSphere 本身并没有像 Spring 那样对 JTA 事务的集成做相对应的模板封装,其意在提供原生 JTA XA 事务能力的一对一映射,只将相对应的事务操作委派给对应的 XA 实现 Provider,如 Atomikos。

Spring 意在使 Java 应用开发本身变得更简单,让开发者更关注于业务逻辑本身,而不是将重心放在如何将应用程序与基础软件如中间件等进行集成。

以上,是个人对 ShardingSphere 对 JTA 能力支持最终呈现形态的分析,主要从其产品定位出发,探讨其与 Spring JTA 实现的差异。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants