如何选择最适合你的分布式事务方案

[dongfuye1]

之前我有一篇文章，介绍了分布式事务最经典的七种解决方案，这里我们从业务需求的角度，根据不同的业务场景，给出最适合的解决方案。

当我们采用服务 /微服务架构，对业务进行分拆解耦后，原先在一个单体内，使用本地数据库保证 ACID 的数据修改，因为跨了多个服务，就不再适用了，就需要引入分布式事务来保证新的原子性。

由于分布式事务方案，无法做到 ACID 的保证，没有一种完美的方案，能够解决掉所有业务问题。因此在实际应用中，会根据业务的不同特性，选择最适合的分布式事务方案。

业务分类

下面是常见的几种业务分类，以及适合的解决方案介绍

多个微服务组合成原子操作

有一类业务场景是需要把多个微服务组合成原子操作：假设您有一个活动业务，用户点击领取按钮后，会领取一张优惠券，和一个月的会员。优惠券和会员分别属于不同的服务，需要都被调用，不希望出现一个服务调用成功，另一个因为网络或者其他故障导致没有成功。

这个场景适合可靠消息方案，可以使用 rocketmq 、rabbitmq 等，发送给消息队列的消息，一定要等收到队列接收确认，再返回应用程序。

本地事务+多个微服务组合为原子操作

有一类业务与前一种业务情况类似，但有一些差别：假设您有一个新用户注册成功后，领取一张优惠券和一个月会员。如果注册不成功，不希望调用领取；只有注册成功才领取。

这种情况，适合本地消息方案，或者事务消息方案。这两种方案都能保证本地事务和消息的原子性。

订单类对一致性要求较高的业务

订单交易类业务，涉及资金、库存、优惠券等多个服务，完成一个订单，需要相关的各个服务组合成一个整体可回滚的事务。如果订单进行过程中金额先扣减，后续因为库存不够只能退款，把金额补偿加回来。在这个过程中用户看到了金额减少，又金额变回来，体验很差。一般这类业务都会先冻结资金，如果订单能成功，再扣减资金；不能成功，则解冻资金，这样能够让资金信息对用户更友好。

这种场景适合 TCC 方案，可以在 TCC 的 Try 中冻结资金，Confirm 中扣减资金，Cancel 中解冻资金

一致性要求不高的可回滚业务

如果业务对事务中的一致性要求不高，允许用户看到中间状态，例如用户的积分数据等。

这种模式适用 SAGA 模式，SAGA 对比与 TCC，只有正向操作和逆向补偿操作，会更加简单

耗时较久的全局事务

耗时较旧的全局事务适合可靠消息和 SAGA，不适合 TCC 和 XA，因为大多数的 XA 和 TCC 实现，为了方便用户灵活的定义事务，通常把事务的进度保存在应用程序，一旦事务进行中应用程序崩溃，无法往前进行下一步，只能回滚。

SAGA 和可靠消息，把事务进度保存在数据库或消息系统中，任何一个组件临时的失败，如果重试成功，能够让事务继续。

其中如果整个事务是需要回滚的，那么适合 SAGA，不需要回滚的，适合可靠消息

并发度较低的业务

如果业务并发度不高，事务又需要支持回滚，那么适合 XA 方案。XA 方案，除了并发不高，也还需要本地数据库能支持 XA 接口。这个方案的优点是，使用上较简单，比较接近本地事务

实践

上面介绍完各种业务类型，以及适合的事务方案，通常情况下，您需要选择合适的开源项目来实施技术方案。在分布式事务领域，应用比较广泛的有DTM、SEATA、RocketMq

其中 seata 用 Java 开发，支持 Java 语言的接入，支持 TCC 、SAGA 、XA 、AT(类似 XA，性能更高，但有脏回滚)

RocketMq 用 Java 开发，支持各类语言的接入，仅支持可靠消息、事务消息模式

这里重点介绍 DTM，它用 GO 开发，基于 HTTP 协议，支持多种语言接入，支持 TCC 、SAGA 、XA 、可靠消息、事务消息模式。

可靠消息例子

我们拿第一个最简单的业务场景“多个微服务组合成原子操作”来看 DTM 是如何解决问题的

假设领取优惠券和会员的处理函数分别是：ObtainCoupon 和 ObtainVip，那么处理领取逻辑的处理函数（用 Go 做示例）只用这么写：

	msg := dtmcli.NewMsg(DtmServer,gid).
		Add(Busi+"/ObtainCoupon", req).
		Add(Busi+"/ObtainVip", req)
	err := msg.Submit()

dtm 收到客户端提交的消息后，会保证 ObtainCoupon 和 ObtainVip 被调用，如果任何一个出现失败，会不断重试，直到成功。

假如您采用的是 rocketmq 方案，那么您需要做以下几个步骤：

1. 发送"领取"的消息给队列
2. 消费"领取”的消息，然后调用 ObtainCoupon 和 ObtainVip，然后确认消息已成功消费

