架构设计方法（三）分布式事务

lljjmm
257 阅读12分钟

以下内容是在学习过程中的一些笔记，难免会有错误和纰漏的地方。如果造成任何困扰，很抱歉。

前言

什么是事务（Transaction）？一般是指要做的或所做的事情，包含开始和结束，并且在计算机中含有“回滚”的概念：当一组事务的执行中发生无法预估的错误，将会把之前执行完成的动作进行恢复。事务中包含四种属性（ACID）：

  • 原子性

    一个事务是一个不可分割的工作单位，事务中包括的操作要么都做，要么都不做。

  • 一致性

    也叫原子性，事务必须是使数据库从一个一致性状态变到另一个一致性状态。

  • 隔离性

    并发执行的各个事务之间不能互相干扰。

  • 持久性

    一个事务一旦提交，它对数据库中数据的改变就应该是永久性的

一、CAP定理与一致性问题

CAP 定理，又被叫作布鲁尔定理

  • C (一致性)

    数据在多个副本之间能够保持一致的特性。

    • 强一致性

      对于关系型数据库，要求更新过的数据能被后续的访问都能看到。

    • 弱一致性

      数据更新后，能容忍后续的访问只能访问到部分或者全部访问不到。

  • A (可用性)

    指系统提供的服务必须一直处于可用的状态，每次只要收到用户的请求，服务器就必须给出回应（不是错误和超时的响应）。

  • P (网络分区容错性)

    网络节点之间无法通信的情况下，节点被隔离，产生了网络分区， 整个系统仍然是可以工作的。

CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP

简单将一致性问题分为两大类：

  • 分布式事务一致性
  • 高可用副本一致性

分布式问题也是随处可见：

  1. 缓存和数据库的一致性问题；
  2. 消息中间件和数据库的一致性问题；
  3. 两个数据库的一致性问题；
  4. 微服务和数据库的一致性问题；
  5. 微服务之间的一致性问题；
  6. 两个文件的一致性问题；

下面对这些一致性问题思考一下解决方案。

二、2PC

2PC主要应用在两个数据库之间，里面包含两种角色：协调者和参与者。

其中包含了两种阶段：

  1. 第一阶段，事务询问
  2. 第二阶段：提交or回滚

Open Group组织在文字中定义了2PC XA规范，主流的数据库都实现了XA协议

        try {
            // 业务操作A
            // ...

            // 业务操作B
            // ...

            // 2PC阶段一：准备阶段
            // ...

            // 2PC阶段二：提交阶段
            // ...

        } catch (Exception e) {
            // 异常回滚
        }

但是这种方式存在弊端，如：

  1. 性能问题，要等待所有资源提交才能进入下一个阶段；
  2. 协调者宕机情况，无人决策；
  3. 超时情况，等待参与者时间过长；
  4. 使用限制，只能应用与数据库与数据库；

为了解决系统中的分布式问题，下面来看看支付宝提出的TCC方案。

三、TCC

TCC是“Try”，“Confirm”，“Cancel”三个单词的缩写，实际上思路也是跟2PC差不多

分为了两个阶段

  1. 准备阶段：资源检查和资源锁定。
  2. 提交阶段：第一阶段全部返回了Yes，进入提交阶段；如果有错误或者超时，进入Cancel阶段。

如果调用方发生宕机或超时，则第二阶段进行不断重试。

四、XA与TCC的区别

基于XA协议的两阶段提交（2PC）

  1. 概念

    分为两个部分，事务管理器和本地资源管理器

    本地资源管理器：由数据库实现XA接口

    事务管理器：作为全局的调度者，负责各个本地资源的提交和回滚

  2. 交互流程

    分为两个阶段，投票阶段和提交阶段

    投票阶段：参与者将自身操作结果反馈给协调者（全局事务管理器）

    提交阶段：协调者根据反馈上来的结果，决定各个参与者要全部提交还是全部回滚

  3. 缺点：算法执行过程中，所有节点进入阻塞状态，效率低

