シータベースの分散トランザクションソリューション

序文

前回の記事では、分散トランザクションの基本的なソリューションについて予備的な理解を深めましたが、本日は、分散トランザクションミドルウェアSeataと、自分で作成したseataに基づく分散トランザクションのデモを紹介します。

テキスト

背景

2019年1月、アリババのミドルウェアチームは、オープンソースプロジェクトFescar（Fast＆EaSy Commit And Rollback）を立ち上げ、コミュニティと協力して、オープンソースの分散トランザクションソリューションを構築しました。Fescarのビジョンは、分散トランザクションの使用をローカルトランザクションの使用と同じくらい簡単かつ効率的にし、開発者が遭遇する分散トランザクションのすべての問題を徐々に解決することです。Fescarがオープンソースになった後、Ant FinancialはFescarコミュニティに参加して共同構築に参加し、0.4.0バージョンのFescarのTCCモデルに貢献しました。より中立で、オープンで、生態学的に豊かな分散トランザクションオープンソースコミュニティを構築するために、コミュニティのコアメンバーによる投票の後、全員がFescarのブランドをアップグレードすることを決定し、Seataに名前を変更しました。つまり、シンプルで拡張可能な自律型トランザクションアーキテクチャがセットになっています。ワンストップの分散トランザクションソリューション。

シータとは？

Seataは、高性能で使いやすい分散トランザクションサービスの提供に特化したオープンソースの分散ソリューションです。その設計の当初の意図は次のとおりです。

ビジネスへの侵入なし：ここでの侵入とは、分散トランザクションの技術的な問題の制約による、ビジネスレベルでのアプリケーションの設計と変換を指します。この設計と変更は、多くの場合、アプリケーションに高いR＆Dとメンテナンスコストをもたらします。ミドルウェアレベルで分散トランザクションの問題を解決するために、アプリケーションがビジネスレベルで追加の作業を行う必要はありません。
高パフォーマンス：分散トランザクションの保証を導入すると、必然的に追加のオーバーヘッドが発生し、パフォーマンスが低下します。分散トランザクションの導入によるパフォーマンスの損失を非常に低いレベルに減らし、分散トランザクションの導入によるアプリケーションのサービスの可用性による影響を回避

SeataはユーザーにATモード、TCCモード、Sogaモード、XAトランザクションモードを提供し、ユーザーのためのワンストップ分散トランザクションソリューションを作成します。

我们先来了解一下Seata的重要的组件：

Transcation Coordinator(TC)：事务协调器，维护全局事务的事务状态，负责协调并驱动全局事务的提交或回滚即Seata-server
Transaction Manager(TM): 维护全局事务的边界，负责开启一个全局事务，并负责发起全局事务的提交或者回滚的决议即Seata-Client,事务的发起者，整个微服务调用链的起点
Resource Manger(RM): 控制分支事务，负责注册分支事务，分支事务状态的汇报，并接受事务协调器的指令，驱动本地事务的提交或者回滚即Seata-Client, 事务的参与者，负责本地事务的处理以及与Seata-server的交互

一个典型的分布式事务过程：

TM 向TC发起创建一个全局事务，TC创建全局事务成功并生成一个全局唯一的XID
XID在整个服务调用上下文中传递
RM向TC注册分支事务，并入对应XID的全局事务的管辖下
TM 向TC 发起对应XID全局事务的提交或回滚决议
TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。

接下来介绍下Seata各个事务模式

AT模式

AT模式的使用的提前是：一是基于支持ACID的关系数据库，而是Java应用，通过JDBC访问数据库。AT模式其实是对基于XA解决方案的改进，将资源管理器从数据库层面抽离出来，而已二方包的形式作为中间件层部署在应用的一侧。不依赖与数据库本身对协议的支持，当然也不需要数据库支持 XA 协议。

它的基本步骤：

一阶段：

解析业务sql
获取sql执行前的镜像，前镜像
执行业务sql
获取sql执行后的镜像，后镜像
添加undo_log日志，把前后镜像数据和业务sql相关的信息组成回滚日志，添加到undo_log表中
向TC注册分支事务，并申请全局锁
事务提交，将业务操作和undo_log一起提交
释放本地锁与数据库连接资源

二阶段-提交：

收到TC发出的提交分支事务的请求，将请求放进一个异步任务队列中，马上返回成功给TC
异步任务阶段的分支提交请求将异步和批量地删除相应 UNDO LOG 记录

二阶段-回滚：

收到TC发出的回滚请求，开启一个事务
根据XID和Branch ID 查找对应的UNDO_LOG记录
数据校验：拿 UNDO LOG 中的后镜与当前数据进行比较，如果有不同，说明数据被当前全局事务之外的动作做了修改。这种情况，需要根据配置策略来做处理
根据 UNDO LOG 中的前镜像和业务 SQL 的相关信息生成并执行回滚的语句
提交本地事务

这时有的同学可能会问为啥它能在第一阶段就能释放锁呢

Seata的JDBC 数据源代理通过对业务 SQL 的解析，把业务数据在更新前后的数据镜像组织成回滚日志，利用本地事务的 ACID 特性，将业务数据的更新和回滚日志的写入在同一个本地事务中提交。这样就可以保证：任何提交的业务数据的更新一定有相应的回滚日志存在。基于这样的设计，就可以在第一阶段释放本地锁

