Spring Cloud与分布式事务

文章目录

  • X/Open DTP模型
  • OSI TP与2PC
  • XA接口与JTA
  • CAP与BASE定理
  • Java事务编程接口JTA
  • 分布式事务TCC模式
    • 定义
    • TCC与2PC
    • TCC与ACID
  • 分布式事务SAGA模式

X/Open DTP模型

DTP: Distributed Transaction Processing模型,用来规范全局事务处理。

Spring Cloud与分布式事务_第1张图片

如上图所示,它定义了几个组件,分别如下:

  • AP:Application Program,应用程序。即需要使用分布式事务的应用服务。
  • RM:Resource Manager,资源管理器。比如数据库或文件系统,通过对共享资源的访问,保障资源的ACID特性。
  • TM:Transaction Manager,事务管理器。主要给事务分配唯一标识,负责事务的启动、提交及回滚,保障全局事务的原子性。
  • CRMs: Communication Resource Managers,通信资源管理器。负责控制分布式应用在TM domain(一组使用同一个TM的实例集合)之内或跨TM domain之间的通信,该通信使用的是OSI TP服务。
  • 通信协议:即由通信资源管理器支持,在分布式应用使用的通信协议。

OSI TP与2PC

OSI TP提出了2PC协议。该协议具体内容如下:

  • 阶段一,TM请求所有的RM预提交各自的事务分支。RM如果能提交,则会记录相关端点事务日志;RM如果不能提交,则返回失败,同时回滚已经处理的操作,然后释放该事务分支的资源。
  • 阶段二,TM向所有的RM发送提交或回滚事务分支的请求。如果第一阶段RM返回的都是成功,则发送提交事务请求;否则只要有一个RM返回失败,就发送回滚事务请求。最后将反馈执行结果给TM,然后TM释放占用的相关资源。

2PC缺点如下:

  • 两阶段的工程都是同步阻塞的,需要等待各个参与者的响应,这会影响分布式事务的操作性能。
  • 单点故障:TM在整个过程中负载协调管理,如果它自身发生故障,那么RM就会阻塞状态,事务无法进行下去。
  • 在数据一致性方面,如果阶段二有部分RM在收到提交请求后提交了事务,部分RM由于网络异常等原因无法收到提交事务请求,就会造成数据不一致的问题。

XA接口与JTA

XA接口是X/Open DTP在2PC的基础上给TM与RM之间通信定义的接口。

在Java领域,J2EE(Java Enterprise Edition)定义了JTA(Java Transaction API)规范,具体见JSR 907,它遵循X/open XA接口,是高级版本的API规范。

JTS(Java Transaction Service):定义更底层的实现TM的相关接口,其中包括支持高级别的JTA接口以及标准的CORBA Object Transaction Service到Java的映射。JTS对于Java的XA事务规范,类似于JMS对于Java的消息中间件规范。

CAP与BASE定理

ACID的C主要关注的是数据在跨节点操作情况下的操作原子性,CAP的C关注的是同一份数据在多个副本之间同步的一致性。

BASE是Basically Available(基本可用)、Soft state(软状态)、Eventually consistent(最终一致性)这几个单纯的缩写。
数据一致性要做到满足ACID特性往往比较可能,于是BASE理论就提出在一些非严格要求强一致的应用场景下面,应用可以根据实际情况来达到最终一致性,其宗旨是通过牺牲强一致性来获取可用性。

使用XA事务来实现分布式事务,其可用性就比较差,于是业界提出了TCC及SAGA等解决方案,其思想和BASE定理类似,通过打破ACID特性中的一个或结果来提升分布式事务的可用性。

Java事务编程接口JTA

满足J2EE规范的容器支持了JTA规范,在纯J2SE领域,Spring Boot官方文档推荐了atomiskos、bitronix、narayana这三个组件。

  • atomitos:原子性。相应的spring-boot组件为spring-boot-starter-jta-atomikos。
  • bitronix: 是一款简单但是完整地实现了JTA1.1规范的事务管理器。相应的组件为spring-boot-starter-jta-bitronix。
  • arayana:它是jboss提供的一款分布式事务管理器,目前实现了JTA1.2版本的规范。

分布式事务TCC模式

定义

  • Tentative Operation: 为了在多个实体之间达成一致,要求一个实体必须能够接受另一个实体对请求执行的不确定性。比如,在发出执行操作请求之后又发出取消该操作的请求。这类后续可能取消的操作,就称为Tentative Operation。
  • Confirmation: 如果请求方认为Tentative Operation没问题,就可用发出Confirmation的执行请求,最终确定这个操作。
  • Cancellation:如果请求方决定撤回Tentative Operation,那么就可用发出Cancellation请求,取消这个操作。

Spring Cloud与分布式事务_第2张图片
TCC事务模型的三种状态:

  • Initial状态:最初始的状态,接到Try请求时变成Reserved状态。
  • Reserved状态:接到Confirm请求时变成Final状态,如果接受Cancel请求或等待超时则返回Initial状态。
  • Final状态:TCC事务成功状态。

TCC与2PC

将分布式事务场景,委托给各个业务场景去实现,将业务服务纳入到整个分布式事务当中。在出现不一致的场景的时候可以通过手工等方式介入。

TCC与ACID

TCC模式不满足Isolation特性,即TCC采用预留资源的方式来做try以及cancel操作,那么在达到final状态之前,其他事务读取处于中间状态资源的时候,读到的时“脏数据”。

TCC要求confirm、cancel操作必须是幂等的,因为实际场景会因为网络等原因导致这些操作被重试,因此TCC实现的是最终一致性的分布式事务。

分布式事务SAGA模式

LLT:Long Lived Transaction,指的是持有数据库资源相对较长的长活事务。

如果一个LLT可以被拆分为一序列可以跟其他事务交错执行(interleaved with)的子事务。

你可能感兴趣的:(分布式事务)