Java中事务类型有哪些

事务类型

本地事务

指仅操作单一事务资源、不需要全局事务管理器进行协调的事务。只适用于当个服务使用单个数据源的场景。事务的开启、终止、提交、回滚、嵌套、设置隔离级别、事务传播方式，全部都要依赖底层数据源的支持才能工作。实现了原子性、持久性、隔离性（ACID）。

全局事务

一种适用于单个服务使用多个数据源场景的事务解决方案（分布式环境中仍追求强一致性的事务处理方案）。java中的全局事务事务解决方案：

JTA（基于XA）

主要的由事务管理器接口、满足XA定义的资源定义接口组成。一般情况下由javaEE容器（JBoss、WebSphere、WEbLogic等）提供支持，目前也实现了以jar包的形式实现了JTA的接口使得JavaSE环境（Tomcat、Jetty等）下也能使用JTA。
XA将事务提交拆分成两个阶段过程：

准备阶段

协调者询问参与者是否准备好提交，对于数据来说，将在 redo log中记录全部事务提交操作所要做的内容，与本地事务真正提交的区别只是暂不写入最后一条commit record。

提交阶段

协调者在上一阶段收到所要参与者 prepared 消息后，先自己本地持久化事务状态为commit，然后向所有参与者发送commit指令。只要有一个参与者回复了 Non-Prepared 消息，协调者将自己的事务状态持久化为 abort 状态之后，向所有参与者发送 Abort 指令。
两段式提交原理简单，但有几个显著缺点：单点问题、性能问题、一致性风险。为了缓解协调者的单点问题和准备阶段的性能问题，发展出了三段式提交协议：分别为
Cancommit、PreCommit、DoCommit，新增的CanCommit 协调者让参与者根据自身状态，评估事务是否可能顺利完成。如果得到正面响应，事务成功提交的把握就比较大，参与者提交发生崩溃的风险相对就较小。同时由于多了一次询问，性能要差一些。

共享事务

指多个服务共用同一个数据源。理论可行的方案是多个服务通过数据库代理来间接的访问数据库，多个服务的事务通过数据库代理的本地事务的方式来完成。但是，这种方案与实际生产环境的压力方向相悖，实际应用并不提倡。

分布式事务

指多个服务同时访问多个数据源的事务处理机制。分布式系统中，涉及共享数据问题时，一致性（c）、可用性（a）、分区容错性（p）只能满足其中两个(cap定理) 。而 p 是分步式系统的天然属性，除非涉及金钱交易的服务，宁可中断也不能出错，否则多数系统是不能容忍节点越多可用性反而越低的，所以，选择放弃（强）一致性的（ap），降低为追求“最终一致性” 成了分布式系统是设计分布式系统的主流选择。
解决方案有：

可靠事件队列

在系统中建立一个消息服务，定时轮询信息表，将状态是“进行中”的消息发送到子服务，直到将状态更新为“已完成”，达到最终一致性。可靠消息队列只要第一步业务完成了，后续没有失败回滚的概念。可靠消息队列虽然实现了最终一致性，但是缺乏隔离性。rocketMQ 原生支持分布式事务操作。

TCC

缺乏隔离性会带来一个显而易见的问题是“超售”。如果业务需要隔离，应该终点考虑TCC。 TCC又分为三个阶段：

• Try，尝试阶段
  完成所有业务的检查（保障一致性），并且预留好全部需用到的业务资源（保障隔离性）
• Confirm，确认阶段
  使用Try阶段准备的资源来完成业务处理。可能会重复执行，本阶段所有操作需要具备幂等性。
• Cancel,取消执行阶段
  释放Try阶段预留的业务资源，可能会重复执行，本阶段所有操作需要具备幂等性。
  TCC位于用户代码层皮，灵活性较高，执行时只操作预留资源，几乎不涉及锁和资源的争用，性能潜力高。但是带来了更高的开发成本和业务侵入，意味着更高的开发成本和更高替换事务方案的成本。实现方案有阿里的seata。

SAGA，长时间事务

基于补偿来代替回滚的思路，把一个大事务分解为可以交错运行的一系列子事务集合。SAGA有两个部分组成：
大事务拆分出来的若干小事务（Ti）。每个子事务都应该是或者能被认为是原子行为。
为每一个子事务设计的对应的补偿动作（Ci），Ti 与 Ci 满足交换律，即先执行 Ti 还是 先执行 Ci ，效果都是一样的。Ci必须能成功提交，不考虑Ci本身提交失败被回滚的情形。
如果，T1到 Tn均提交成功，事务完成，否则有两种情形：

• 正向恢复，Ti 失败，则对 Ti 重试，直至成功（最大努力交付）。正向恢复不需要补偿。
• 反向恢复，如果Ti提交是吧，则对Ti执行对应的补偿动作Ci，直至成功（最大努力交付）。Ci 执行成功之后，已经执行子事务的补偿动作也要执行完，直到C0执行成功。
  Seata 支持 SAGA。

进阶干货