对比 dtm 和 rocketmq 的方案，dtm 仅需要简单的几行代码即可（ dtm 也提供 http 的接口，可以用任何语言直接发 http 请求），清晰简单。而 rocketmq 方案，涉及较多队列的知识，要做的工作较多

SAGA 例子

假设我们有一个积分兑换课程的业务，一方面积分不属于非常核心的资产，中间状态允许用户看到，另一方面兑换课程可能出现课程已拥有权限，则需要回滚，因此该业务属于“一致性要求不高的可回滚业务“。

我们采用 SAGA 方案来解决这个问题，来看看 DTM 的解决方式，代码大致如下：

	saga := dtmcli.NewSaga(DtmServer, gid).
		Add(Busi+"/AdjustIntegral", Busi+"/AdjustIntegralRevert", req).
		Add(Busi+"/AuthCourse", Busi+"/AuthCourseRevert", req)
	saga.WaitResult = true
	err := saga.Submit()

dtm 收到客户端提交的 saga 事务之后，会按顺序调用 AdjustIntegral，AuthCourse，如果函数返回错误要求回滚，dtm 则会调用 AuthCourseRevert，AdjustIntegralRevert 进行回滚。

如果您没有采用 dtm 方案，那么您可以采用 SEATA 的 SAGA，涉及比较多的背景知识，接入较复杂。

更多的例子

您可以访问https://github.com/yedf/dtm ，里面有很多的分布式事务例子

多种模式并存

如果您的实际项目，涉及分布式事务的场景较多，一种事务模式，可能并不满足需求，可能需要使用 SEATA+Rocketmq，接入以及维护成本较高。而 DTM 提供了一站式的解决方案，对常见的各种业务场景都提供了便捷的支持。

小结

dtm 作为一个新兴起的分布式事务框架，提供了强大的功能，以及简单易用的接口，极大的简化了微服务架构下，分布式事务的使用。

下面是 dtm 与 seata 的主要特性对比：

特性	DTM	SEATA	备注
支持语言	Golang 、python 、php 、c# 及其他	Java	dtm 可轻松接入一门新语言
异常处理	子事务屏障自动处理	手动处理	dtm 解决了幂等、悬挂、空补偿
TCC 事务	✓	✓
XA 事务	✓	✓
AT 事务	✗	✓	AT 与 XA 类似，性能更好，但有脏回滚
SAGA 事务	简单模式	状态机复杂模式	dtm 的状态机模式在规划中
事务消息	✓	✗	dtm 提供类似 rocketmq 的事务消息
通信协议	HTTP 、GRPC	dubbo 等协议，无 HTTP	dtm 对云原生友好

dtm 的项目地址为https://github.com/yedf/dtm ，欢迎大家访问、试用、点亮 star

[masterclock]

dtm 看着非常不错
我们目前基于 temporal https://docs.temporal.io/ 实现简单的部分 saga，用于几个服务间的事务协作，“几”小于 10
这种情况下
有没有必要引入 dtm
有没有可能引入 dtm
如果，有，呃，能来个例子吗？🤪

[dongfuye1]

@masterclock 我大概看了一下 temporal 的例子，他很像一个把状态机写在客户端的 saga 事务管理器，或者叫 workflow 。
我初步的感觉是，dtm 的简单 saga 能够满足绝大部分需求，并且比 temporal 更加简单易用。
例子在文中，自取哈

[S2Line]

有性能测试数据吗？和不做分布式事务以及其他主流分布式事务解决方案(seata 、servicecomb 之类的)的对比。

[dongfuye1]

@S2Line 没收到 seata 、servicecomb-pack 的测试报告，没办法比较。从架构原理上，dtm 对每个事务分支，会有 1~3 次数据库读写，其他都是网络开销，额外性能消耗不大。

[S2Line]

@dongfuye1 想请问下你们为什么考虑使用 mysql 作为存放呢？有频繁的数据库读写，且字段内容比较单一，为什么不考虑使用 KV 库？还有请问数据库清理策略是怎样的呢？ mysql 的可用性怎么保证的？

[dongfuye1]

@S2Line 您的问题比较深入。dtm 主要目标是解决分布式事务问题，大多数接入 dtm 的公司，微服务的数据访问用的是 mysql，因此 dtm 很自然采用 mysql 存储，对各家公司的运维成本最低，只要公司的 mysql 是高可用的，那么 dtm 就是高可用的。
如果采用其他 KV 库，那么部署运维，高可用等，都有不少的学习维护成本。

dtm 目前没做数据库清理，但是相关的查询索引都是 OK 的。如果贵公司的数据量很大，由 DBA 弄个简单的定时脚本进行清理即可。

[akira]

看到最后 果然是广告啊。。。欣慰

[wangxin13g]

最好的分布式事务框架果然就是不用框架

[fkdog]

谢谢,即使目前没有用到 dtm 的需求, 也学到不少分布式事务相关的知识.
这样帖子即使是推广也是诚意满满.