详细说分布式事务

 

一、分布式事务的概念

1，什么是事务

　　事务可以看做是一次大的活动，它由不同的小活动组成，这些活动要么全部成功，要么全部失败。

2，本地事务

　　数据库事务的四大特性 ACID：
  • A（Atomic）：原子性，构成事务的所有操作，要么都执行完成，要么全部不执行，不可能出现部分成功部分失败的情况。
  • C（Consistency）：一致性，在事务执行前后，数据库的一致性约束没有被破坏。比如：张三向李四转100元，转账前和转账后的数据是正确状态这叫一致性，如果出现张三转出100元，李四账户没有增加100元这就出现了数据错误，就没有达到一致性。
  • I（Isolation）：隔离性，数据库中的事务一般都是并发的，隔离性是指并发的两个事务的执行互不干扰，一个事务不能看到其他事务运行过程的中间状态。通过配置事务隔离级别可以避脏读、重复读等问题。
  • D（Durability）：持久性，事务完成之后，该事务对数据的更改会被持久化到数据库，且不会被回滚。

　　数据库事务在实现时会将一次事务涉及的所有操作全部纳入到一个不可分割的执行单元，该执行单元中的所有操作要么都成功，要么都失败，只要其中任一操作执行失败，都将导致整个事务的回滚。

3，分布式事务

　　分布式系统会把一个应用系统拆分为可独立部署的多个服务，因此需要服务与服务之间远程协作才能完成事务操作，这种分布式系统环境下由不同的服务之间通过网络远程协作完成事务称之为分布式事务，例如用户注册送积分事务、创建订单减库存事务，银行转账事务等都是分布式事务。

4，分布式事务产生的场景

  • 典型的场景就是微服务架构，微服务之间通过远程调用完成事务操作。比如：订单微服务和库存微服务，下单的同时订单微服务请求库存微服务减库存。 简言之：跨JVM进程产生分布式事务。
  • 单体系统访问多个数据库实例，跨数据库实例产生分布式事务。
  • 多服务访问同一个数据库实例，比如：订单微服务和库存微服务即使访问同一个数据库也会产生分布式事务，原因就是跨JVM进程，两个微服务持有了不同的数据库链接进行数据库操作，此时产生分布式事务。

二、分布式事务基础理论

1，CAP理论

a）概念

　　CAP是 Consistency、Availability、Partition tolerance三个词语的缩写，分别表示一致性、可用性、分区容忍性。

b）组合方式

　　在所有分布式事务场景中不会同时具备CAP三个特性，因为在具备了P的前提下C和A是不能共存的。

  • AP：放弃一致性，追求分区容忍性和可用性。这是很多分布式系统设计时的选择。Eureka集群就是采用的AP设计思想。
  • CP：放弃可用性，追求一致性和分区容错性。zookeeper集群。
  • CA：放弃分区容忍性，即不进行分区，不考虑由于网络不通或结点挂掉的问题，则可以实现一致性和可用性。那么系统将不是一个标准的分布式系统，我们最常用的关系型数据就满足了CA。

c）总结

　　CAP是一个已经被证实的理论：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三项中的两项。它可以作为我们进行架构设计、技术选型的考量标准。对于多数大型互联网应用的场景，结点众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到N个9（99.99..%），并要达到良好的响应性能来提高用户体验，因此一般都会做出如下选择：保证P和A，舍弃C强一致，保证最终一致性。

2，BASE理论

a）强一致性与最终一致性

  • 强一致性：CAP中的一致性要求在任何时间查询每个结点数据都必须一致，它强调的是强一致性。
  • 最终一致性：允许可以在一段时间内每个结点的数据不一致，但是经过一段时间每个结点的数据必须一致，它强调的是最终数据的一致性。

b）概念

