深度剖析一站式分布式事务方案 Seata-Server

本文做者李钊，公众号「咖啡拿铁」做者，分布式事务 Seata 社区 Contributor。

1.关于Seata

在前不久，我写了一篇关于分布式事务中间件 Fescar 的解析，没过几天 Fescar 团队对其进行了品牌升级，取名为 Seata(Simpe Extensible Autonomous Transcaction Architecture)，而之前的 Fescar 的英文全称为 Fast & EaSy Commit And Rollback。能够看见 Fescar 从名字上来看更加局限于 Commit 和 Rollback，而新的品牌名字 Seata 旨在打造一套一站式分布式事务解决方案。更换名字以后，我对其将来的发展更有信心。

这里先大概回忆一下 Seata 的整个过程模型：

• TM：事务的发起者。用来告诉 TC，全局事务的开始，提交，回滚。
• RM：具体的事务资源，每个 RM 都会做为一个分支事务注册在 TC。
• TC 事务的协调者。也能够看作是 Fescar-server，用于接收咱们的事务的注册，提交和回滚。

在以前的文章中对整个角色有个大致的介绍，在这篇文章中我将重点介绍其中的核心角色 TC，也就是事务协调器。

2.Transaction Coordinator

为何以前一直强调 TC 是核心呢？那由于 TC 这个角色就好像上帝同样，管控着芸芸众生的 RM 和 TM。若是 TC 一旦很差使，那么 RM 和 TM 一旦出现小问题，那一定会乱的一塌糊涂。因此要想了解 Seata，那么必需要了解他的 TC。

那么一个优秀的事务协调者应该具有哪些能力呢？我以为应该有如下几个：

• 正确的协调：能正确的协调 RM 和 TM 接下来应该作什么，作错了应该怎么办，作对了应该怎么办。
• 高可用：事务协调器在分布式事务中很重要，若是不能保证高可用，那么他也没有存在的必要了。
• 高性能：事务协调器的性能必定要高，若是事务协调器性能有瓶颈，那么他所管理的 RM 和 TM 会常常遇到超时，从而引发回滚频繁。
• 高扩展性：这个特色是属于代码层面的，若是是一个优秀的框架，那么须要给使用方不少自定义扩展，好比服务注册/发现，读取配置等等。

下面我也将逐步阐述 Seata 是如何作到上面四点。

2.1 Seata-Server 的设计

Seata-Server 总体的模块图如上所示：

• Coordinator Core：最下面的模块是事务协调器核心代码，主要用来处理事务协调的逻辑，如是否 Commit、Rollback 等协调活动。
• Store：存储模块，用来将咱们的数据持久化，防止重启或者宕机数据丢失。
• Discover：服务注册/发现模块，用于将 Server 地址暴露给 Client。
• Config：用来存储和查找服务端的配置。
• Lock：锁模块，用于给 Seata 提供全局锁的功能。
• Rpc：用于和其余端通讯。
• HA-Cluster：高可用集群，目前还没开源。为 Seata 提供可靠的高可用功能。

2.2 Discover

首先来说讲比较基础的 Discover 模块，又称服务注册/发现模块。咱们将 Seata-Server 启动以后，须要将本身的地址暴露给其余使用者，那么就须要这个模块帮忙。

这个模块有个核心接口 RegistryService，如上图所示：

• register：服务端使用，进行服务注册。
• unregister：服务端使用，通常在 JVM 关闭钩子，ShutdownHook 中调用。
• subscribe：客户端使用，注册监听事件，用来监听地址的变化。
• unsubscribe：客户端使用，取消注册监听事件。
• lookup：客户端使用，根据 Key 查找服务地址列表。
• close：均可以使用，用于关闭 Register 资源。

若是须要添加本身定义的服务注册/发现，那么实现这个接口便可。截止目前在社区的不断开发推进下，已经有四种服务注册/发现，分别是 redis、zk、nacos、eruka。下面简单介绍下 Nacos 的实现：

