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

之前我有一篇文章，介绍了分布式事务最经典的七种解决方案，这里我们从业务需求的角度，根据不同的业务场景，给出最适合的解决方案。
当我们采用服务/微服务架构，对业务进行分拆解耦后，原先在一个单体内，使用本地数据库保证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方案，那么您需要做一下几个步骤：

发送"领取"的消息给队列
消费"领取”的消息，然后调用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	dubbo等协议，无HTTP	dtm后续将支持grpc类协议