　　BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。BASE理论是对CAP中AP的一个扩展，通过牺牲强一致性来获得可用性，当出现故障允许部分不可用但要保证核心功能可用，允许数据在一段时间内是不一致的，但最终达到一致状态。满足BASE理论的事务，我们称之为“柔性事务”。

  • 基本可用：分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。如，电商网站交易付款出现问题了，商品依然可以正常浏览。
  • 软状态：由于不要求强一致性，所以BASE允许系统中存在中间状态（也叫软状态），这个状态不影响系统可用性，如订单的“支付中”、“数据同步中”等状态，待数据最终一致后状态改为“成功”状态。
  • 最终一致性：最终一致是指经过一段时间后，所有节点数据都将会达到一致。如订单的"支付中"状态，最终会变为“支付成功”或者"支付失败"，使订单状态与实际交易结果达成一致，但需要一定时间的延迟、等待。

三、解决方案之2PC

1，什么是2PC

　　2PC即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（commit phase），2是指两个阶段，P是指准备阶段，C是指提交阶段。

  • 准备阶段（Prepare phase）：事务管理器给每个参与者发送Prepare消息，每个数据库参与者在本地执行事务，并写本地的Undo/Redo日志，此时事务没有提交。（Undo日志是记录修改前的数据，用于数据库回滚，Redo日志是记录修改后的数据，用于提交事务后写入数据文件）
  • 提交阶段（commit phase）：如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据事务管理器的指令执行提交或者回滚操作，并释放事务处理过程中使用的锁资源。注意:必须在最后阶段释放锁资源。

　　成功情况：

　　失败情况：

　

2，解决方案之XA

　　2PC的传统方案是在数据库层面实现的，如Oracle、MySQL都支持2PC协议，为了统一标准减少行业内不必要的对接成本，需要制定标准化的处理模型及接口标准，国际开放标准组织Open Group定义了分布式事务处理模型DTP（Distributed Transaction Processing Reference Model）。 

　　

 　　整个2PC的事务流程涉及到三个角色AP、RM、TM。AP指的是使用2PC分布式事务的应用程序；RM指的是资源管理器，它控制着分支事务；TM指的是事务管理器，它控制着整个全局事务。

　　1）在准备阶段RM执行实际的业务操作，但不提交事务，资源锁定；
　　2）在提交阶段TM会接受RM在准备阶段的执行回复，只要有任一个RM执行失败，TM会通知所有RM执行回滚操作，否则，TM将会通知所有RM提交该事务。提交阶段结束资源锁释放。
　　XA方案的问题：1、需要本地数据库支持XA协议。2、资源锁需要等到两个阶段结束才释放，性能较差。 

3，解决方案之Seata

a）seata的设计思想

　　Seata的设计目标其一是对业务无侵入，因此从业务无侵入的2PC方案着手，在传统2PC的基础上演进，并解决2PC方案面临的问题。

　　Seata把一个分布式事务理解成一个包含了若干分支事务的全局事务。全局事务的职责是协调其下管辖的分支事务达成一致，要么一起成功提交，要么一起失败回滚。此外，通常分支事务本身就是一个关系数据库的本地事务，下图是全局事务与分支事务的关系图：

　　

　　与 传统2PC 的模型类似，Seata定义了3个组件来协议分布式事务的处理过程： 

　　

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

b）Seata的执行流程

　　

  1. 用户服务的 TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的XID。
  2. 用户服务的 RM 向 TC 注册 分支事务，该分支事务在用户服务执行新增用户逻辑，并将其纳入 XID 对应全局事务的管辖。
  3. 用户服务执行分支事务，向用户表插入一条记录。
  4. 逻辑执行到远程调用积分服务时(XID 在微服务调用链路的上下文中传播)。积分服务的RM 向 TC 注册分支事务，该分支事务执行增加积分的逻辑，并将其纳入 XID 对应全局事务的管辖。
  5. 积分服务执行分支事务，向积分记录表插入一条记录，执行完毕后，返回用户服务。
  6. 用户服务分支事务执行完毕。
  7. TM 向 TC 发起针对 XID 的全局提交或回滚决议。
  8. TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。 

c）Seata的具体实现

　　详情见：Spring Cloud Alibaba Seata

