Loading

你必须掌握的分布式事务知识点

1. 基础概念

1.1 什么是事务

一组操作，要么全部执行成功，要么都失败

1.2 本地事务

利用关系型数据的事务特性实现。

事务特性：

原子性：

一致性：

隔离性：

持久性：

1.3 分布式事务

分布式环境下由不同服务之间通过网络协作完成事务，称之为分布式事务。例如用户注册送积分事务、创建订单减库存事务、银行转账事务等都是分布式事务。

自己的理解：组成事务的操作，需要通过网络调用完成。

我们知道本地事务依赖数据库本身提供的事务特性来实现，因此以下逻辑可以控制本地事务：

begin transaction； 
  //1.本地数据库操作：张三减少金额 
  //2.本地数据库操作：李四增加金额 
commit transation;

但是在分布式环境下，会变成下边这样：

begin transaction； 
  //1.本地数据库操作：张三减少金额 
  //2.远程调用：让李四增加金额 
commit transation;

1.4 分布式事务场景

分布式事务问题：无法用本地数据库控制事务

1、微服务架构

2、单体架构访问多个数据库实例

3、多服务访问同一个数据库实例

两个微服务持有了不同的数据库连接，进行数据库操作

评估和诊断、评估和压疮保持

2. 分布式事务基础理论

2.1 理解CAP

通过电商系统理解CAP

商品信息

image-20200615210159448

CAP各是什么？有什么结论

只能在AP和CP选。

AP使用较多，BASE理论基于AP。

CP，Zookeeper，强一致性要求。转账。

2.2 BASE理论

BASE理论指的是？

基本可用：核心功能可用

软状态：中间状态

最终一致：经过一段时间，数据可以达到一致。

什么是强一致性？什么是最终一致？

满足BASE理论的事务，叫做柔性事务。

3. 分布式事务解决方案之2PC

3.1 什么是2PC

准备阶段和提交阶段

角色：事务管理者、事务参与者

结合案例描述一下2PC过程？

比如，写数据到数据库后，发送日志给MQ系统，如何使用2PC完成。（可靠消息最终一致性之本地消息表方案）

image-20200616103246516

3.2 解决方案

3.2.1 XA方案

什么是XA？

DTP(分布式事务处理模型)定义的TM和RM之间通讯的接口规范叫做XA。

基于XA协议来实现2PC又称为XA方案。

DTP模型定义的角色及执行流程？

AP、RM、TM

准备阶段、提交阶段

XA方案存在的问题？

1、需要本地数据库支持XA协议

2、资源锁需要等到两个阶段结束才释放，性能较差

3.2.2 Seata方案

优点：

1、性能较好，不长时间占用连接资源

2、对业务代码0侵入

3、支持AT模式(即2PC)及TCC模式的分布式事务解决方案

Seara设计思想：

把一个事务理解成一个包含若干分支事务的全局事务。。全局事务的职责是协调其下管辖的分支事务达成一致，要么一起成功提交，要么一起失败回滚。

image-20200616103151941

Seata如何在2PC基础上改进效率？

第一阶段就提交事务，释放资源，用全局事务XID来标记事务。

提交事务的流程是：

1、向事务协调器注册分支事务，TC返回branchid

2、写入业务数据、写入undo_log、提交分支事务

3、上报分支事务处理结果

第一阶段提交成功，携带事务ID进入第二个分支事务。执行上面的提交流程。

如果第一阶段失败，就不会进入第二步，第二步失败，通知事务协调器回滚分支事务

Seata三个组件解释一下？

事务管理器、事务协调器、资源管理器

image-20200616103133435

  • 事务协调器：独立部署，维护全局事务运行状态，接收TM指令，发起全局事务的提交或回滚，负责与RM通信协调各个事务分支的提交回滚
  • 事务管理器：内嵌应用程序中，负责开启全局事务，最终向TC发起全局事务提交或全局回滚
  • 资源管理器：控制分支事务，负责分支事务注册、状态汇报，并接收事务协调器指令，驱动分支事务的提交和回滚