2.2.1 register 接口

step1：校验地址是否合法；

step2：获取 Nacos 的 Name 实例，而后将地址注册到当前 Cluster 名称上面。

unregister 接口相似，这里不作详解。

2.2.2 lookup 接口

step1：获取当前 clusterName 名字；

step2：判断当前 Cluster 是否已经获取过了，若是获取过就从 Map 中取；

step3：从 Nacos 拿到地址数据，将其转换成咱们所须要的；

step4：将咱们事件变更的 Listener 注册到 Nacos。

2.2.3 subscribe 接口

这个接口比较简单，具体分两步：

step1：将 Clstuer 和 Listener 添加进 Map 中；

step2：向 Nacos 注册。

2.3 Config

配置模块也是一个比较基础，比较简单的模块。咱们须要配置一些经常使用的参数好比：Netty 的 Select 线程数量，Work 线程数量，Session 容许最大为多少等等，固然这些参数在 Seata 中都有本身的默认设置。

一样的在 Seata 中也提供了一个接口 Configuration，用来自定义咱们须要的获取配置的地方：

• getInt/Long/Boolean/Config()：经过 DataId 来获取对应的值。
• putConfig：用于添加配置。
• removeConfig：删除一个配置。
• add/remove/get ConfigListener：添加/删除/获取 配置监听器，通常用来监听配置的变动。

目前为止有四种方式获取 Config：File（文件获取）、Nacos、Apollo、ZK。在 Seata 中首先须要配置 registry.conf，来配置 conf 的类型。实现 conf 比较简单这里就不深刻分析。

2.4 Store

存储层的实现对于 Seata 是否高性能，是否可靠很是关键。

若是存储层没有实现好，那么若是发生宕机，在 TC 中正在进行分布式事务处理的数据将会被丢失。既然使用了分布式事务，那么其确定不能容忍丢失。若是存储层实现好了，可是其性能有很大问题，RM 可能会发生频繁回滚那么其彻底没法应对高并发的场景。

在 Seata 中默认提供了文件方式的存储，下面定义存储的数据为 Session，而 TM 创造的全局事务数据叫 GloabSession，RM 创造的分支事务叫 BranchSession，一个 GloabSession 能够拥有多个 BranchSession。咱们的目的就是要将这么多 Session 存储下来。

在 FileTransactionStoreManager#writeSession 代码中:

上面的代码主要分为下面几步：

step1：生成一个 TransactionWriteFuture。

step2：将这个 futureRequest 丢进一个 LinkedBlockingQueue 中。为何须要将全部数据都丢进队列中呢？固然这里其实也能够用锁来实现，在另一个阿里开源的 RocketMQ 中使用的锁。不管是队列仍是锁，他们的目的是为了保证单线程写，这又是为何呢？有人会解释说，须要保证顺序写，这样速度就很快，这个理解是错误的，咱们的 FileChannel 实际上是线程安全的，已经能保证顺序写了。保证单线程写实际上是为了让这个写逻辑都是单线程的，由于可能有些文件写满或者记录写数据位置等等逻辑，固然这些逻辑均可以主动加锁去作，可是为了实现简单方便，直接再整个写逻辑加锁是最为合适的。

step3：调用 future.get，等待该条数据写逻辑完成通知。

咱们将数据提交到队列以后，接下来须要对其进行消费，代码以下：

这里将一个 WriteDataFileRunnable() 提交进线程池，这个 Runnable 的 run() 方法以下:

分为下面几步:

step1：判断是否中止，若是 stopping 为 true 则返回 null。

step2：从队列中获取数据。

step3：判断 future 是否已经超时了，若是超时，则设置结果为 false，此时咱们生产者 get() 方法会接触阻塞。

step4：将数据写进文件，此时数据还在 pageCache 层并无刷新到磁盘，若是写成功而后根据条件判断是否进行刷盘操做。

