Go开源说第十七期 分布式事务DTM

大家好，很高兴到“Go开源说”跟大家分享DTM，我是叶东富，DTM作者，github：https://github.com/yedf

本次分享分为以下四个部分：

1. DTM是什么

2. 产生的背景

3. 可以解决什么问题

4. 发展现状与未来

我们按照开源项目的习惯，以一个类似Quick Start的例子来说明：

业务场景：A跨行转给B 30元，A、B分属不同银行

需求要点：

• 需要保证A-30和B+30，都成功，或都失败

• 中间任何一个地方发生故障，不能影响最终的数据一致性

• 因数据保存在多个数据库实例，无法通过本地事务解决

解决方案DTM：A Distributed Transaction Manager

在这个例子中：

1. 定义了一个Saga事务

2. Saga事务中的第一个子事务TransOut负责扣减A的余额

3. Saga事务中的第一个子事务TransIn负责增加B的余额

4. 完成了Saga事务定义之后，将事务提交给DTM

5. DTM将按顺序完成各项子事务

6. 如果中间出现临时的网络错误，DTM会负责重试

7. 如果业务返回失败，DTM会调用子事务的补偿操作，保证最终数据一致性

DTM是跨数据源、跨服务的数据一致性解决方案，他又可以分为以下三类：跨数据库、跨服务、混合

现在涌现出构建在分布式系统上的数据库--NewSQL，能够随着分布式系统的动态扩容而大幅提高系统的服务能力，例如谷歌的Spanner、国产的TiDB。NewSQL的事务是在分布式系统上构建的，也被称之为分布式事务，但是与我们在前面介绍的分布式事务在解决问题类型不同，所使用的核心技术也不同。

NewSQL事务主要解决的是数据库扩展到多Host下的ACID，聚焦在数据库系统层面，而DTM聚焦在应用层和多数据源之间的数据一致性。

随着我们公司业务的发展，交易系统越来越复杂，交易并发也越来越高。原先一个交易是放在一个本地事务里完成，由数据库来保证ACID。这种架构，一方面要求把所有订单交易的操作在一个服务，导致无法微服务化，这样就会把所有订单涉及的子系统耦合进订单中，复杂度很高；另一方面，订单修改库存到订单提交的这段时间里，库存是被锁定的，购买同一个商品的所有订单会因为扣库存的行锁导致串行，并发度低。

我们系统采用的语言栈是Node，调研之后，决定之后采用Go作为主栈。如果把交易系统全部用Go改写之后再上线，周期十分漫长，对业务非常不友好。我们需要做渐进式的改造，需要分布式事务支持一部分服务Go编写，一部分服务Node编写，然后把相关服务组合成一个全局的分布式事务。

我们调研了当时市面上的方案，最成熟、应用最广泛的是阿里开源的Seata，它是Java语言开发的，如果我们选用这个方案的话，需要把订单相关的系统，全部改造成Java，工作量巨大，预计要20人月以上。还有其他方案，例如hmily、tcc-transaction、ByteTCC，这些都是Java的方案，工作量都接近。

其他语言的分布式事务方案，没有看到成熟可用的，Go、PHP、Python、Node等语言搜索了一个遍，都未发现好的方案。

加上前面我们希望要一个渐进式的方案，需要支持多语言的子服务组合成一个全局事务，那么市面上的方案就更不可能了。综合评估下来，我们决定自己开发

我们开发的DTM架构如下：

图中左上角的Go客户端SDK等，都是轻量级的SDK，大约几十到几百行代码，新增一门语言支持非常容易。DTM服务器采用云原生友好的无状态服务，可以非常方便的动态扩容、做高可用，数据存储在数据库，和现在绝大多数公司的存储架构一致。

我们支持了类似如下的多语言，能够采用各种语言编写子服务，最终组合成一个全局事务：

DTM提供了跨数据源分布式事务的一站式解决方案，支持的事务模式包括：可靠消息、事务消息、TCC、SAGA、XA。而在这些事务模式中，有一个难点问题是如果中间发生异常，导致子事务乱序要怎么解决。

典型的异常分为三类，：

• 空补偿：可能出现回滚请求在正向操作前到达，此时需忽略

• 悬挂：可能出现回滚后，再收到正向操作，此时需忽略

• 幂等：可能出现重复请求，需要允许操作重试，不影响结果

通俗一点说，转账这类的分布式事务，可能会出现服务先收到撤销转账的请求，然后再收到转账的请求。下面是一个时序图，很好的演示了异常的情况：

其中：

• 5 Cancel在Try之前被调用，是空补偿

• 7 Cancel和5的重复，是重复请求

• 8 Try在Cancel之后执行，是悬挂操作

目前没有看到哪个项目在这方面有成熟好用的解决方案，包括Seata，都要求业务层面直接处理这类问题。业务直接处理这类问题，面临大量逻辑判断，复杂易出错，需要花费大量的时间进行调试测试，而且由于悬挂这样的问题难以模拟，可能要线上跑一段时间后才会出现。业务对于这样的情况只能表示很无奈，很头疼。