那么AT模式如何保证写隔离的呢

本地事务在commit之前都会去申请全局锁，需要确保拿到全局锁才能commit
拿不到全局锁便不会commit
申请全局锁有限制范围，超出了这个范围，就会回滚本地事务并释放本地锁

如何保证读隔离

Seata的AT模式默认的全局隔离级别是读未提交。如果应用在特定场景下，必需要求全局的读已提交，目前Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。SELECT FOR UPDATE 语句的执行会申请全局锁，如果全局锁被其他事务持有，则释放本地锁（回滚 SELECT FOR UPDATE 语句的本地执行）并重试。这个过程中，查询是被 block 住的，直到全局锁拿到，即读取的相关数据是已提交的，才返回。出于总体性能上的考虑，Seata目前的方案并没有对所有SELECT语句都进行代理，仅针对 FOR UPDATE 的 SELECT 语句。

AT模式优缺点

优点：

不需要数据库对XA协议的支持
并发和吞吐量提升，本地锁在第一阶段就可以释放

缺点

只能用在支持ACID的关系型数据库
事务隔离级别最高支持到读已提交的水平，SQL 的解析还不能涵盖全部的语法等。

TCC模式

TCC模式可以把自定义的分支事务纳入到全局事务之中，不依赖于底层数据资源对事务的依赖

它的处理过程是：

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

@LocalTCC
public interface TccAcountAction {

    @TwoPhaseBusinessAction(name = "DubboTccActionTwo" , commitMethod = "commit", rollbackMethod = "rollback")
    public boolean prepare(BusinessActionContext actionContext,
                           @BusinessActionContextParameter(paramName = "b") String b,
                           @BusinessActionContextParameter(paramName = "c", index = 0) List list);

    public boolean commit(BusinessActionContext actionContext);


    public boolean rollback(BusinessActionContext actionContext);
}
复制代码

整个事务的过程：

TM 向TC发起创建一个全局事务，TC创建全局事务成功并生成一个全局唯一的XID
依次执行分支事务
- 向TC注册分支事务
执行事务的prepare阶段即调用prepare方法
提交或者回滚全局事务，TC向每个RM发起commit或者rollbac，即调用写好的commit或者rollback方法

TCC模式的优缺点

优点：

可以把众多非事务的资源纳入纳入全局事务的管理，如缓存

缺点：

要自己实现补偿逻辑

Soga模式

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

Saga的实现：

目前SEATA提供的Saga模式是基于状态机引擎来实现的，机制是：

通过状态图来定义服务调用的流程并生成 json 状态语言定义文件
状态图中一个节点可以是调用一个服务，节点可以配置它的补偿节点
状态图 json 由状态机引擎驱动执行，当出现异常时状态引擎反向执行已成功节点对应的补偿节点将事务回滚

注意: 异常发生时是否进行补偿也可由用户自定义决定

可以实现服务编排需求，支持单项选择、并发、子流程、参数转换、参数映射、服务执行状态判断、异常捕获等功能

适用场景：

业务流程长、业务流程多
参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口

优势：

一阶段提交本地事务，无锁，高性能
事件驱动架构，参与者可异步执行，高吞吐
补偿服务易于实现

缺点：

不保证隔离性

小编自己也写了一个基于Seata的AT模式/TCC模式的demo，github地址：https://github.com/GBBP1813/seata-use

基于分布式事务中间件seata的分布式解决方案

本Demo工程基于seata/seata-sample实现AT/MT模式

涉及技术栈：

springboot dubbo zookeeper

使用本案例demo步骤

1.准备项目

克隆此项目到本地，导入idea，JDK为1.8 创建业务数据库 sql在项目中包括undo表

模块：

Seata-order 订单服务模块

Seata-storage 库存服务模块

Seata-account 账户服务模块

Seata-common 公共模块

Seata-transcation-manage TM模块

2.环境准备

1）先下载seata-server 地址：https://github.com/seata/seata/releases 下载完后修其数据库配置

由于demo使用的是db模式存储事务日志，要创建三张表：global_table，branch_table，lock_table，建表sql在上面下载的seata-server的/conf/db_store.sql中；配置文件事务组也可以自己修改，修改的话项目中也要对应变更

2）启动本地zookeeper

3）启动seata-server

3.启动项目

分别启动项目四个子模块

4.模拟请求

AT模式

Commit：

curl -H "Content-Type:application/json" -X POST -d '{"userId":"1","commodityCode":"C201901140001","name":"电脑","count":1,"amount":"10"}' 'localhost:8004/tmManager/buy'
复制代码

Rollback：

curl -H "Content-Type:application/json" -X POST -d '{"userId":"1","commodityCode":"C201901140001","name":"电脑","count":1,"amount":"10"}' 'localhost:8004/tmManager/buy?throwExp=true'
复制代码

TCC模式：

Commit:

curl -H "Content-Type:application/json" -X POST -d ''  'localhost:8004/tcc/bug'
复制代码

Rollback:

curl -H "Content-Type:application/json" -X POST -d ''  'localhost:8004/tcc/bug?throwExp=true'
复制代码