EasyTransaction主要源码分析

EasyTransaction是一个全功能的分布式事务框架，以下特性摘抄自其首页：https://github.com/QNJR-GROUP/EasyTransaction

  • 一个框架包含多种事务形态，一个框架搞定所有类型的事务
  • 多种事务形态可混合使用
  • 高性能,大多数业务系统瓶颈在业务数据库，若不启用框架的幂等功能，对业务数据库的额外消耗仅为写入25字节的一行
  • 可选的框架自带幂等实现及调用错乱次序处理，大幅减轻业务开发工作量,但启用的同时会在业务数据库增加一条幂等控制行
  • 业务代码可实现完全无入侵
  • 支持嵌套事务
  • 无需额外部署协调者，不同APP的服务协调自身发起的事务，也避免了单点故障
  • 分布式事务ID可关联业务ID，业务类型，APPID，便于监控各个业务的分布式事务执行情况

本文主要分享EasyTransaction core中各个package的作用其主要实现。

请先阅读 Seata架构的比对思考 https://www.cnblogs.com/skyesx/p/10674700.html ，再结合 代码以及demo调试过程看这篇，直接看的话这里的点太零碎了

一、context包

主要类

LogProcessContext

其用于存储ET事务的上下文信息。在开启ET事务（第一次ET远程调用，或者主动调用startSoftTrans方法）时，将创建本类的实例并将其与Spring的本地事务上下文绑定，通过：

TransactionSynchronizationManager.bindResource()

执行绑定。当需要取得ET上下文时，通过

TransactionSynchronizationManager.getResource()

取得。

ET上下文中包含的主要内容有：

  • 最终事务状态
  • 全部的全局事务日志
  • 未Flush到外部的全局事务日志
  • 事务ID等内容

二、包core

本包主要类为

EasyTransFacade
TransactionHook
ConsistentGuardian
ExecuteCacheManager

类EasyTransFacade

其定义了业务调用方的接口，只包含两个：

public void startEasyTrans(String busCode,long trxId);

public <P extends EasyTransRequest<R,E>,E extends EasyTransExecutor, R extends Serializable> Future<R> execute(P params);

第一个用于开启全局事务，主要的操作为：

  • 挂载TransactionHook到当前的Spring本地事务中，使得可以在关键节点（如本地事务提交前、本地事务回滚后等等）嵌入ET的代码
  • 将 LogProcessContext 绑定到当前的Spring本地事务，使得ET可以在当前Spring本地事务中随时取得ET全局事务的状态。
  • 在当前已开启的本地事务中，写入一条事务执行记录到业务库中，其对Crash恢复时识别全局事务的状态起关键作用

第二个表示执行某个远程事务方法。

  • 通过调用参数Object对应的Class获取对应的处理器（如TCC处理器，可靠消息处理器等）并执行调用，具体调用的形态后续专门的章节再继续

基于注解的接口调用也是通过这两个方法封装而成。

类TransactionHook

其为ET框架代码与Spring原生事务的主要交界点，ET通过TransactionSynchronization定义的方法，在Spring本地事务执行过程中，扩展支持了全局事务。主要扩展了以下两个方法

beforeCommit(boolean readOnly)
afterCompletion(int status)

beforeCommit方法将会

  • 在Spring本地事务提交前将所有未落盘的全局事务日志落盘
  • 并执行所有未执行的远程调用（ET会尽量延后全局事务以此堆积并批量执行）
  • 若有不成功的全局事务，则抛出异常，回滚事务（包括本地以及全局）

afterCompletion方法将会

  • 获取本地事务的最终结果（提交/回滚/未知）以及 ET父级事务的状态（提交/回滚/未知）来决定本级ET事务的最终状态（提交/回滚/未知）
  • 获得最终的本级ET事务状态后，异步执行最终一致处理（调用consistentGuardian.process）

类ConsistentGuardian

本类用于处理ET全局事务的最终一致，例如TCC的Conifrim/Cancel,可靠消息的发送消息。

最终一致处理通常会在同步操作（TCC的TRY等）对应的本地事务执行完成后抛到线程池异步执行，但执行失败的话，会有兜底的补偿（recovery包），后续再详细讲述

该类的主要工作机制是根据之前写入的全局事务日志，获取日志对应的处理器（如从TCC的事务日志获取对应的TCC日志处理器），以此

  • 判断当前ET事务的最终状态（若当前ET事务状态仍未确定的话）
  • 传入最终ET事务状态到日志处理器，依次处理对应的事务日志，处理的典型过程例子：
    • 若存在TRY方法对应的日志
    • 并且找不到TRY对应的CONFRIM/CANCEL日志
    • 则根据ET最终事务状态，调用对应CONFIRM/CANCEL方法

类ExecuteCacheManager

本类主要服务于ET的以下期望

  • 批量写入ET事务日志（以减少IO）
  • 批量并发执行远程业务调用(以减少串行等待远程相应时间)

其主要实现的是，

  • 对每个传入的Calleble对象都返回一个经过改写的Futrure对象
  • 当任意一个Futrue的get方法都没有被调用前，所有之前传入的Callable对象都不会执行。
  • 当任意一个Future的get被调用时，所有callable都会被批量执行，这里包含了批量写入日志以及批量并发执行远程调用

三、包datasource

