Spring Cloud与分布式事务

X/Open DTP模型

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

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

• 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请求，取消这个操作。

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）的子事务。