4，Seata与传统2PC

  • 架构层次方面，传统2PC方案的 RM 实际上是在数据库层，RM 本质上就是数据库自身，通过 XA 协议实现，而Seata的 RM 是以jar包的形式作为中间件层部署在应用程序这一侧的。
  • 两阶段提交方面，传统2PC无论第二阶段的决议是commit还是rollback，事务性资源的锁都要保持到Phase2完成才释放。而Seata的做法是在Phase1 就将本地事务提交，这样就可以省去Phase2持锁的时间，整体提高效率。 

四、解决方案之TCC

1，什么是TCC

　　TCC是Try、Confirm、Cancel三个词语的缩写，TCC要求每个分支事务实现三个操作：预处理Try、确认Confirm、撤销Cancel。Try操作做业务检查及资源预留，Confirm做业务确认操作，Cancel实现一个与Try相反的操作即回滚操作。TM首先发起所有的分支事务的try操作，任何一个分支事务的try操作执行失败，TM将会发起所有分支事务的Cancel操作，若try操作全部成功，TM将会发起所有分支事务的Confifirm操作，其中Confirm/Cancel操作若执行失败，TM会进行重试。 

　　成功情况：

　　

　　失败情况：

　　

 　　TCC分为三个阶段：

  • Try 阶段是做业务检查(一致性)及资源预留(隔离)，此阶段仅是一个初步操作，它和后续的Confirm 一起才能真正构成一个完整的业务逻辑。
  • Confirm 阶段是做确认提交，Try阶段所有分支事务执行成功后开始执行 Confirm。通常情况下，采用TCC则认为 Confifirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。若Confirm阶段真的出错了，需引入重试机制或人工处理。 
  • Cancel 阶段是在业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放。通常情况下，采用TCC则认为Cancel阶段也是一定成功的。若Cancel阶段真的出错了，需引入重试机制或人工处理。

2，TCC解决方案

框架名称 Github地址
tcc-transaction
Hmily
ByteTCC 
EasyTransaction 

3，TCC需要注意的问题

a）空回滚

　　在没有调用 TCC 资源 Try 方法的情况下，调用了二阶段的 Cancel 方法，Cancel 方法需要识别出这是一个空回滚，然后直接返回成功。 

　　出现原因：是当一个分支事务所在服务宕机或网络异常，分支事务调用记录为失败，这个时候其实是没有执行Try阶段，当故障恢复后，分布式事务进行回滚则会调用二阶段的Cancel方法，从而形成空回滚。 

　　解决方法：识别出这个空回滚。需要知道一阶段是否执行，如果执行了，那就是正常回滚；如果没执行，那就是空回滚。前面已经说过TM在发起全局事务时生成全局事务记录，全局事务ID贯穿整个分布式事务调用链条。再额外增加一张分支事务记录表，其中有全局事务 ID 和分支事务 ID，第一阶段 Try 方法里会插入一条记录，表示一阶段执行了。

//在cancel中cancel空回滚处理，如果try没有执行，cancel不允许执行
if(accountInfoDao.isExistTry(transId)<=0){
    log.info("bank1 空回滚处理，try没有执行，不允许cancel执行,xid:{}",transId);
    return ;
}

b）幂等

　　为了保证TCC二阶段提交重试机制不会引发数据不一致，要求 TCC 的二阶段 Try、Confirm 和 Cancel 接口保证幂等，这样不会重复使用或者释放资源。如果幂等控制没有做好，很有可能导致数据不一致等严重问题。

//当前是在try中进行幂等判断 判断local_try_log表中是否有try日志记录，如果有则不再执行
if(accountInfoDao.isExistTry(transId)>0){
    log.info("bank1 try 已经执行，无需重复执行,xid:{}",transId);
    return ;
}

c）悬挂

　　悬挂就是对于一个分布式事务，其二阶段 Cancel 接口比 Try 接口先执行。 

