分布式事务理论及解决方案

程序员文章站 2022-07-14 12:35:12

...

分布式事务理论及java解决方案

前言

分布式事务是企业集成中的一个技术难点，也是每一个分布式系统架构中都会涉及到的一个东西，特别是在微服务架构中，几乎可以说是无法避免，本文就分布式事务来简单聊一下。

数据库事务

在说分布式事务之前，我们先从数据库事务说起。数据库事务可能大家都很熟悉，在开发过程中也会经常使用到。但是即使如此，可能对于一些细节问题，很多人仍然不清楚。比如很多人都知道数据库事务的几个特性：原子性(Atomicity )、一致性( Consistency )、隔离性或独立性( Isolation)和持久性(Durabilily)，简称就是ACID。但是再往下比如问到隔离性指的是什么的时候可能就不知道了，或者是知道隔离性是什么但是再问到数据库实现隔离的都有哪些级别，或者是每个级别他们有什么区别的时候可能就不知道了。

本文并不打算介绍这些数据库事务的这些东西，有兴趣可以搜索一下相关资料。不过有一个知识点我们需要了解，就是假如数据库在提交事务的时候突然断电，那么它是怎么样恢复的呢？为什么要提到这个知识点呢？因为分布式系统的核心就是处理各种异常情况，这也是分布式系统复杂的地方，因为分布式的网络环境很复杂，这种“断电”故障要比单机多很多，所以我们在做分布式系统的时候，最先考虑的就是这种情况。这些异常可能有机器宕机、网络异常、消息丢失、消息乱序、数据错误、不可靠的TCP、存储数据丢失、其他异常等等…

我们接着说本地事务数据库断电的这种情况，它是怎么保证数据一致性的呢？我们使用SQL Server来举例，我们知道我们在使用 SQL Server 数据库是由两个文件组成的，一个数据库文件和一个日志文件，通常情况下，日志文件都要比数据库文件大很多。数据库进行任何写入操作的时候都是要先写日志的，同样的道理，我们在执行事务的时候数据库首先会记录下这个事务的redo操作日志，然后才开始真正操作数据库，在操作之前首先会把日志文件写入磁盘，那么当突然断电的时候，即使操作没有完成，在重新启动数据库时候，数据库会根据当前数据的情况进行undo回滚或者是redo前滚，这样就保证了数据的强一致性。

接着，我们就说一下分布式事务。

分布式理论

当我们的单个数据库的性能产生瓶颈的时候，我们可能会对数据库进行分区，这里所说的分区指的是物理分区，分区之后可能不同的库就处于不同的服务器上了，这个时候单个数据库的ACID已经不能适应这种情况了，而在这种ACID的集群环境下，再想保证集群的ACID几乎是很难达到，或者即使能达到那么效率和性能会大幅下降，最为关键的是再很难扩展新的分区了，这个时候如果再追求集群的ACID会导致我们的系统变得很差，这时我们就需要引入一个新的理论原则来适应这种集群的情况，就是 CAP 原则或者叫CAP定理，那么CAP定理指的是什么呢？

CAP定理

CAP定理是由加州大学伯克利分校Eric Brewer教授提出来的，他指出WEB服务无法同时满足一下3个属性：

一致性(Consistency) ：客户端知道一系列的操作都会同时发生(生效)
可用性(Availability) ：每个操作都必须以可预期的响应结束
分区容错性(Partition tolerance) ：即使出现单个组件无法可用,操作依然可以完成
具体地讲在分布式系统中，在任何数据库设计中，一个Web应用至多只能同时支持上面的两个属性。显然，任何横向扩展策略都要依赖于数据分区。因此，设计人员必须在一致性与可用性之间做出选择。

这个定理在迄今为止的分布式系统中都是适用的！为什么这么说呢？

这个时候有同学可能会把数据库的2PC（两阶段提交）搬出来说话了。OK，我们就来看一下数据库的两阶段提交。

对数据库分布式事务有了解的同学一定知道数据库支持的2PC，又叫做 XA Transactions。

MySQL从5.5版本开始支持，SQL Server 2005 开始支持，Oracle 7 开始支持。

其中，XA 是一个两阶段提交协议，该协议分为以下两个阶段：

第一阶段：事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交.
第二阶段：事务协调器要求每个数据库提交数据。

其中，如果有任何一个数据库否决此次提交，那么所有数据库都会被要求回滚它们在此事务中的那部分信息。这样做的缺陷是什么呢? 咋看之下我们可以在数据库分区之间获得一致性。

如果CAP 定理是对的，那么它一定会影响到可用性。