代码补偿事务（TCC）

  1. 交互流程

    分为两个步骤，预留资源和资源操作

    阶段1（Try）：做业务资源预留，进行业务的一致性检查，查看所有服务是否可以执行该操作

    阶段2（Confirm）：确认执行业务操作，不做任何业务检查， 只使用Try阶段预留的业务资源

    阶段3（Cancel）：取消Try阶段预留的业务资源

  2. 缺点：侵入性

XATCC
一致性资源层面的分布式事务，强一致性业务层面的分布式事务，弱一致性（最终一致性）
侵入性无侵入性侵入性强
依赖支持需要数据源支持XA接口无

五、最终一致性

场景描述：转账请求场景

解决方案一：消息中间件无法提供事务消息，由业务方处理，建立消息表的形式，不再直接发送给消息中间件，而是将消息写入写入消息表，扣钱和写消息表这个操作放在一个数据库事务中，保证两者的原子性。至于消息中间件的写入操作，通过另外的程序将消息表的消息源源不断输送给消息中间件，即使失败了也会重传，利用消息中间件的ACK机制，防止消息丢失。同时程序也要同步处理好消息重复逻辑。

解决方案二：利用RocketMQ事务消息机制处理，但是业务方还是需要设计判重机制，实现消息的幂等性。

方案的选择根据实际业务中使用的消息中间件决定。

六、阿里云Seata

文章目录
GitHub - seata/seata: Seata is an easy-to-use, high-performance, open source distributed transaction solution.
GitHub - seata/seata-samples: seata-samples
Seata部署指南

Seata是阿里巴巴开源的一个分布式事务框架，能够让大家在操作分布式事务时，像操作本地事务一样简单，一个注解搞定分布式事务。

事务模式

ta有4种分布式事务的实现方案

  • AT

    自动模式，业务方不需要写代码，使得应用代码可以像使用本地事务一样使用分布式事务，完全屏蔽了底层细节，前置条件：

    • 基于支持本地 ACID 事务的关系型数据库。
    • Java 应用，通过 JDBC 访问数据库。

    1. 业务通过 JDBC 标准接口访问数据库资源时，Seata 框架会对所有请求进行拦截
    2. 每个本地事务提交时，本地资源管理器（Resource Manager）会向TC事务协调器注册分支事务
    3. 请求链路调用完成，进入第二阶段，决定是否提交还是回滚

    接下来看看这三种组件的功能点

    • Transaction Coordinator (TC)

      事务协调器，维护全局事务的运行状态，负责协调并决定全局事务的提交或回滚

    • Transaction Manager（TM）

      控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议

    • Resource Manager (RM)

      资源管理器，负责本地事务的注册，本地事务状态的汇报(投票)，并且负责本地事务的提交和回滚

    其中，XID是一个全局事务的唯一标识。

  • TCC

    一个分布式的全局事务，整体是 两阶段提交 的模型。全局事务是由若干分支事务组成的，分支事务要满足 两阶段提交 的模型要求，即需要每个分支事务都具备自己的：

    • 一阶段 prepare 行为。
    • 二阶段 commit 或 rollback 行为。

    AT 模式（参考链接 TBD）基于 支持本地 ACID 事务 的 关系型数据库：

    • 一阶段 prepare 行为：在本地事务中，一并提交业务数据更新和相应回滚日志记录。
    • 二阶段 commit 行为：马上成功结束，自动 异步批量清理回滚日志。
    • 二阶段 rollback 行为：通过回滚日志，自动 生成补偿操作，完成数据回滚。

    相应的，TCC 模式，不依赖于底层数据资源的事务支持：

    • 一阶段 prepare 行为：调用 自定义 的 prepare 逻辑。
    • 二阶段 commit 行为：调用 自定义 的 commit 逻辑。
    • 二阶段 rollback 行为：调用 自定义 的 rollback 逻辑。

    所谓 TCC 模式，是指支持把 自定义 的分支事务纳入到全局事务的管理中。

  • Saga

    Saga模式是SEATA提供的长事务解决方案，在Saga模式中，业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现。

  • XA

    前置条件：

    • 支持XA 事务的数据库。
    • Java 应用，通过 JDBC 访问数据库。

使用方法

做之前，思路梳理清楚，每个服务都是一个RM资源管理器；另外有一个单独的TM服务，专门进行全局各个服务的调用；最后TC事务协调器，其实我们单独开启的Seata服务就是一个事务协调器。