　　出现原因：RPC 调用分支事务try时，先注册分支事务，再执行RPC调用，如果此时 RPC 调用的网络发生拥堵，通常 RPC 调用是有超时时间的，RPC 超时以后，TM就会通知RM回滚该分布式事务，可能回滚完，RPC 请求才到达参与者真正执行，而一个 Try 方法预留的业务资源。

　　解决思路：如果二阶段执行完成，那一阶段就不能再继续执行。在执行一阶段事务时判断在该全局事务下，“分支事务记录”表中是否已经有二阶段事务记录，如果有则不执行Try。 

//try悬挂处理，如果cancel、confirm有一个已经执行了，try不再执行
if(accountInfoDao.isExistConfirm(transId)>0 || accountInfoDao.isExistCancel(transId)>0){
    log.info("bank1 try悬挂处理  cancel或confirm已经执行，不允许执行try,xid:{}",transId);
    return ;
}

4，Hmily

　　项目源码：cloud-dtx-tcc

a）导入数据库

　　sql文件下载地址为：dtx-tcc-sql

b）工程配置

　　涉及到分布式事务的工程均需要的配置

maven配置

复制代码
<!-- hmily依赖 -->
<dependency> 
    <groupId>org.dromara</groupId>
    <artifactId>hmily‐springcloud</artifactId>
    <version>2.0.4‐RELEASE</version>
</dependency>
复制代码

application.yaml中添加hmily

复制代码
org:
  dromara:
    hmily:
      serializer: kryo
      recoverDelayTime: 30
      retryMax: 30
      scheduledDelay: 30
      scheduledThreadMax: 10
      repositorySupport: db
      #对于发起方的时候，把此属性设置为true。参与方为false。
      started: true
      hmilyDbConfig:
        driverClassName: com.mysql.jdbc.Driver
        url: jdbc:mysql://localhost:3306/hmily?useUnicode=true
        username: root
        password: 123456
复制代码

注入hmily的配置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;
}
复制代码

启动类上添加注解

@ComponentScan({"org.dromara.hmily"})

c）调用方（bank1）实现

　　代码实现：AccountInfoServiceImpl

复制代码
try： 
    try幂等校验
    try悬挂处理
    检查余额是够扣减金额
    扣减金额
confirm：
    空
cancel
    cancel幂等校验
    cancel空回滚处理
    增加可用余额
复制代码

　　注意：远程调用bank2时，在feign调用的接口上加注解@Hmily

d）参与方（bank2）实现

　　代码实现：AccountInfoServiceImpl

复制代码
try：
    空
confirm：
    confirm幂等校验
    正式增加金额
cancel：
    空
复制代码

e）小结

　　如果拿TCC事务的处理流程与2PC两阶段提交做比较，2PC通常都是在跨库的DB层面，而TCC则在应用层面的处理，需要通过业务逻辑来实现。这种分布式事务的实现方式的优势在于，可以让应用自己定义数据操作的粒度，使得降低锁冲突、提高吞吐量成为可能。
　　而不足之处则在于对应用的侵入性非常强，业务逻辑的每个分支都需要实现try、confirm、cancel三个操作。此外，其实现难度也比较大，需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。

五、解决方案之可靠消息最终一致性

　　项目源码：cloud-dtx-txmsg

1，什么是可靠消息最终一致性

　　可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息，事务参与方(消息消费者)一定能够接收消息并处理事务成功，此方案强调的是只要消息发给事务参与方最终事务要达到一致。

　　

可靠消息需要解决的问题：

  • 本地事务与消息发送的原子性问题
  • 复制代码
    //先发消息如果数据库操作错误,消息已经发送
begin transaction；
    //1.发送MQ 
    //2.数据库操作
commit transation;
//如果数据库超时，此时数据库回滚，但是消息可能也已经发送
begin transaction；
    //1.数据库操作
    //2.发送MQ 
commit transation;
    复制代码
  • 事务参与方接受消息的可靠性
  • 事务参与方必须能够从消息队列接收到消息，如果接收消息失败可以重复接收消息。
  • 消息重复消费的问题
  • 由于网络2的存在，若某一个消费节点超时但是消费成功，此时消息中间件会重复投递此消息,就导致了消息的重 复消费。