image-20200616103118046

Seata的2PC和传统2PC的区别？

  • RM：jar包中间件层，部署在应用程序一侧

  • 锁释放的时机：第一阶段就将本地事务提交，释放资源

3.3 Seata实现2PC事务

3.3.1 业务说明

本示例通过Seata中间件实现分布式事务，模拟两个账户的转账交易过程。

两个账户在两个个不同的银行(张三在bank1、李四在bank2)，bank1和bank2是两个个微服务。交易过程是，张三 给李四转账指定金额。

上述交易步骤，要么一起成功，要么一起失败，必须是一个整体性的事务。

image-20200627234359827

3.3.2 程序组成部分

本示例程序组成部分如下：

数据库：MySQL-5.7.25

包括bank1和bank2两个数据库。

JDK：64位 jdk1.8.0_201

微服务框架：spring-boot-2.1.3、spring-cloud-Greenwich.RELEASE

seata客户端（RM、TM）：spring-cloud-alibaba-seata-2.1.0.RELEASE

seata服务端(TC)：seata-server-0.7.1

微服务及数据库的关系 ：

dtx/dtx-seata-demo/seata-demo-bank1 银行1，操作张三账户， 连接数据库bank1

dtx/dtx-seata-demo/seata-demo-bank2 银行2，操作李四账户，连接数据库bank2

服务注册中心：dtx/discover-server

本示例程序技术架构如下：

image-20200627234516366

3.3.3 创建数据库

导入数据库脚本

包括如下数据库：

bank1库，包含张三账户

CREATE DATABASE `bank1` CHARACTER SET 'utf8' COLLATE 'utf8_general_ci';

DROP TABLE IF EXISTS `account_info`; 
CREATE TABLE `account_info` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`account_name` varchar(100) CHARACTER SET utf8 COLLATE utf8_bin NULL DEFAULT NULL COMMENT '户 主姓名',
`account_no` varchar(100) CHARACTER SET utf8 COLLATE utf8_bin NULL DEFAULT NULL COMMENT '银行 卡号',
`account_password` varchar(100) CHARACTER SET utf8 COLLATE utf8_bin NULL DEFAULT NULL COMMENT '帐户密码',
`account_balance` double NULL DEFAULT NULL COMMENT '帐户余额',
PRIMARY KEY (`id`) USING BTREE 
) ENGINE = InnoDB AUTO_INCREMENT = 5 CHARACTER SET = utf8 COLLATE = utf8_bin ROW_FORMAT = Dynamic; 
INSERT INTO `account_info` VALUES (2, '张三的账户', '1', '', 10000);

bank2库，包含李四账户

CREATE DATABASE `bank2` CHARACTER SET 'utf8' COLLATE 'utf8_general_ci';

CREATE TABLE `account_info` ( 
  `id` bigint(20) NOT NULL AUTO_INCREMENT, 
  `account_name` varchar(100) CHARACTER SET utf8 COLLATE utf8_bin NULL DEFAULT NULL COMMENT '户 主姓名',
`account_no` varchar(100) CHARACTER SET utf8 COLLATE utf8_bin NULL DEFAULT NULL COMMENT '银行 卡号',
`account_password` varchar(100) CHARACTER SET utf8 COLLATE utf8_bin NULL DEFAULT NULL COMMENT '帐户密码',
`account_balance` double NULL DEFAULT NULL COMMENT '帐户余额',
PRIMARY KEY (`id`) USING BTREE 
) ENGINE = InnoDB AUTO_INCREMENT = 5 CHARACTER SET = utf8 COLLATE = utf8_bin ROW_FORMAT = Dynamic;
INSERT INTO `account_info` VALUES (3, '李四的账户', '2', NULL, 0);

分别在bank1、bank2库中创建undo_log表，此表为seata框架使用：

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;

3.3.4 启动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服务将采用文件的方式存储信息。

image-20200627234811793

如上图出现“Server started...”的字样则表示启动成功。

3.3.5 启动注册发现服务

