那些用Go实现的分布式事务框架(二)

开篇

上一篇那些用Go实现的分布式事务框架我们主要介绍的是seata-golang。一个对标seata的go语言实现，当然版本还是落后Java版很多的。

这次我们来介绍一下另一个go实现的分布式事务:dtm。

首先来看下dtm整体架构图(来源官网)。

再来看之前的seata架构图。

从架构上来看，大差不差。

seata中的TC对标dam的TM。

RM两边意思一致。

seata中的TM对标dtm事务SDK。作用都是一样:第一阶段开启一个全局事务,执行各RM分支事务，第二阶段根据RM第一阶段执行结果，决定调用TC(seata)|TM(dtm) commit或者rollback。

架构上，个人感觉只是因为模块名称以及图画不一样的差别，当然在实现细节上还是有很大差别的。

我们先简单介绍下DTM各个模块。

TM 层在代码中是没有具体的主体结构的，开始都是函数之前的调用。

启动TM实际上开启了两个服务，http以及grpc这两个服务。

http路由，

gRPC接口，

即然提供了两个服务入口，那理所当然有公共处理核心业务的部分。

TM对数据的存储管理并不是依赖于接口，而是依赖于common.DB 结构。根据配置文件中DB.driver 的值决定底层数据库是mysql还是postgres两种。

再看这个DB结构，所以本质上无论底层是哪种数据库，都是直接依赖gorm来对数据进行操作的。

接着，看下TM是如何通知各个RM进行commit或者rollback的？

举一个TCC模式的例子。

TCC的两个阶段。

从上面我们可以得知，TCC模式下，TM在第二阶段要么通知各分支事务Confirm要么Cancel。

在注册各RM事务分支到TM的时候，最终TM会为每一个分布式事务的参与者(RM)生成两条分支信息。

就像这样，

对，就是把对应的RM资源操作地址直接存入。

当TM接收到commit或者rollback命令，在处理完自身逻辑(一般就是修改Gloable状态)，就需要开始处理每一个注册进来的分支事务了，说白了就是需要调用各个分支事务对应操作的接口。

这里的t.getProcessor() 是需要根据当前事务的类型(TCC、SAGA、XA)获取到对应的处理器来进行逻辑的处理。

当然，每个事务处理器只需要实现接口，

真正调用RM资源服务地址的时候，分为http和grpc，这是由开发者决定的。

在v1.6之前的版本，grpc的请求是很简单粗暴解析地址方法然后连接的。

现在为了支持那些采用gRPC Resolver 机制之上的一些微服务框架接入，做了一块抽象。感兴趣[1]可以看下，这里就不介绍了。

至于SDK，每一个事务模式都是独立的，本质上是没有关联的。比如下面我们启动一个TCC分布式事务。这个分布式事务是由两个服务组成，简称+30和-30的服务。

从上面的调用中我们还是能还原出整体流程。

调用TM，得到一个分布式id
调用TccGlobalTransaction函数开启分布式事务。
调用TM prepare(这步只是为了查看第一步产生的那个分布式事务状态是否处于prepare。这里没看明白，此时还未注册执行分支，全局状态不是应该只会存在初始化状态吗)
上一步没问题，执行传入的闭包函数，即CallBranch 函数里向TM注册参与事务的TM分支。注册完成后，开始第一阶段调用各分支的try服务。
各分支try服务调用结束，根据第一阶段结果决定通知TM是submit还是abort。

另外提一点，分布式事务常见的一些问题:比如空补偿、重挂等问题。

一般情况下，业务需要自行去处理这种场景，以免造成不可描述的错误。

dtm里面提供了对应子事务屏障方案。核心就在，