主要包含以下两个接口，其主要作用于业务数据源。

DataSourceSelector
TransStatusLogger

类DataSourceSelector

该类主要用于获取当前事务/请求对应的数据源及其事务管理器，若应用有多个业务数据源，则需要自行实现对应的数据源选择器，主要包含以下方法

DataSource selectDataSource(String appId,String busCode,long trxId);
DataSource selectDataSource(String appId,String busCode,EasyTransRequest<?, ?> request);

第一个方法是开启ET事务时候选择对应的数据源

第二个方法是被调用方接受到请求时选择对应的数据源（用于幂等、防悬挂处理，若不需要可忽略）

该接口包含一个默认实现，当只有单数据源时，可以直接用该实现

SingleDataSourceSelector

类TransStatusLogger

该类主要用来读写用于判断ET事务状态的记录，该记录会在ET事务开启时，写入当前的数据库表中，随着业务对应事务（Spring本地事务）提交而提交，回滚而回滚。

更具体请直接看实现

四、包executor

该包存储的是事务发起方（远程服务调用方）相关处理类的位置，不同的事务类型（TCC,可靠事务等）有不同的Executor,以TCC为例讲解，其他的事务类型实现都类似。

TccMethodExecutor

该类实现了三个接口

  • EasyTransExecutor
  • LogProcessor
  • DemiLogEventHandler

EasyTransExecutor接口定义了方法

	<P extends EasyTransRequest<R,E>,E extends EasyTransExecutor,R  extends Serializable> Future<R> execute(Integer sameBusinessCallSeq, P params);

该方法供类EasyTransFacade.execute使用，其对应的是执行TCC里的TRY方法，具体的，它

  • 将TRY方法调用对应的RPC请求包装成Runnable类
  • 构建本次调用对应的全局事务日志（主要包含本次调用的具体参数、对应远程方法等）
  • 然后传入上面章节提到的类ExecuteCacheManager方法中

LogProcessor接口定义了如何处理事务日志，其包含一个主要方法

	boolean logProcess(LogProcessContext ctx, Content currentContent)

该方法将会判断，如果传入的日志类型是PreTccCallContent（TCC TRY请求对应的日志）的话，将会监听该日志最终的配对信息（类ConsistentGuardian会在处理当前ET事务的日志后，发送消息，告知所有需要配对的日志的配对结果），如果

  • 监听到成功配对（找到CONFIRM或者CANCEL对应的日志）的消息，则不再做后续处理
  • 监听到配对失败（没有存在对应的CONFIRM/CANCEL日志）的消息，则根据当前的ET事务状态执行对应的CONFIRM或者CANCEL操作，并记录对应的日志

其他的事务形态的实现也类似，不再赘述

五、包recovery

用于兜底恢复事务，实现最终一致。

代码不复杂，可以自行查看。

六、包Filter

该包主要用于实现ET对应的Filter，该Filter作用于被调用端。我们可以通过实现ET的Filter扩展被调用端的功能，如处理幂等、处理嵌套事务、增加调用上下文的处理等等。

七、包idempotent

实现幂等、方悬挂等处理对应的包

幂等及防悬挂处理的主要原理：

  • 当远程调用过来时，写入调用日志到当前的开启的业务日志中，并记录 调用对应的ID,调用参数对应的MD5
  • 有结果返回时就将结果更新存储到日志中
  • 当有重复请求过来时，就检查ID对应的记录是否存在，若存在则检查参数的MD5是否一致，若一致则返回之前的存储结果
  • 防悬挂也类似，在上述的日志中，将会记录调用的方法是什么，如
    • 当找不到请求对应日志时，但当前为cancel操作的话，框架将直接返回成功
    • 上述cancel已经成功执行后，try方法再来到时，发现cancel已经执行，就直接将try报错返回

八、包idgen

用于生成ET的分布式事务ID，当自行制定ID时，本包对应的方法不会被调用。当不指定ID时，将会自动生成一个。

九、包log

定义ET事务日志对应的Class，以及其读写接口。
事务日志在之前TccExecutor等章节已提到，不再赘述。

需要扩展事务日志存储实现的，直接实现以下接口即可

TransactionLogReader
TransactionLogWritter

（ET事务日志的读写不需要与业务事务在同一个事务中，也不能在同一个事务中）

十、包master

用于在同一个appId中选择一个作为master进行兜底最终一致补偿的包。

实际上选择不需要太精确，任意一个appId下的实例均可，也可以同时有多个master存在（但目前没有意义，也会浪费性能）

十一、包monitor

用于提供ET实例状态的包，可供Dashboard，监控等扩展使用

十二、包protocol

供客户直接定义分布式事务服务的包，其包含一些客户直接使用的 父类、配置接口、配置注解等

十三、包provider.factory

从Spring中获取并存储对应的bean实现，以便于快速方便地通过ET对应的定义，取得对应bean

十四、包queue

若要扩展新增对应的消息队列实现，则实现这个包对应的接口

十五、包rpc

同上

十六、包serialization

ET框架所使用的序列化形式，可自行扩展

十七、包stingcodec

用于压缩字符串，将字符串替换为数字id，以提高存储效率

posted @ 2019-06-30 23:11  YOYO&#  阅读(5031)  评论(0)  编辑  收藏  举报