zoukankan html css js c++ java

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

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

商品信息

CAP各是什么？有什么结论

只能在AP和CP选。

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

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

2.2 BASE理论

BASE理论指的是？

基本可用：核心功能可用

软状态：中间状态

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

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

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

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

3.1 什么是2PC

准备阶段和提交阶段

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

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

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

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设计思想：

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

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

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

提交事务的流程是：

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

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

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

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

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

Seata三个组件解释一下？

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

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

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

RM：jar包中间件层，部署在应用程序一侧
锁释放的时机：第一阶段就将本地事务提交，释放资源

3.3 Seata实现2PC事务

3.3.1 业务说明

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

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

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

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

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

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

注：其中8888为服务端口号；ﬁle为启动模式，这里指seata服务将采用文件的方式存储信息。

如上图出现“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、ﬁle.conf文件，内容可拷贝seata-server-0.7.1中的配置文件。在registry.conf中registry.type使用ﬁle：

在ﬁle.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 中的配置保持一致。

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

新增DatabaseConﬁguration.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、正常提交流程

2、回滚流程

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

要点说明：

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会进行重试。

TCC分为三个阶段：

Try 阶段是做业务检查(一致性)及资源预留(隔离)，此阶段仅是一个初步操作，它和后续的Conﬁrm 一起才能真正构成一个完整的业务逻辑。
Conﬁrm 阶段是做确认提交，Try阶段所有分支事务执行成功后开始执行 Conﬁrm。通常情况下，采用TCC则认为 Conﬁrm阶段是不会出错的。即：只要Try成功，Conﬁrm一定成功。若Conﬁrm阶段真的出错了，需引入重试机制或人工处理。
Cancel 阶段是在业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放。通常情况下，采用TCC则认为Cancel阶段也是一定成功的。若Cancel阶段真的出错了，需引入重试机制或人工处理。
TM事务管理器 TM事务管理器可以实现为独立的服务，也可以让全局事务发起方充当TM的角色，TM独立出来是为了成为公用组件，是为了考虑系统结构和软件复用。

TM在发起全局事务时生成全局事务记录，全局事务ID贯穿整个分布式事务调用链条，用来记录事务上下文，追踪和记录状态，由于Conﬁrm 和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,ﬁle,mysql。
事务日志序列化支持：java，hessian，kryo，protostuﬀ。
采用Aspect AOP 切面思想与Spring无缝集成，天然支持集群。
RPC事务恢复，超时异常恢复等。

Hmily利用AOP对参与分布式事务的本地方法与远程方法进行拦截处理，

通过多方拦截，事务参与者能透明的调用到另一方的Try、Conﬁrm、Cancel方法；

传递事务上下文；

并记录事务日志，酌情进行补偿，重试等。

Hmily不需要事务协调服务，但需要提供一个数据库(mysql/mongodb/zookeeper/redis/ﬁle)来进行日志存储。

Hmily实现的TCC服务与普通的服务一样，只需要暴露一个接口，也就是它的Try业务。

Conﬁrm/Cancel业务逻辑，只是因为全局事务提交/回滚的需要才提供的，因此Conﬁrm/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、 Conﬁrm 和 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 元。 Conﬁrm 接口表示正式提交，由于业务资源已经在 Try 接口里扣除掉了，那么在第二阶段的 Conﬁrm 接口里可以什么都不用做。Cancel 接口的执行表示整个事务回滚，账户A回滚则需要把 Try 接口里扣除掉的 30 元还给账户。

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

方案1的问题分析：

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

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

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

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

问题解决：

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

2）try，cancel、conﬁrm方法实现幂等。

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

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

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

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

5.2 解决方案

5.2.1 本地消息表方案

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

5.2.2 RocketMQ事务消息方案

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

视频地址

文件：百度云根目录

查看全文

相关阅读:
WEBAPP开发技巧
 手机中的javascript事件
 I6下实现FIXED
vim 使用帮助
 javascript小技巧
 webkitbox & translate CSS3动画详解
 backbone中的实例中文注释
 getClientRect和getBoundingClientRect获取节点的屏幕距离
 javascript判定不同浏览器
 jQuery中的trigger(type, [data]) 原生实现方法

原文地址：https://www.cnblogs.com/xinrong2019/p/13138754.html