step5：当写入数量到达必定的时候，或者写入时间到达必定的时候，须要将当前的文件保存为历史文件，删除之前的历史文件，而后建立新的文件。这一步是为了防止文件无限增加，大量无效数据浪费磁盘资源。

在 writeDataFile 中有以下代码:

step1：首先获取 ByteBuffer，若是超出最大循环 BufferSize 就直接建立一个新的，不然就使用缓存的 Buffer。这一步能够很大的减小 GC。

step2：而后将数据添加进入 ByteBuffer。

step3：最后将 ByteBuffer 写入 fileChannel，这里会重试三次。此时的数据还在 pageCache 层，受两方面的影响，OS 有本身的刷新策略，可是这个业务程序不能控制，为了防止宕机等事件出现形成大量数据丢失，因此就须要业务本身控制 flush。下面是 flush 的代码：

这里 flush 的条件写入必定数量或者写的时间超过必定时间，这样也会有个小问题若是是停电，那么 pageCache 中有可能还有数据并无被刷盘，会致使少许的数据丢失。目前还不支持同步模式，也就是每条数据都须要作刷盘操做，这样能够保证每条消息都落盘，可是性能也会受到极大的影响，固然后续会不断的演进支持。

Store 核心流程主要是上面几个方法，固然还有一些好比 Session 重建等，这些比较简单，读者能够自行阅读。

2.5 Lock

你们知道数据库实现隔离级别主要是经过锁来实现的，一样的再分布式事务框架 Seata 中要实现隔离级别也须要经过锁。通常在数据库中数据库的隔离级别一共有四种：读未提交、读已提交、可重复读、串行化。在 Seata 中能够保证写的互斥，而读的隔离级别通常是未提交，可是提供了达到读已提交隔离的手段。

Lock 模块也就是 Seata 实现隔离级别的核心模块。在 Lock 模块中提供了一个接口用于管理锁：

其中有三个方法:

• acquireLock：用于对 BranchSession 加锁，这里虽然是传的分支事务 Session，其实是对分支事务的资源加锁，成功返回 true。
• isLockable：根据事务 ID，资源 ID，锁住的 Key 来查询是否已经加锁。
• cleanAllLocks：清除全部的锁。

对于锁咱们能够在本地实现，也能够经过 redis 或者 mysql 来帮助咱们实现。官方默认提供了本地全局锁的实现：

在本地锁的实现中有两个常量须要关注：

• BUCKET_PER_TABLE：用来定义每一个 table 有多少个 bucket，目的是为了后续对同一个表加锁的时候减小竞争。
• LOCK_MAP：这个 Map 从定义上来看很是复杂，里里外外套了不少层 Map，这里用个表格具体说明一下：

层数	key	value
1-LOCK_MAP	resourceId（jdbcUrl）	dbLockMap
2- dbLockMap	tableName （表名）	tableLockMap
3- tableLockMap	PK.hashcode%Bucket （主键值的 hashcode%bucket）	bucketLockMap
4- bucketLockMap	PK	trascationId

能够看见实际上的加锁在 bucketLockMap 这个 Map 中，这里具体的加锁方法比较简单就不做详细阐述，主要是逐步的找到 bucketLockMap ，而后将当前 trascationId 塞进去，若是这个主键当前有 TranscationId，那么比较是不是本身，若是不是则加锁失败。

2.6 RPC

保证 Seata 高性能的关键之一也是使用了 Netty 做为 RPC 框架，采用默认配置的线程模型以下图所示：

若是采用默认的基本配置那么会有一个 Acceptor 线程用于处理客户端的连接，会有 cpu*2 数量的 NIO-Thread，再这个线程中不会作业务过重的事情，只会作一些速度比较快的事情，好比编解码，心跳事件和TM注册。一些比较费时间的业务操做将会交给业务线程池，默认状况下业务线程池配置为最小线程为 100，最大为 500。

这里须要提一下的是 Seata 的心跳机制，这里是使用 Netty 的 IdleStateHandler 完成的，以下:

在 Sever 端对于写没有设置最大空闲时间，对于读设置了最大空闲时间，默认为 15s，若是超过 15s 则会将连接断开，关闭资源。

step1：判断是不是读空闲的检测事件；

step2：若是是则断开连接，关闭资源。

2.7 HA-Cluster

目前官方没有公布 HA-Cluster，可是经过一些其余中间件和官方的一些透露，能够将 HA-Cluster 用以下方式设计：

具体的流程以下：

step1：客户端发布信息的时候根据 TranscationId 保证同一个 Transcation 是在同一个 Master 上，经过多个 Master 水平扩展，提供并发处理性能。

step2：在 Server 端中一个 Master 有多个 Slave，Master 中的数据近实时同步到 Slave上，保证当 Master 宕机的时候，还能有其余 Slave 顶上来能够用。

固然上述一切都是猜想，具体的设计实现还得等 0.5 版本以后。目前有一个 Go 版本的 Seata-Server 也捐赠给了 Seata (还在流程中)，其经过 Raft 实现副本一致性，其余细节不是太清楚。

2.8 Metrics & Tracing

这个模块也是一个没有具体公布实现的模块，固然有可能会提供插件口，让其余第三方 metric 接入进来。另外最近 Apache SkyWalking 正在和 Seata 小组商讨如何接入进来。

3.Coordinator Core

上面咱们讲了不少 Server 基础模块，想必你们对 Seata 的实现已经有个大概，接下来我会讲解事务协调器具体逻辑是如何实现的，让你们更加了解 Seata 的实现内幕。

3.1 启动流程

启动方法在 Server 类有个 main 方法，定义了咱们启动流程：

step1：建立一个 RpcServer，再这个里面包含了咱们网络的操做，用 Netty 实现了服务端。

step2：解析端口号和文件地址。

step3：初始化 SessionHoler，其中最重要的重要就是重咱们 dataDir 这个文件夹中恢复咱们的数据，重建咱们的Session。

step4：建立一个CoorDinator,这个也是咱们事务协调器的逻辑核心代码，而后将其初始化，其内部初始化的逻辑会建立四个定时任务：

• retryRollbacking：重试 rollback 定时任务，用于将那些失败的 rollback 进行重试的，每隔 5ms 执行一次。
• retryCommitting：重试 commit 定时任务，用于将那些失败的commit 进行重试的，每隔 5ms 执行一次。
• asyncCommitting：异步 commit 定时任务，用于执行异步的commit，每隔 10ms 一次。
• timeoutCheck：超时定时任务检测，用于检测超时的任务，而后执行超时的逻辑，每隔 2ms 执行一次。

step5： 初始化 UUIDGenerator 这个也是咱们生成各类 ID(transcationId,branchId) 的基本类。

step6：将本地 IP 和监听端口设置到 XID 中，初始化 rpcServer 等待客户端的链接。

启动流程比较简单，下面我会介绍分布式事务框架中的常见的一些业务逻辑 Seata 是如何处理的。

3.2 Begin - 开启全局事务

一次分布式事务的起始点必定是开启全局事务，首先咱们看看全局事务 Seata 是如何实现的：

step1： 根据应用 ID，事务分组，名字，超时时间建立一个 GloabSession，这个再前面也提到过他和 branchSession 分别是什么。

step2：对其添加一个 RootSessionManager 用于监听一些事件，这里要说一下目前在 Seata 里面有四种类型的 Listener (这里要说明的是全部的 sessionManager 都实现了 SessionLifecycleListener)：

• ROOT_SESSION_MANAGER：最全，最大的，拥有全部的 Session。
• ASYNC_COMMITTING_SESSION_MANAGER：用于管理须要作异步 commit 的 Session。
• RETRY_COMMITTING_SESSION_MANAGER：用于管理重试 commit 的 Session。
• RETRY_ROLLBACKING_SESSION_MANAGER：用于管理重试回滚的 Session。
  因为这里是开启事务，其余 SessionManager 不须要关注，咱们只添加 RootSessionManager 便可。