discover-server是服务注册中心，测试工程将自己注册至discover-server。 导入：资料\基础代码\dtx 父工程，此工程自带了discover-server，discover-server基于Eureka实现。

3.3.6 导入案例工程dtx-seata-demo

dtx-seata-demo是seata的测试工程，根据业务需求需要创建两个dtx-seata-demo工程。

1、导入dtx-seata-demo工程

两个测试工程如下：

dtx/dtx-seata-demo/dtx-seata-demo-bank1 ，操作张三账户，连接数据库bank1

dtx/dtx-seata-demo/dtx-seata-demo-bank2 ，操作李四账户，连接数据库bank2

2、父工程Maven依赖说明

在dtx父工程中指定了SpringBoot和SpringCloud版本

<dependency> 
  <groupId>org.springframework.boot</groupId> 
  <artifactId>spring‐boot‐dependencies</artifactId> 				 <version>2.1.3.RELEASE</version> 
  <type>pom</type> 
  <scope>import</scope> 
</dependency>

<dependency> 
  <groupId>org.springframework.cloud</groupId> 
  <artifactId>spring‐cloud‐dependencies</artifactId> <version>Greenwich.RELEASE</version> 
  <type>pom</type> 
  <scope>import</scope> 
</dependency>

在dtx-seata-demo父工程中指定了spring-cloud-alibaba-dependencies的版本。

<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>

3、配置Seata

在src/main/resource中，新增registry.conf、file.conf文件，内容可拷贝seata-server-0.7.1中的配置文件。 在registry.conf中registry.type使用file：

image-20200627235039180

在file.conf中更改service.vgroup_mapping.[springcloud服务名]-fescar-service-group = "default"，并修改 service.default.grouplist =[seata服务端地址]

image-20200627235108437

关于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 中的配置保持 一致。

4、创建代理数据源（重要）

新增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; 
    }
}

3.3.7 Seata执行流程

1、正常提交流程

image-20200627235658971

2、回滚流程

回滚流程省略前的RM注册过程。

image-20200627235731200

要点说明：

1、每个RM使用DataSourceProxy连接数据库，其目的是使用ConnectionProxy，使用数据源和数据连接代理的目 的就是在第一阶段将undo_log和业务数据放在一个本地事务提交，这样就保存了只要有业务操作就一定有 undo_log。

2、在第一阶段undo_log中存放了数据修改前和修改后的值，为事务回滚作好准备，所以第一阶段完成就已经将分 支事务提交，也就释放了锁资源。

3、TM开启全局事务开始，将XID全局事务id放在事务上下文中，通过feign调用也将XID传入下游分支事务，每个 分支事务将自己的Branch ID分支事务ID与XID关联。

4、第二阶段全局事务提交，TC会通知各各分支参与者提交分支事务，在第一阶段就已经提交了分支事务，这里各 各参与者只需要删除undo_log即可，并且可以异步执行，第二阶段很快可以完成。

5、第二阶段全局事务回滚，TC会通知各各分支参与者回滚分支事务，通过 XID 和 Branch ID 找到相应的回滚日 志，通过回滚日志生成反向的 SQL 并执行，以完成分支事务回滚到之前的状态，如果回滚失败则会重试回滚操 作。

3.3.8 dtx-seata-demo-bank1

dtx-seata-demo-bank1实现如下功能：

1、张三账户减少金额，开启全局事务。

2、远程调用bank2向李四转账。

（1）DAO

@Mapper @Component public interface AccountInfoDao {

//更新账户金额 
  @Update("update account_info set account_balance = account_balance + #{amount} where account_no = #{accountNo}") 
  int updateAccountBalance(@Param("accountNo") String accountNo, @Param("amount") Double amount);

}

（2）FeignClient

远程调用bank2的客户端

@FeignClient(value = "seata‐demo‐bank2",fallback = Bank2ClientFallback.class) 
public interface Bank2Client {

@GetMapping("/bank2/transfer") 
  String transfer(@RequestParam("amount") Double amount);

}

