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

yedf · · 1234 次点击 · · 开始浏览

这是一个创建于的文章，其中的信息可能已经有所发展或是发生改变。

之前我有一篇文章，介绍了[分布式事务最经典的七种解决方案](https://segmentfault.com/a/1190000040321750)，这里我们从业务需求的角度，根据不同的业务场景，给出最适合的解决方案。当我们采用服务/微服务架构，对业务进行分拆解耦后，原先在一个单体内，使用本地数据库保证ACID的数据修改，因为跨了多个服务，就不再适用了，就需要引入分布式事务来保证新的原子性。由于分布式事务方案，无法做到ACID的保证，没有一种完美的方案，能够解决掉所有业务问题。因此在实际应用中，会根据业务的不同特性，选择最适合的分布式事务方案。 ## 业务分类下面是常见的几种业务分类，以及适合的解决方案介绍 ### 多个微服务组合成原子操作有一类业务场景是需要把多个微服务组合成原子操作：假设您有一个活动业务，用户点击领取按钮后，会领取一张优惠券，和一个月的会员。优惠券和会员分别属于不同的服务，需要都被调用，不希望出现一个服务调用成功，另一个因为网络或者其他故障导致没有成功。这个场景适合可靠消息方案，可以使用rocketmq、rabbitmq等，发送给消息队列的消息，一定要等收到队列接收确认，再返回应用程序。 ### 本地事务+多个微服务组合为原子操作有一类业务与前一种业务情况类似，但有一些差别：假设您有一个新用户注册成功后，领取一张优惠券和一个月会员。如果注册不成功，不希望调用领取；只有注册成功才领取。这种情况，适合本地消息方案，或者事务消息方案。这两种方案都能保证本地事务和消息的原子性。 ### 订单类对一致性要求较高的业务订单交易类业务，涉及资金、库存、优惠券等多个服务，完成一个订单，需要相关的各个服务组合成一个整体可回滚的事务。如果订单进行过程中金额先扣减，后续因为库存不够只能退款，把金额补偿加回来。在这个过程中用户看到了金额减少，又金额变回来，体验很差。一般这类业务都会先冻结资金，如果订单能成功，再扣减资金；不能成功，则解冻资金，这样能够让资金信息对用户更友好。这种场景适合TCC方案，可以在TCC的Try中冻结资金，Confirm中扣减资金，Cancel中解冻资金 ### 一致性要求不高的可回滚业务如果业务对事务中的一致性要求不高，允许用户看到中间状态，例如用户的积分数据等。这种模式适用SAGA模式，SAGA对比与TCC，只有正向操作和逆向补偿操作，会更加简单 ### 耗时较久的全局事务耗时较旧的全局事务适合可靠消息和SAGA，不适合TCC和XA，因为大多数的XA和TCC实现，为了方便用户灵活的定义事务，通常把事务的进度保存在应用程序，一旦事务进行中应用程序崩溃，无法往前进行下一步，只能回滚。 SAGA和可靠消息，把事务进度保存在数据库或消息系统中，任何一个组件临时的失败，如果重试成功，能够让事务继续。其中如果整个事务是需要回滚的，那么适合SAGA，不需要回滚的，适合可靠消息 ### 并发度较低的业务如果业务并发度不高，事务又需要支持回滚，那么适合XA方案。XA方案，除了并发不高，也还需要本地数据库能支持XA接口。这个方案的优点是，使用上较简单，比较接近本地事务 ## 实践上面介绍完各种业务类型，以及适合的事务方案，通常情况下，您需要选择合适的开源项目来实施技术方案。在分布式事务领域，应用比较广泛的有[DTM](https://github.com/yedf/dtm)、[SEATA](https://github.com/seata/seata)、[RocketMq](https://github.com/apache/rocketmq) 其中seata用Java开发，支持Java语言的接入，支持TCC、SAGA、XA、AT(类似XA，性能更高，但有脏回滚) RocketMq用Java开发，支持各类语言的接入，仅支持可靠消息、事务消息模式这里重点介绍DTM，它用GO开发，基于HTTP协议，支持多种语言接入，支持TCC、SAGA、XA、可靠消息、事务消息模式。 ### 可靠消息例子我们拿第一个最简单的业务场景“多个微服务组合成原子操作”来看DTM是如何解决问题的假设领取优惠券和会员的处理函数分别是：ObtainCoupon和ObtainVip，那么处理领取逻辑的处理函数（用Go做示例）只用这么写： ``` 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的解决方式，代码大致如下： ``` go 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](https://github.com/yedf/dtm) ，里面有很多的分布式事务例子 ### 多种模式并存如果您的实际项目，涉及分布式事务的场景较多，一种事务模式，可能并不满足需求，可能需要使用SEATA+Rocketmq，接入以及维护成本较高。而DTM提供了一站式的解决方案，对常见的各种业务场景都提供了便捷的支持。 ## 小结 dtm作为一个新兴起的分布式事务框架，提供了强大的功能，以及简单易用的接口，极大的简化了微服务架构下，分布式事务的使用。下面是dtm与seata的主要特性对比： | 特性| DTM | SEATA |备注| |:-----:|:----:|:----:|:----:| | 支持语言 |Golang、python、php、c# 及其他|Java|dtm可轻松接入一门新语言| |异常处理| [子事务屏障自动处理](https://zhuanlan.zhihu.com/p/388444465)|手动处理 |dtm解决了幂等、悬挂、空补偿| | TCC事务| ✓|✓|| | XA事务|✓|✓|| |AT事务|✗|✓|AT与XA类似，性能更好，但有脏回滚| | SAGA事务 |简单模式 |状态机复杂模式 |dtm的状态机模式在规划中| |事务消息|✓|✗|dtm提供类似rocketmq的事务消息| |通信协议|HTTP|dubbo等协议，无HTTP|dtm后续将支持grpc类协议| |star数量|<img src="https://img.shields.io/github/stars/yedf/dtm.svg?style=social" alt="github stars"/>|<img src="https://img.shields.io/github/stars/seata/seata.svg?style=social" alt="github stars"/>|dtm从20210604发布0.1，发展快| dtm的项目地址为[https://github.com/yedf/dtm](https://github.com/yedf/dtm) ，欢迎大家访问、试用、点亮star

有疑问加站长微信联系（非本文作者））