如果说系统的可用性代表的是执行某项操作相关所有组件的可用性的和。那么在两阶段提交的过程中，可用性就代表了涉及到的每一个数据库中可用性的和。我们假设两阶段提交的过程中每一个数据库都具有99.9%的可用性，那么如果两阶段提交涉及到两个数据库，这个结果就是99.8%。根据系统可用性计算公式，假设每个月43200分钟，99.9%的可用性就是43157分钟, 99.8%的可用性就是43114分钟，相当于每个月的宕机时间增加了43分钟。

以上，可以验证出来，CAP定理从理论上来讲是正确的，CAP我们先看到这里，等会再接着说。

BASE理论

在分布式系统中，我们往往追求的是可用性，它的重要程序比一致性要高，那么如何实现高可用性呢？前人已经给我们提出来了另外一个理论，就是BASE理论，它是用来对CAP定理进行进一步扩充的。BASE理论指的是：

Basically Available（基本可用）
Soft state（软状态）
Eventually consistent（最终一致性）

BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

有了以上理论之后，我们来看一下分布式事务的问题。

分布式事务

在分布式系统中，要实现分布式事务，无外乎那几种解决方案。

一、两阶段提交（2PC）

和上一节中提到的数据库XA事务一样，两阶段提交就是使用XA协议的原理，我们可以从下面这个图的流程来很容易的看出中间的一些比如commit和abort的细节。

分布式事务理论及解决方案

两阶段提交这种解决方案属于牺牲了一部分可用性来换取的一致性。在实现方面，在 .NET 中，可以借助 TransactionScop 提供的 API 来编程实现分布式系统中的两阶段提交，比如WCF中就有实现这部分功能。不过在多服务器之间，需要依赖于DTC来完成事务一致性，Windows下微软搞的有MSDTC服务，Linux下就比较悲剧了。

另外说一句，TransactionScop 默认不能用于异步方法之间事务一致，因为事务上下文是存储于当前线程中的，所以如果是在异步方法，需要显式的传递事务上下文。

优点：尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不能100%保证强一致）

缺点：实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景，如果分布式系统跨接口调用，目前 .NET 界还没有实现方案。

java方案-Seata方案

Seata是由阿里中间件团队发起的开源项目 Fescar，后更名为Seata，它是一个是开源的分布式事务框架,现已集成到Spring Cloud Alibaba框架中。
传统2PC的问题在Seata中得到了解决，它通过对本地关系数据库的分支事务的协调来驱动完成全局事务，是工作在应用层的中间件。主要优点是性能较好，且不长时间占用连接资源，它以高效并且对业务0侵入的方式解决微服务场景下面临的分布式事务问题，它目前提供AT模式(即2PC)及TCC模式的分布式事务解决方案。
Seata的设计思想如下：
Seata的设计目标其一是对业务无侵入，因此从业务无侵入的2PC方案着手，在传统2PC的基础上演进，并解决2PC方案面临的问题。
Seata把一个分布式事务理解成一个包含了若干分支事务的全局事务。全局事务的职责是协调其下管辖的分支事务达成一致，要么一起成功提交，要么一起失败回滚。此外，通常分支事务本身就是一个关系数据库的本地事务，下图是全局事务与分支事务的关系图：
分布式事务理论及解决方案
与传统2PC 的模型类似，Seata定义了3个组件来协议分布式事务的处理过程：

Transaction Coordinator (TC)：事务协调器，它是独立的中间件，需要独立部署运行，它维护全局事务的运行状态，接收TM指令发起全局事务的提交与回滚，负责与RM通信协调各各分支事务的提交或回滚。
Transaction Manager ™：事务管理器，TM需要嵌入应用程序中工作，它负责开启一个全局事务，并最终向TC发起全局提交或全局回滚的指令。
Resource Manager (RM)：控制分支事务，负责分支注册、状态汇报，并接收事务协调器TC的指令，驱动分支（本地）事务的提交和回滚。
Seata实现2PC与传统2PC的差别：

架构层次方面，传统2PC方案的 RM 实际上是在数据库层，RM 本质上就是数据库自身，通过 XA 协议实现，而Seata的 RM 是以jar包的形式作为中间件层部署在应用程序这一侧的。

两阶段提交方面，传统2PC无论第二阶段的决议是commit还是rollback，事务性资源的锁都要保持到Phase2完成才释放。而Seata的做法是在Phase1 就将本地事务提交(rollback时框架自动生成并执行逆操作SQL,需要分别在分支事务操作的数据库中创建undo_log表，以记录原始事务SQL)，这样就可以省去Phase2持锁的时间，整体提高效率。