要解决消息重复消费的问题就要实现事务参与方的方法幂等性。

2，RocketMQ事务消息方案

　　

  • Producer 发送事务消息 ：Producer （MQ发送方）发送事务消息至MQ Server，MQ Server将消息状态标记为Prepared（预备状态），注意此时这条消息消费者（MQ订阅方）是无法消费到的。 
  • MQ Server回应消息发送成功 ：MQ Server接收到Producer 发送给的消息则回应发送成功表示MQ已接收到消息。 
  • Producer 执行本地事务：Producer 端执行业务代码逻辑，通过本地数据库事务控制。 
  • 消息投递：若Producer 本地事务执行成功则自动向MQServer发送commit消息，此时MQ订阅方（积分服务）即正常消费消息；若Producer 本地事务执行失败则自动向MQServer发送rollback消息，MQ Server接收到rollback消息后 将删除”增加积分消息“ 。 MQ订阅方（积分服务）消费消息，消费成功则向MQ回应ack，否则将重复接收消息。这里ack默认自动回应，即程序执行正常则自动回应ack。 
  • 事务回查：如果执行Producer端本地事务过程中，执行端挂掉，或者超时，MQ Server将会不停的询问同组的其他 Producer来获取事务执行状态，这个过程叫事务回查。MQ Server会根据事务回查结果来决定是否投递消息。 

3，RocketMQ实现可靠消息最终一致性事务

a）SQL

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

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;

View Code

bank2

CREATE DATABASE `bank2` 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
    (
        3,
        '李四的账户',
        '2',
        NULL,
        0
    );

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;

b）安装RocketMQ

c）工程配置

　　maven

<dependency>
    <groupId>org.apache.rocketmq</groupId>
    <artifactId>rocketmq-spring-boot-starter</artifactId>
    <version>2.0.2</version>
</dependency>

　　properties配置

rocketmq.producer.group = producer_bank2
rocketmq.name‐server = 127.0.0.1:9876

d）bank1

　　Service：AccountInfoServiceImpl

//两个方法
//1，向mq发送转账消息
//2，更新账户，扣减金额 （通过事务id保证幂等性）

　　Controller：AccountInfoController

//生成事务id，调用service的发消息接口

　　message：ProducerTxmsgListener

//两个方法executeLocalTransaction和checkLocalTransaction
//事务消息发送后的回调方法。此时保证本地事务，调用Service扣减金额同时将消息改为COMMIT（可消费状态），如果捕获异常，将消息改为ROLLBACK回滚
//事务回查。查询是否在调用方已经处理，如果已经处理需修改消息为COMMIT可消费,否则就是UNKOWN状态。

e）bank2

　　Service：AccountInfoServiceImpl

//更新账户bank2，增加金额。(通过事务id保证幂等性)

　　message：TxmsgConsumer

//监听bank1发送的消息topic，调用Service增加金额

4，总结

　　可靠消息最终一致性就是保证消息从生产方经过消息中间件传递到消费方的一致性，本案例使用了RocketMQ作为消息中间件，RocketMQ主要解决了两个功能：

  • 本地事务与消息发送的原子性问题。
  • 事务参与方接收消息的可靠性。
　　可靠消息最终一致性事务适合执行周期长且实时性要求不高的场景。引入消息机制后，同步的事务操作变为基于消息执行的异步操作, 避免了分布式事务中的同步阻塞操作的影响，并实现了两个服务的解耦。

六、解决方案之最大努力通知

　　源码：cloud-dtx-notify

1，什么是最大努力通知

　　发起通知方通过一定的机制最大努力将业务处理结果通知到接收方。
  • 有一定的消息重复通知机制。因为接收通知方可能没有接收到通知，此时要有一定的机制对消息重复通知。
  • 消息校对机制。如果尽最大努力也没有通知到接收方，或者接收方消费消息后要再次消费，此时可由接收方主动向通知方查询消息信息来满足需求。