DTM首创了子事务屏障，系统性的解决了上述的异常问题，效果示意图如下：

所有这些请求，到了子事务屏障后：不正常的请求，会被过滤；正常请求，通过屏障。开发者使用子事务屏障之后，前面所说的各种异常全部被妥善处理，业务开发人员只需要关注实际的业务逻辑，负担大大降低。
子事务屏障提供了方法BranchBarrier.Call，方法的原型为：

func (bb *BranchBarrier) Call(db *sql.DB, busiCall BusiFunc) error

业务开发人员，在busiCall里面编写自己的相关逻辑，调用BranchBarrier.Call。BranchBarrier.Call保证，在空回滚、悬挂等场景下，busiCall不会被调用；在业务被重复调用时，有幂等控制，保证只被提交一次。

子事务屏障会管理TCC、SAGA、事务消息等，也可以扩展到其他领域

有了子事务屏障的帮助，分布式事务的使用门槛大大降低，原先需要架构师才能胜任的工作，现在只需要普通开发人员就可以完成。未来DTM有可能成为推进微服务化的核心组件。

说完了所有事务模式共同的问题和解决方案后，我们下面看一下DTM对各个事务模式的支持：

这两种事务模式保证消息至少被成功消费一次（或者说相关服务的执行最少成功一次），保证多个微服务被原子执行，它适合不需要回滚的业务场景。例如：

• 点击按钮，领取优惠券+会员，领优惠券+会员不需要回滚，这种情况适合可靠消息

• 注册成功后，领取优惠券+会员，这种情况适合事务消息。

第二种情况和第一种对比，差别主要是只有注册成功，才领取，如果注册失败，不可以领取，这种情况适合事务消息

DTM的支持如下：

如果是事务消息，那么在本地事务提交之前调用Prepare，提交之后调用Commit。如果没有本地事务，其实就是可靠消息，忽略Prepare调用即可。

XA是标准二阶段提交，一阶段Prepare，二阶段Commit/Rollback。一阶段的所有Prepare成功，则Commit，否则Rollback。从修改数据开始，到Commit/Rollback结束，锁定数据长，并发度较低。

这种事务模式适合并发不高的订单转账等各项业务。

DTM的支持如下：

TCC的每个子事务有两个阶段：一阶段Try；二阶段Confirm/Cancel；Try中进行资源预留，例如冻结资金；一阶段如果全部成功，则Confirm，例如进行余额扣减，解冻资金；一阶段如果有一个子事务出现失败，则Cancel，例如解冻资金；

TCC模式不长期锁数据，并发高。常用于支付、订单类业务的拆分。

DTM的支持如下：

SAGA每个子事务有正向分支和补偿分支，它在正向分支中直接修改数据，出错则补偿所有修改过的数据。

SAGA比TCC少一个分支，一致性比TCC弱。适用于积分换礼品等不涉及资金业务；也适用于对接较多第三方的长事务。

DTM的支持如下：

AT为SEATA和部分其他的框架提供的事务模式，各方面特性类似于XA，性能比XA高，但低于其他模式。

这种模式的使用需要小心避免脏回滚，假如T1修改Row1，然后Row1被T2直接修改，接下来T1回滚，此时出现脏回滚，需要手动处理。Seata给出避免这种脏回滚的办法是，所有要修改Row1的访问，都必须使用Seata中的Transaction注解，这个要求在多团队协作，新旧系统兼容上难以保证。

因为脏回滚以及类似XA的特性，DTM支持了XA，并未支持AT模式，预计近期也不会支持。

DTM还有一些其他典型的适用场景，例如：多个应用间的对账系统、发布文章后更新各类统计信息等

DTM对单服务多数据源的支持非常优雅，只需要将每个数据源的修改用一个子事务屏障包装起来即可。如图所示：

已完成的特性

• 从生产系统提炼而来，已接入三家

• 中英文文档

• HTTP/gRPC支持

• 测试覆盖95%以上

• Promethues监控

• 完善的CI/CD

• 支持的语言包括Go、Python、PHP、Node、Java、C#等

• 完整的线上部署文档，含直接部署、Docker、K8S

行业影响

干货推广文《分布式事务最经典的其中解决方案》被大量的自媒体自发转载（不是主动投稿），大约有几十个公众号，多个自媒体平台（包括脉脉，微博等）。该文章两个月时间就排到谷歌搜索“分布式事务"结果第二。

DTM在Github上面的star增长迅速，受到了很大的关注

下图是DTM和Seata在重要特性上的对比：

可以看到DTM在各项重要特性上不输于，甚至优于第一名，未来的发展潜力很大，他的目标是成为云原生架构的核心组件

我们的项目地址是：https://github.com/yedf/dtm

文档是：https://dtm.pub