我们将使用的流程梳理一下

  1. 前期准备

    • 下载Seata服务代码至本地项目；

    • 创建单独的数据库，记录分支信息；

    • 每个业务数据库中创建undo_log表，记录回滚操作；

  2. 修改Seata服务的registry.conf配置文件

    • 连接注册中心；
    • 连接Seata数据库；

  3. 所有涉及分布式事务的项目（包括Seata服务本身），全部引入alibaba-seata的pom依赖

  4. 修改项目的配置文件，加入Seata独有的一些配置，例如是否使用分布式事物等

    #是否使用分布式事物
seata: 
  enabled: true
  application-id: seata-bus

  5. 在业务层上，对某个调用了多服务的数据库操作方法打上注解开启分布式事务

        @GlobalTransactional
    public Boolean RunDemo(){
        // 服务A调用
        // .....
        // 服务B调用
        // .....
        // 服务C调用
        // .....
        return true;
    }

  6. 进行测试，查看效果

  7. 我贴个依赖放在这给自己看

    <!-- https://mvnrepository.com/artifact/com.alibaba.cloud/spring-cloud-alibaba-seata -->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-alibaba-seata</artifactId>
    <version>2.2.0.RELEASE</version>
</dependency>

服务端部署

111

客户端部署

1111

七、同步事务状态表+异步事务补偿

业务方自身实现的TCC思维，调用方维护一张事务状态表（或者事务日志、日志流水），每次调用之前，将一条事务流水落盘，生成一个全局的事务ID

每次成功调用，更新事务状态，然后有一个后台任务，定时扫描事务状态表，如过了一段时间，状态没有变成最终的4，则强制重新调用各个子系统，保证到达最终状态，当然这里要保证重复的幂等性操作。

如果重试一段时间还是不成功，则标记error，人工介入处理。

八、同步双写（多写）+异步对账

首先描述场景

  1. 微博的关注关系：分库分表，关注表与粉丝表，每次业务操作需要双写，需要保证数据原子性与一致性；
  2. 电商的订单系统：分库分表，卖家分库与卖家分库，同时也是每次操作需要双写；

上面的例子，合适的解决办法就是，每次操作后进行一次对账，但是对账有一个关键点：要有对账的基准值。

从实现层面，有大致几种对账方式：

  • 异步消息对账

    每次业务采用双写操作，对账基准写成功后，抛出消息给中间件，由一个消费者去消费这条消息，对两个库里的数据进行比对，用正确（基准）的一方去补齐缺失的一方。但是消息可能丢失，所以需要下方的全量后台任务对账做兜底。

  • 全量后台任务对账

    放一个定时任务，每天晚上运行比对。

  • 增量后台任务对账

    基于数据库的更新时间，每隔一段时间只对账增量的数据。

基于上述的技术层面，还有基于业务层面的。例如在订单状态中，包含“已支付”、“下发给仓库”、“出仓完成”等，通过从业务层面分析制定相应的对账计划也可以进行处理。

对账的关键还是在于找到“业务数据背后的规律”，基于规律去进行数据比对。

九、弱一致性+基于状态的事后补偿

总结上述的方案，发现存在以下几点问题：

  • 最终一致性是一种异步的方法，数据有一定的延迟；
  • TCC是同步方法，但是TCC需要两个阶段，有一定的性能损耗；
  • 事务状态表同理，也有一定的性能损耗；
  • 对账也是一个事后过程；

列举业务场景：电商平台的商品下单，需要同时创建订单+扣库存，调用了两个系统，如何保证它们的原子性，并且能抗住高并发？既要满足高并发，又要达到一致性，鱼和熊掌不可谦得，所以我们利用业务的特殊性，使用弱一致性解决。

例如在电商场景中，允许库存“多扣”，但是不允许“少扣”，通过失败后的不断调用重试+后台异步库存回收机制解决，最关键的是一定要记录日志流水，不细说。

十、重试+回滚+报警+人工修复

略。

十一、总结

分布式事务的解决思路

  • 2PC
  • 1PC

结束

avatar
文章
阅读
粉丝