step3：开启 Globalsession

这一步会把状态变为 Begin，记录开始时间,而且调用 RootSessionManager的onBegin 监听方法，将 Session 保存到 Map 并写入到咱们的文件。

step4：最后返回 XID，这个 XID 是由 ip+port+transactionId 组成的，很是重要，当 TM 申请到以后须要将这个 ID 传到 RM 中，RM 经过 XID 来决定到底应该访问哪一台 Server。

3.3 BranchRegister - 分支事务注册

当全局事务在 TM 开启以后，RM 的分支事务也须要注册到全局事务之上，这里看看是如何处理的：

step1：经过 transactionId 获取并校验全局事务是不是开启状态。

step2：建立一个新的分支事务，也就是 BranchSession。

step3：对分支事务进行加全局锁，这里的逻辑就是使用锁模块的逻辑。

step4：添加 branchSession，主要是将其添加到 globalSession 对象中，并写入到咱们的文件中。

step5：返回 branchId，这个 ID 也很重要，咱们后续须要用它来回滚咱们的事务，或者对咱们分支事务状态更新。

分支事务注册以后，还须要汇报分支事务的后续状态究竟是成功仍是失败，在 Server 目前只是简单的作一下保存记录，汇报的目的是，就算这个分支事务失败，若是 TM 仍是执意要提交全局事务，那么再遍历提交分支事务的时候，这个失败的分支事务就不须要提交。

3.4 GlobalCommit - 全局提交

当分支事务执行完成以后，就轮到 TM-事务管理器来决定是提交仍是回滚，若是是提交，那么就会走到下面的逻辑：

step1：首先找到 globalSession。若是他为 Null 证实已经被 commit 过了，那么直接幂等操做，返回成功。

step2：关闭 GloabSession 防止再次有新的 branch 进来。

step3：若是 status 是等于 Begin，那么久证实尚未提交过，改变其状态为 Committing 也就是正在提交。

step4：判断是不是能够异步提交，目前只有AT模式能够异步提交，由于是经过 Undolog 的方式去作的。MT 和 TCC 都须要走同步提交的代码。

step5：若是是异步提交，直接将其放进 ASYNC_COMMITTING_SESSION_MANAGER，让其再后台线程异步去作 step6，若是是同步的那么直接执行 step6。

step6：遍历 BranchSession 进行提交，若是某个分支事务失败，根据不一样的条件来判断是否进行重试，异步不须要重试，由于其自己都在 manager 中，只要没有成功就不会被删除会一直重试，若是是同步提交的会放进异步重试队列进行重试。

3.5 GlobalRollback - 全局回滚

若是咱们的 TM 决定全局回滚，那么会走到下面的逻辑：

这个逻辑和提交流程基本一致，能够看做是他的反向，这里就不展开讲了。

4.总结

最后在总结一下开始咱们提出了分布式事务的关键四点，Seata 究竟是怎么解决的：

• 正确的协调：经过后台定时任务各类正确的重试，而且将来会推出监控平台有可能能够手动回滚。
• 高可用: 经过 HA-Cluster 保证高可用。
• 高性能：文件顺序写，RPC 经过 netty 实现，Seata 将来能够水平扩展，提升处理性能。
• 高扩展性：提供给用户能够自由实现的地方，好比配置，服务发现和注册，全局锁等等。

最后但愿你们能从这篇文章能了解 Seata-Server 的核心设计原理，固然你也能够想象若是你本身去实现一个分布式事务的 Server 应该怎样去设计？

文中涉及的相关连接

• Seata github 地址：https://github.com/seata/seata
• 延伸阅读：蚂蚁金服分布式事务开源以及实践 | SOFA 开源一周年献礼

公众号：金融级分布式架构（Antfin_SOFA）