具体使用

1,分别在各事务数据库中创建undo_log表

CREATE TABLE `undo_log` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`branch_id` bigint(20) NOT NULL,
`xid` varchar(100) NOT NULL,
`context` varchar(128) NOT NULL,
`rollback_info` longblob NOT NULL,
`log_status` int(11) NOT NULL,
`log_created` datetime NOT NULL,
`log_modified` datetime NOT NULL,
`ext` varchar(100) DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `ux_undo_log` (`xid`,`branch_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

2,启动TC(事务协调器)
（1）下载seata服务器
下载地址：https://github.com/seata/seata/releases/download/v0.7.1/seata-server-0.7.1.zip
（2）解压并启动
[seata服务端解压路径]/bin/seata-server.bat -p 8888 -m file
注：其中8888为服务端口号；file为启动模式，这里指seata服务将采用文件的方式存储信息。

3,启动服务注册中心
4,微服务配置,增加依赖

<dependency>
	<groupId>com.alibaba.cloud</groupId>
	<artifactId>spring‐cloud‐alibaba‐dependencies</artifactId>
	<version>2.1.0.RELEASE</version>
	<type>pom</type>
	<scope>import</scope>
</dependency>

5,微服务配置seata

在src/main/resource中，新增registry.conf、file.conf文件，内容可拷贝seata-server-0.7.1中的配置文件。
在registry.conf中registry.type使用file.
在file.conf中更改service.vgroup_mapping.[springcloud服务名]-fescar-service-group = “default”，并修改service.default.grouplist =[seata服务端地址]

关于vgroup_mapping的配置：
vgroup_mapping.事务分组服务名=Seata Server集群名称（默认名称为default）
default.grouplist = Seata Server集群地址在 org.springframework.cloud:spring-cloud-starter-alibaba-seata 的org.springframework.cloud.alibaba.seata.GlobalTransactionAutoConfiguration 类中，默认会使用${spring.application.name}-fescar-service-group 作为事务分组服务名注册到 Seata Server上，如果和file.conf 中的配置不一致，会提示 no available server to connect 错误也可以通过配置 spring.cloud.alibaba.seata.tx-service-group 修改后缀，但是必须和file.conf 中的配置保持一致。

2)创建代理数据源
新增DatabaseConfiguration.java，Seata的RM通过DataSourceProxy才能在业务代码的事务提交时，通过这个切入点，与TC进行通信交互、记录undo_log等。

@Configuration
public class DatabaseConfiguration {
	@Bean
	@ConfigurationProperties(prefix = "spring.datasource.ds0")
	public DruidDataSource ds0() {
		DruidDataSource druidDataSource = new DruidDataSource();
		return druidDataSource;
	}
	@Primary
	@Bean
	public DataSource dataSource(DruidDataSource ds0) {
		DataSourceProxy pds0 = new DataSourceProxy(ds0);
		return pds0;
	}
}

事务注解
@GlobalTransactional //seata注解
@Transactional //Spring注解,所有本地事务上标注
将@GlobalTransactional注解标注在全局事务发起的Service实现方法上，开启全局事务：

GlobalTransactionalInterceptor会拦截@GlobalTransactional注解的方法，生成全局事务ID(XID)，XID会在整个分布式事务中传递。
在远程调用时，spring-cloud-alibaba-seata会拦截Feign调用将XID传递到下游服务。

二、补偿事务（TCC）

TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。它分为三个阶段：

Try 阶段主要是对业务系统做检测及资源预留

Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。

Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。

举个例子，假入 Bob 要向 Smith 转账，思路大概是：
我们有一个本地方法，里面依次调用
1、首先在 Try 阶段，要先调用远程接口把 Smith 和 Bob 的钱给冻结起来。
2、在 Confirm 阶段，执行远程调用的转账的操作，转账成功进行解冻。
3、如果第2步执行成功，那么转账成功，如果第二步执行失败，则调用远程冻结接口对应的解冻方法 (Cancel)。

优点：跟2PC比起来，实现以及流程相对简单了一些，但数据的一致性比2PC也要差一些

缺点：缺点还是比较明显的，在2,3步中都有可能失败。TCC属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，在一些场景中，一些业务流程可能用TCC不太好定义及处理。

java方案-TCC框架Hmily

目前市面上的TCC框架众多比如下面这几种：
（以下数据采集日为2019年07月11日）

框架名称	Gitbub地址	star数量
tcc-transaction	https://github.com/changmingxie/tcc-transaction	3850
Hmily	https://github.com/yu199195/hmily	2407
ByteTCC	https://github.com/liuyangming/ByteTCC	1947
EasyTransaction	https://github.com/QNJR-GROUP/EasyTransaction	1690

阿里的Seata也支持TCC，但Seata的TCC模式对Spring Cloud并没有提供支持。
Hmily是一个高性能分布式事务TCC开源框架。基于Java语言来开发（JDK1.8），支持Dubbo，Spring Cloud等RPC框架进行分布式事务。它目前支持以下特性：

支持嵌套事务(Nested transaction support).
采用disruptor框架进行事务日志的异步读写，与RPC框架的性能毫无差别。
支持SpringBoot-starter 项目启动，使用简单。
RPC框架支持 : dubbo,motan,springcloud。
本地事务存储支持 : redis,mongodb,zookeeper,file,mysql。
事务日志序列化支持：java，hessian，kryo，protostuff。
采用Aspect AOP 切面思想与Spring无缝集成，天然支持集群
RPC事务恢复，超时异常恢复等。

Hmily利用AOP对参与分布式事务的本地方法与远程方法进行拦截处理，通过多方拦截，事务参与者能透明的调用到另一方的Try、Confirm、Cancel方法；传递事务上下文；并记录事务日志，酌情进行补偿，重试等。
Hmily不需要事务协调服务，但需要提供一个数据库(mysql/mongodb/zookeeper/redis/file)来进行日志存储。
Hmily实现的TCC服务与普通的服务一样，只需要暴露一个接口，也就是它的Try业务。Confirm/Cancel业务逻辑，只是因为全局事务提交/回滚的需要才提供的，因此Confirm/Cancel业务只需要被Hmily TCC事务框架发现即可，不需要被调用它的其他业务服务所感知。
官网介绍：https://dromara.org/website/zh-cn/docs/hmily/index.html
TCC需要注意三种异常处理分别是空回滚、幂等、悬挂:
空回滚：
在没有调用 TCC 资源 Try 方法的情况下，调用了二阶段的 Cancel 方法，Cancel 方法需要识别出这是一个空回滚，然后直接返回成功。
出现原因是当一个分支事务所在服务宕机或网络异常，分支事务调用记录为失败，这个时候其实是没有执行Try阶段，当故障恢复后，分布式事务进行回滚则会调用二阶段的Cancel方法，从而形成空回滚。
解决思路是关键就是要识别出这个空回滚。思路很简单就是需要知道一阶段是否执行，如果执行了，那就是正常回滚；如果没执行，那就是空回滚。前面已经说过TM在发起全局事务时生成全局事务记录，全局事务ID贯穿整个分布式事务调用链条。再额外增加一张分支事务记录表，其中有全局事务 ID 和分支事务 ID，第一阶段 Try 方法里会插入一条记录，表示一阶段执行了。Cancel 接口里读取该记录，如果该记录存在，则正常回滚；如果该记录不存在，则是空回滚。
幂等：
通过前面介绍已经了解到，为了保证TCC二阶段提交重试机制不会引发数据不一致，要求 TCC 的二阶段 Try、Confirm 和 Cancel 接口保证幂等，这样不会重复使用或者释放资源。如果幂等控制没有做好，很有可能导致数据不一致等严重问题。
解决思路在上述“分支事务记录”中增加执行状态，每次执行前都查询该状态。
悬挂：
悬挂就是对于一个分布式事务，其二阶段 Cancel 接口比 Try 接口先执行。
出现原因是在 RPC 调用分支事务try时，先注册分支事务，再执行RPC调用，如果此时 RPC 调用的网络发生拥堵，通常 RPC 调用是有超时时间的，RPC 超时以后，TM就会通知RM回滚该分布式事务，可能回滚完成后，RPC 请求才到达参与者真正执行，而一个 Try 方法预留的业务资源，只有该分布式事务才能使用，该分布式事务第一阶段预留的业务资源就再也没有人能够处理了，对于这种情况，我们就称为悬挂，即业务资源预留后没法继续处理。
解决思路是如果二阶段执行完成，那一阶段就不能再继续执行。在执行一阶段事务时判断在该全局事务下，“分支事务记录”表中是否已经有二阶段事务记录，如果有则不执行Try。
综上:
使用hmily需要创建hmily数据库，用于存储hmily框架记录的数据,自动调用。
每个本地事务数据库都创建try、confirm、cancel三张日志表,用于手动进行空回滚,幂等和悬挂的判定,(华为ServiceComb下的pack异步框架正在实现以上的自动判定,期待O(∩_∩)O)：

使用

单独创建hmily数据库,配置时会使用到
每个微服务本地事务数据库都创建try、confirm、cancel三张日志表:

CREATE TABLE `local_try_log` (
	`tx_no` varchar(64) NOT NULL COMMENT '事务id',
	`create_time` datetime DEFAULT NULL,
	PRIMARY KEY (`tx_no`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
CREATE TABLE `local_confirm_log` (
	`tx_no` varchar(64) NOT NULL COMMENT '事务id',
	`create_time` datetime DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8
CREATE TABLE `local_cancel_log` (
	`tx_no` varchar(64) NOT NULL COMMENT '事务id',
	`create_time` datetime DEFAULT NULL,
PRIMARY KEY (`tx_no`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

每个微服务引入maven依赖

<dependency>
	<groupId>org.dromara</groupId>
	<artifactId>hmily‐springcloud</artifactId>
	<version>2.0.4‐RELEASE</version>
</dependency>

3)微服务配置hmily
application.yml：

org:
	dromara:
		hmily :
			serializer : kryo
			recoverDelayTime : 128
			retryMax : 30
			scheduledDelay : 128
			scheduledThreadMax : 10
			repositorySupport : db
			started: true
			hmilyDbConfig :
				driverClassName : com.mysql.jdbc.Driver
				url : jdbc:mysql://localhost:3306/hmily?useUnicode=true
				username : root
				password : root

新增配置类接收application.yml中的Hmily配置信息，并创建HmilyTransactionBootstrap Bean：

@Bean
public HmilyTransactionBootstrap hmilyTransactionBootstrap(HmilyInitService hmilyInitService){
	HmilyTransactionBootstrap hmilyTransactionBootstrap = new
HmilyTransactionBootstrap(hmilyInitService);
	hmilyTransactionBootstrap.setSerializer(env.getProperty("org.dromara.hmily.serializer"));			 			   
	hmilyTransactionBootstrap.setRecoverDelayTime(Integer.parseInt(env.getProperty("org.dromara.hmily.recoverDelayTime")));
	hmilyTransactionBootstrap.setRetryMax(Integer.parseInt(env.getProperty("org.dromara.hmily.retryMax")));
	hmilyTransactionBootstrap.setScheduledDelay(Integer.parseInt(env.getProperty("org.dromara.hmily.scheduledDelay")));
	hmilyTransactionBootstrap.setScheduledThreadMax(Integer.parseInt(env.getProperty("org.dromara.hmily.scheduledThreadMax")));
	hmilyTransactionBootstrap.setRepositorySupport(env.getProperty("org.dromara.hmily.repositorySupport"));
	hmilyTransactionBootstrap.setStarted(Boolean.parseBoolean(env.getProperty("org.dromara.hmily.started")));
	HmilyDbConfig hmilyDbConfig = new HmilyDbConfig();
	hmilyDbConfig.setDriverClassName(env.getProperty("org.dromara.hmily.hmilyDbConfig.driverClassName"));
	hmilyDbConfig.setUrl(env.getProperty("org.dromara.hmily.hmilyDbConfig.url"));
	hmilyDbConfig.setUsername(env.getProperty("org.dromara.hmily.hmilyDbConfig.username"));
	hmilyDbConfig.setPassword(env.getProperty("org.dromara.hmily.hmilyDbConfig.password"));
	hmilyTransactionBootstrap.setHmilyDbConfig(hmilyDbConfig);
	return hmilyTransactionBootstrap;
}

启动类增加@EnableAspectJAutoProxy并增加org.dromara.hmily的扫描项：

@SpringBootApplication
@EnableDiscoveryClient
@EnableHystrix
@EnableFeignClients(basePackages = {"项目Feign路径"})
@ComponentScan({"项目包路径","org.dromara.hmily"})
public class Bank1HmilyServer {
	public static void main(String[] args) {
		SpringApplication.run(Bank1HmilyServer.class, args);
	}
}

开始愉快地使用事务
@Transactional Spring注解,所有TCC方法标注
@Hmily(confirmMethod = “commit”, cancelMethod = “rollback”) Hmily注解,标在所有T方法上
@Hmily Hmily注解,标在feignClient接口内方法上.表示服务调用方开启分布式事务
关于TCC三个方法
需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。
全部方法要依据数据库中的三张表判断幂等,回滚要结合T表防止空回滚,T要结合cancel表防止悬挂.
原事务拆成T和提交两阶段,要考虑T可以在回滚方法中异步反向操作,例如转帐案例,扣款需放在T中,加钱需放在commit中,防止中间有并发消费掉钱而不能回滚.T可以为空,只有检查网络和系统状态的作用.总之尽量避免确认或者回滚不了的情况.

三、本地消息表（异步确保）

本地消息表这种实现方式应该是业界使用最多的，其核心思想是将分布式事务拆分成本地事务进行处理，这种思路是来源于ebay。我们可以从下面的流程图中看出其中的一些细节：

分布式事务理论及解决方案

基本思路就是：

消息生产方，需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交，也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送失败，会进行重试发送。

消息消费方，需要处理这个消息，并完成自己的业务逻辑。此时如果本地事务处理成功，表明已经处理成功了，如果处理失败，那么就会重试执行。如果是业务上面的失败，可以给生产方发送一个业务补偿消息，通知生产方进行回滚等操作。

生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一遍。如果有靠谱的自动对账补账逻辑，这种方案还是非常实用的。

这种方案遵循BASE理论，采用的是最终一致性，笔者认为是这几种方案里面比较适合实际业务场景的，即不会出现像2PC那样复杂的实现(当调用链很长的时候，2PC的可用性是非常低的)，也不会像TCC那样可能出现确认或者回滚不了的情况。

优点：一种非常经典的实现，避免了分布式事务，实现了最终一致性。在 .NET中有现成的解决方案。

缺点：消息表会耦合到业务系统中，如果没有封装好的解决方案，会有很多杂活需要处理。

java中可以基于定时任务框架加MQ中间件,手动实现

举例:

1,基于RabbitMQ设计任务表,一式三份,保证消息发送和事务的原子性
生产方待处理任务表,生产方已完成任务表,消费方的历史任务表,记得区分表名O(∩_∩)O
分布式事务理论及解决方案
在任务表中包括了交换机的名称、路由key等信息为了是将任务的处理做成一个通用的功能。一组事务需要一个交换机,用两个key绑定两个队列(通知,完成反馈).
考虑分布式系统并发读取任务处理任务的情况发生项目使用乐观锁的方式解决并发问题。
2,：生产方待处理任务表
定时任务发送消息流程如下：

定时任务扫描task表，一次取出多个任务，取出超过定时时间未处理的任务
考虑生产方服务可能集群部署，为避免重复发送任务使用乐观锁的方式每次从任务列表取出要处理的任务
1. 每次取任务时判断当前版本及任务id是否匹配，如果匹配则执行任务，如果不匹配则取消执行。
2. 如果当前版本和任务Id可以匹配到任务则更新当前版本加1.此处用到了Spring Data JPA的**:变量**

	@Modifying
	@Query("update XcTask t set t.version = :version+1 where t.id = :id and t.version = :version")

任务发送完毕更新任务发送时间

3，消费方的历史任务表,校对幂等,发起成功反馈消息.

3,生产方已完成任务表,为保证后期对账.
生产方接到消费反馈后,将消息表的消息先添加到历史消息表再删除消息，表示此消息已经完成。

在异步情况下,方案未考虑消费持续失败,可以考虑人工干预;如果存在回滚需求,可以通过生产方监听反馈消息进行业务补偿回滚.

四、MQ 事务消息

有一些第三方的MQ是支持事务消息的，比如RocketMQ，他们支持事务消息的方式也是类似于采用的二阶段提交，但是市面上一些主流的MQ都是不支持事务消息的，比如 RabbitMQ 和 Kafka 都不支持。

以阿里的 RocketMQ 中间件为例，其思路大致为：

第一阶段Prepared消息，会拿到消息的地址。
第二阶段执行本地事务，第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。

也就是说在业务方法内要想消息队列提交两次请求，一次发送消息和一次确认消息。如果确认消息发送失败了RocketMQ会定期扫描消息集群中的事务消息，这时候发现了Prepared消息，它会向消息发送者确认，所以生产方需要实现一个check接口，RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。

分布式事务理论及解决方案

遗憾的是，RocketMQ并没有 .NET 客户端。

优点：实现了最终一致性，不需要依赖本地数据库事务。

缺点：实现难度大，主流MQ不支持，没有.NET客户端，RocketMQ事务消息部分代码也未开源。

RocketMQ事务消息方案

RocketMQ 是一个来自阿里巴巴的分布式消息中间件，于 2012 年开源，并在 2017 年正式成为 Apache *项目。据了解，包括阿里云上的消息产品以及收购的子公司在内，阿里集团的消息产品全线都运行在 RocketMQ 之上，并且最近几年的双十一大促中，RocketMQ 都有抢眼表现。Apache RocketMQ 4.3之后的版本正式支持事务消息，为分布式事务实现提供了便利性支持。
RocketMQ 事务消息设计则主要是为了解决 Producer 端的消息发送与本地事务执行的原子性问题，RocketMQ 的设计中 broker 与 producer 端的双向通信能力，使得 broker 天生可以作为一个事务协调者存在；而 RocketMQ本身提供的存储机制为事务消息提供了持久化能力；RocketMQ 的高可用机制以及可靠消息设计则为事务消息在系统发生异常时依然能够保证达成事务的最终一致性。
在RocketMQ 4.3后实现了完整的事务消息，实际上其实是对本地消息表的一个封装，将本地消息表移动到了MQ内部，解决 Producer 端的消息发送与本地事务执行的原子性问题。
分布式事务理论及解决方案

使用:

1,在各本地数据库中新增de_duplication交易记录表(去重表)，用于交易幂等控制。

DROP TABLE IF EXISTS `de_duplication`;
CREATE TABLE `de_duplication` (
	`tx_no` varchar(64) COLLATE utf8_bin NOT NULL,
	`create_time` datetime(0) NULL DEFAULT NULL,
	PRIMARY KEY (`tx_no`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_bin ROW_FORMAT = Dynamic;

2,事务消息使用不再详解,参考我另一篇RocketMQ总结文章,注意几点:
1),发起事务消息与本地事务分离.通过MQ自动回调和回查实现通知的原子性
2),编写RocketMQLocalTransactionListener接口实现类，实现消息成功回调方法(调用service执行本地事务)和事务回查两个方法。
回调方法和service事务方法都加@Transactional
3) service事务方法执行本地事务并更新本地事务表,事务回查方法据此回查,控制幂等.
4)消费方,service事务方法需控制幂等,防止重复消费
最大努力通知方案：
目标：发起通知方通过一定的机制最大努力将业务处理结果通知到接收方。
具体包括：
1、有一定的消息重复通知机制。
因为接收通知方可能没有接收到通知，此时要有一定的机制对消息重复通知。一般MQ都已实现
2、消息校对机制。
如果尽最大努力也没有通知到接收方，或者接收方消费消息后要再次消费，此时可由接收方主动向通知方查询消息信息来满足需求。需要业务手动实现回查,消费控制幂等

以上各种分布式事务对比分析:

各种方案的优缺点：
2PC 最大的诟病是一个阻塞协议。RM在执行分支事务后需要等待TM的决定，此时服务会阻塞并锁定资源。由于其阻塞机制和最差时间复杂度高，因此，这种设计不能适应随着事务涉及的服务数量增加而扩展的需要，很难用于并发较高以及子事务生命周期较长 (long-running transactions) 的分布式服务中。
如果拿TCC事务的处理流程与2PC两阶段提交做比较，2PC通常都是在跨库的DB层面，而TCC则在应用层面的处理，需要通过业务逻辑来实现。这种分布式事务的实现方式的优势在于，可以让应用自己定义数据操作的粒度，使得降低锁冲突、提高吞吐量成为可能。而不足之处则在于对应用的侵入性非常强，业务逻辑的每个分支都需要实现try、confirm、cancel三个操作。此外，其实现难度也比较大，需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。典型的使用场景：满，登录送优惠券等。
可靠消息最终一致性事务适合执行周期长且实时性要求不高的场景。引入消息机制后，同步的事务操作变为基于消息执行的异步操作, 避免了分布式事务中的同步阻塞操作的影响，并实现了两个服务的解耦。典型的使用场景：注册送积分，登录送优惠券等。
最大努力通知是分布式事务中要求最低的一种,适用于一些最终一致性时间敏感度低的业务；允许发起通知方处理业务失败，在接收通知方收到通知后积极进行失败处理，无论发起通知方如何处理结果都会不影响到接收通知方的后续处理；发起通知方需提供查询执行情况接口，用于接收通知方校对结果。典型的使用场景：银行通知、支付结果通知等。

	2PC	TCC	可靠消息	最大努力通知
一致性	强一致性	最终一致	最终一致	最终一致
吞吐量	低	中	高	高
实现复杂度	易	难	中	易

总结：
在条件允许的情况下，我们尽可能选择本地事务单数据源，因为它减少了网络交互带来的性能损耗，且避免了数据弱一致性带来的种种问题。若某系统频繁且不合理的使用分布式事务，应首先从整体设计角度观察服务的拆分是否合理，是否高内聚低耦合？是否粒度太小？分布式事务一直是业界难题，因为网络的不确定性，而且我们习惯于拿分布式事务与单机事务ACID做对比。
无论是数据库层的XA、还是应用层TCC、可靠消息、最大努力通知等方案，都没有完美解决分布式事务问题，它们不过是各自在性能、一致性、可用性等方面做取舍，寻求某些场景偏好下的权衡。

五、Sagas 事务模型

Saga事务模型又叫做长时间运行的事务（Long-running-transaction）, 它是由普林斯顿大学的H.Garcia-Molina等人提出，它描述的是另外一种在没有两阶段提交的的情况下解决分布式系统中复杂的业务事务问题。你可以在这里看到 Sagas 相关论文。

我们这里说的是一种基于 Sagas 机制的工作流事务模型，这个模型的相关理论目前来说还是比较新的，以至于百度上几乎没有什么相关资料。

该模型其核心思想就是拆分分布式系统中的长事务为多个短事务，或者叫多个本地事务，然后由 Sagas 工作流引擎负责协调，如果整个流程正常结束，那么就算是业务成功完成，如果在这过程中实现失败，那么Sagas工作流引擎就会以相反的顺序调用补偿操作，重新进行业务回滚。

比如我们一次关于购买旅游套餐业务操作涉及到三个操作，他们分别是预定车辆，预定宾馆，预定机票，他们分别属于三个不同的远程接口。可能从我们程序的角度来说他们不属于一个事务，但是从业务角度来说是属于同一个事务的。

分布式事务理论及解决方案

他们的执行顺序如上图所示，所以当发生失败时，会依次进行取消的补偿操作。

因为长事务被拆分了很多个业务流，所以 Sagas 事务模型最重要的一个部件就是工作流或者你也可以叫流程管理器（Process Manager），工作流引擎和Process Manager虽然不是同一个东西，但是在这里，他们的职责是相同的。在选择工作流引擎之后，最终的代码也许看起来是这样的

SagaBuilder saga = SagaBuilder.newSaga("trip")
        .activity("Reserve car", ReserveCarAdapter.class) 
        .compensationActivity("Cancel car", CancelCarAdapter.class) 
        .activity("Book hotel", BookHotelAdapter.class) 
        .compensationActivity("Cancel hotel", CancelHotelAdapter.class) 
        .activity("Book flight", BookFlightAdapter.class) 
        .compensationActivity("Cancel flight", CancelFlightAdapter.class) 
        .end()
        .triggerCompensationOnAnyError();

camunda.getRepositoryService().createDeployment() 
        .addModelInstance(saga.getModel()) 
        .deploy();

这里有一个 C# 相关示例，有兴趣的同学可以看一下。

优缺点这里我们就不说了，因为这个理论比较新，目前市面上还没有什么解决方案。

servicecomb-saga

servicecomb是华为在apache上开源的微服务框架,正在集成到Spring Cloud Huawei中.其中servicecomb-saga
其微服务应用的数据最终一致性解决方案，是一种基于在2PC和TCC两者之间的框架，简单的说是依赖协调器的TCC方式。

特性

高可用。支持集群模式。
高可靠。所有的事务事件都持久存储在数据库中。
高性能。事务事件是通过gRPC来上报的，且事务的请求信息是通过Kyro进行序列化和反序列化的。
低侵入。仅需2-3个注解和编写对应的补偿方法即可进行分布式事务。
部署简单。可通过Docker快速部署。
支持前向恢复（重试）及后向恢复（补偿）。

saga架构图 分布式事务理论及解决方案
具体使用可见: https://www.jianshu.com/p/268dfc7e4a52
这里有一篇2018年QConBeijing Saga分布式事务解决方案与实践演讲实录。http://servicecomb.apache.org/cn/docs/distributed-transactions-saga-implementation/

分布式事务理论及解决方案

分布式事务理论及java解决方案

前言

数据库事务

分布式理论

CAP定理

BASE理论

分布式事务

一、两阶段提交（2PC）

java方案-Seata方案

二、补偿事务（TCC）

java方案-TCC框架Hmily

三、本地消息表（异步确保）

举例:

四、MQ 事务消息

RocketMQ事务消息方案

以上各种分布式事务对比分析:

五、Sagas 事务模型

servicecomb-saga

深入理解PHP+Mysql分布式事务与解决方案

分布式事务之解决方案（可靠消息最终一致性）

分布式事务，解决方案

PHP+Mysql分布式事务与解决方案深入理解

微服务架构的分布式事务解决方案

聊聊分布式事务，再说说解决方案