2，最大努力通知与可靠消息一致性的异同

  • 思想不同：可靠消息一致性，发起通知方需要保证将消息发出去，并且将消息发到接收通知方，消息的可靠性关键由发起通知方来保证。最大努力通知，发起通知方尽最大的努力将业务处理结果通知为接收通知方，但是可能消息接收不到，此时需要接收通知方主动调用发起通知方的接口查询业务处理结果，通知的可靠性关键在接收通知方。
  • 业务场景不同：可靠消息一致性关注的是交易过程的事务一致，以异步的方式完成交易。最大努力通知关注的是交易后的通知事务，即将交易结果可靠的通知出去。
  • 技术解决方向不同：可靠消息一致性要解决消息从发出到接收的一致性，即消息发出并且被接收到；最大努力通知无法保证消息从发出到接收的一致性，只提供消息接收的可靠性机制。可靠机制是，最大努力的将消息通知给接收方，当消息无法被接收方接收时，由接收方主动查询消息（业务处理结果）。

3，解决方案

a）解决方案一：

　　

 　　具体流程：

  • 发起通知方将通知发给MQ。使用普通消息机制将通知发给MQ。
  • 接收通知方监听 MQ。
  • 接收通知方接收消息，业务处理完成回应ack。 
  • 接收通知方若没有回应ack则MQ会重复通知。 MQ会按照间隔1min、5min、10min、30min、1h、2h、5h、10h的方式，逐步拉大通知间隔 （如果MQ采用rocketMq，在broker中可进行配置），直到达到通知要求的时间窗口上限。 
  • 接收通知方可通过消息校对接口来校对消息的一致性。

b）解决方案二：

　　与方案1不同的是应用程序向接收通知方发送通知，如下图：

　　

 　　具体流程：

  • 发起通知方将通知发给MQ：使用可靠消息一致方案中的事务消息保证本地事务与消息的原子性，最终将通知先发给MQ。 
  • 通知程序监听 MQ，接收MQ的消息。 通知程序若没有回应ack则MQ会重复通知。 
  • 通知程序通过互联网接口协议（如http、webservice）调用接收通知方案接口，完成通知。 通知程序调用接收通知方案接口成功就表示通知成功，即消费MQ消息成功，MQ将不再向通知程序投递通知消息。
  • 接收通知方可通过消息校对接口来校对消息的一致性。 

c）两种方案比较

  • 方案1中接收通知方与MQ接口，即接收通知方案监听 MQ，此方案主要应用与内部应用之间的通知。
  • 方案2中由通知程序与MQ接口，通知程序监听MQ，收到MQ的消息后由通知程序通过互联网接口协议调用接收通知方。此方案主要应用于外部应用之间的通知，例如支付宝、微信的支付结果通知。 

4，最大努力通知实现

a）sql

　　bank1_pay.sql
 View Code

　　bank1.sql

 View Code

b）工程配置

　　基本配置同可靠消息一致性

c）pay支付方

　　Service：AccountPayServiceImpl

//两个方法
//1，插入充值记录。生成事务id，将事务id和充值信息发送给MQ队列
//2，查询充值记录。提供给调用方查询。

　　Controller：AccountPayController

//直接调用Service中的方法插入充值记录

d）bank1

　　Service：AccountInfoServiceImpl

//两个方法
//1，更新账户金额。根据事务id保证更新的幂等性。
//2，远程调用pay的查询充值结果。如果发现状态改变同时更新当前账号情况。

　　message：NotifyMsgListener

//监听消息。调用Service的更新账户金额，幂等更新。

　　Controller：AccountInfoController

//调用Service的查询充值结果

5，总结

　　最大努力通知方案是分布式事务中对一致性要求最低的一种,适用于一些最终一致性时间敏感度低的业务；最大努力通知方案需要实现如下功能：

  • 消息重复通知机制。
  • 消息校对机制。 主动调用接口查询并修改。

七、四种分布式事务对比

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