@Component 
public class Bank2ClientFallback implements Bank2Client{
@Override
public String transfer(Double amount) {
return "fallback";
}
}

（3）Service

@Service 
public class AccountInfoServiceImpl implements AccountInfoService {

private Logger logger = LoggerFactory.getLogger(AccountInfoServiceImpl.class);

@Autowired 
  AccountInfoDao accountInfoDao;

@Autowired 
  Bank2Client bank2Client;

//张三转账 
  @Override 
  @GlobalTransactional 
  @Transactional 
  public void updateAccountBalance(String accountNo, Double amount) { logger.info("******** Bank1 Service Begin ... xid: {}" ,RootContext.getXID()); 
   //张三扣减金额
accountInfoDao.updateAccountBalance(accountNo,amount*‐1);
//向李四转账 
String remoteRst = bank2Client.transfer(amount); 
//远程调用失败
if(remoteRst.equals("fallback")){
	throw new RuntimeException("bank1 下游服务异常");} 
//人为制造错误 
	if(amount==3){ 
		throw new RuntimeException("bank1 make exception 3");
	}
	}
}

将@GlobalTransactional注解标注在全局事务发起的Service实现方法上，开启全局事务： GlobalTransactionalInterceptor会拦截@GlobalTransactional注解的方法，生成全局事务ID(XID)，XID会在整个 分布式事务中传递。

在远程调用时，spring-cloud-alibaba-seata会拦截Feign调用将XID传递到下游服务。

（6）Controller

@RestController 
public class Bank1Controller {

@Autowired 
  AccountInfoService accountInfoService;

//转账 
  @GetMapping("/transfer") public String transfer(Double amount){

accountInfoService.updateAccountBalance("1",amount);

return "bank1"+amount; }

}

3.3.9 dtx-seata-demo-bank2

dtx-seata-demo-bank2实现如下功能：

1、李四账户增加金额。 dtx-seata-demo-bank2在本账号事务中作为分支事务不使用@GlobalTransactional。

（1）DAO

@Mapper 
@Component 
public interface AccountInfoDao {

//向李四转账

@Update("UPDATE account_info SET account_balance = account_balance + #{amount} WHERE account_no = #{accountNo}")

int updateAccountBalance(@Param("accountNo") String accountNo, @Param("amount") Double amount);

}

（2）Service

@Service public class AccountInfoServiceImpl implements AccountInfoService {

private Logger logger = LoggerFactory.getLogger(AccountInfoServiceImpl.class);

@Autowired AccountInfoDao accountInfoDao;

@Override
@Transactional
  public void updateAccountBalance(String accountNo, Double amount) {

logger.info("******** Bank2 Service Begin ... xid: {}" , RootContext.getXID()); 
    //李四增加金额 
    accountInfoDao.updateAccountBalance(accountNo,amount); 
    //制造异常 
    if(amount==2){ throw new RuntimeException("bank1 make exception 2"); }

}

}

（3）Controller

@RestController 
public class Bank2Controller {

@Autowired AccountInfoService accountInfoService;

@GetMapping("/transfer") 
  public String transfer(Double amount){
accountInfoService.updateAccountBalance("2",amount);
return "bank2"+amount; }
}

3.3.10 测试场景

张三向李四转账成功。

李四事务失败，张三事务回滚成功。

张三事务失败，李四事务回滚成功。

分支事务超时测试。

3.4.小结

本节讲解了传统2PC（基于数据库XA协议）和Seata实现2PC的两种2PC方案，由于Seata的0侵入性并且解决了传 统2PC长期锁资源的问题，所以推荐采用Seata实现2PC。

Seata实现2PC要点：

1、全局事务开始使用 @GlobalTransactional标识 。

2、每个本地事务方案仍然使用@Transactional标识。

3、每个数据都需要创建undo_log表，此表是seata保证本地事务一致性的关键。

4、分布式事务解决方案之TCC

4.1 什么是TCC事务

TCC是Try、Confirm、Cancel三个词语的缩写，TCC要求每个分支事务实现三个操作：预处理Try、确认Confirm、撤销Cancel。

Try操作做业务检查和资源预留

Confirm做业务确认操作

Cancel实现一个与Try相反的操作即回滚操作

TM首先发起所有的分支事务的try操作，任何一个分支事务的try操作执行失败，TM将会发起所有分支事务的Cancel操作，若Try操作全部成功，TM将会发起所有分支事务的Confirm操作，其中Confirm/Cancel操作若执行失败，TM会进行重试。

image-20200616103759720

TCC分为三个阶段：

  1. Try 阶段是做业务检查(一致性)及资源预留(隔离)，此阶段仅是一个初步操作，它和后续的Confirm 一起才能 真正构成一个完整的业务逻辑。

  2. Confirm 阶段是做确认提交，Try阶段所有分支事务执行成功后开始执行 Confirm。通常情况下，采用TCC则 认为 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。若Confirm阶段真的出错了，需引 入重试机制或人工处理。

  3. Cancel 阶段是在业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放。通常情况下，采 用TCC则认为Cancel阶段也是一定成功的。若Cancel阶段真的出错了，需引入重试机制或人工处理。

  4. TM事务管理器 TM事务管理器可以实现为独立的服务，也可以让全局事务发起方充当TM的角色，TM独立出来是为了成为公 用组件，是为了考虑系统结构和软件复用。

TM在发起全局事务时生成全局事务记录，全局事务ID贯穿整个分布式事务调用链条，用来记录事务上下文， 追踪和记录状态，由于Confirm 和cancel失败需进行重试，因此需要实现为幂等，幂等性是指同一个操作无论请求 多少次，其结果都相同。

4.2.TCC 解决方案

目前市面上的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并没有提供支持。

我们的目标是理解TCC的原 理以及事务协调运作的过程，因此更请倾向于轻量级易于理解的框架，因此最终确定了Hmily。

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。

举例，场景为 A 转账 30 元给 B，A和B账户在不同的服务。

方案1：

账户A

try:	
	检查余额是否够30元 
  扣减30元
confirm：
	空
cancel：
	增加30元

账户B

try：
	增加30元
confirm：
	空
cancel：
	减少30元

方案1说明：

1）账户A，这里的余额就是所谓的业务资源，按照前面提到的原则，在第一阶段需要检查并预留业务资源，因此， 我们在扣钱 TCC 资源的 Try 接口里先检查 A 账户余额是否足够，如果足够则扣除 30 元。 Confirm 接口表示正式 提交，由于业务资源已经在 Try 接口里扣除掉了，那么在第二阶段的 Confirm 接口里可以什么都不用做。Cancel 接口的执行表示整个事务回滚，账户A回滚则需要把 Try 接口里扣除掉的 30 元还给账户。

2）账号B，在第一阶段 Try 接口里实现给账户B加钱，Cancel 接口的执行表示整个事务回滚，账户B回滚则需要把 Try 接口里加的 30 元再减去。

方案1的问题分析：

1）如果账户A的try没有执行在cancel则就多加了30元。

2）由于try，cancel、confirm都是由单独的线程去调用，且会出现重复调用，所以都需要实现幂等。

3）账号B在try中增加30元，当try执行完成后可能会其它线程给消费了。

4）如果账户B的try没有执行在cancel则就多减了30元。

问题解决：

1）账户A的cancel方法需要判断try方法是否执行，正常执行try后方可执行cancel。

2）try，cancel、confirm方法实现幂等。

3）账号B在try方法中不允许更新账户金额，在confirm中更新账户金额。

4）账户B的cancel方法需要判断try方法是否执行，正常执行try后方可执行cancel。

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

5.1 什么是可靠消息最终一致性事务

5.2 解决方案

5.2.1 本地消息表方案

我实现的最初的待办消息发送方案，原来就是这个方案啊

5.2.2 RocketMQ事务消息方案

6、分布式事务解决方案之最大努力通知

视频地址

文件：百度云根目录

posted @ 2020-06-16 00:33  元宝爸爸  阅读(464)  评论(0)  编辑  收藏  举报