如何选择分布式事务形态(TCC,SAGA,2PC,补偿,基于消息最终一致性等等) - YOYO&# - 博客园

标签: | 发表时间:2019-08-03 15:42 | 作者:
出处:https://www.cnblogs.com

各种形态的分布式事务

分布式事务有多种主流形态,包括:

  • 基于消息实现的分布式事务
  • 基于补偿实现的分布式事务(gts/seata自动补偿的形式)
  • 基于TCC实现的分布式事务
  • 基于SAGA实现的分布式事务
  • 基于2PC实现的分布式事务

之所以有这么多形态,是 因为任何事情都没有银弹,只有最合适当前场景的解决方案

这些形态的原理已经在很多文章中进行了剖析,用“分布式事务”关键字就能搜到对应的文章,本文不再赘述这些形态的原理,并将重点放在如何根据业务选择对应的分布式事务形态上。

何时选择单机事务?

这个相信大家都很清楚,在条件允许的情况下,我们应该尽可能地使用单机事务,因为单机事务里,无需额外协调其他数据源,减少了网络交互时间消耗以及协调时所需的存储IO消耗,在修改等量业务数据的情况下,单机事务将会有更高的性能。

但单机数据库由于 业务逻辑解耦等因素进行了数据库垂直拆分、或者由于单机数据库性能压力等因素进行了数据库水平拆分之后,数据分布于多个数据库,这时若需要对多个数据库的数据进行协调变更,则需要引入分布式事务。

分布式事务的模式有很多种,那究竟要怎么选择适合业务的模式呢?以下我们将从使用场景、性能、开发成本这几个方面进行分析。

何时选择基于消息实现的事务?

基于消息实现的事务适用于分布式事务的提交或回滚只取决于事务发起方的业务需求,其他数据源的数据变更跟随发起方进行的业务场景。

举个例子,假设存在业务规则:某笔订单成功后,为用户加一定的积分。

在这条规则里,管理订单数据源的服务为事务发起方,管理积分数据源的服务为事务跟随者。

从这个过程可以看到,基于消息队列实现的事务存在以下操作:

  • 订单服务创建订单,提交本地事务
  • 订单服务发布一条消息
  • 积分服务收到消息后加积分

我们可以看到它的整体流程是比较简单的,同时业务开发工作量也不大:

  • 编写订单服务里订单创建的逻辑
  • 编写积分服务里增加积分的逻辑

可以看到该事务形态过程简单,性能消耗小,发起方与跟随方之间的流量峰谷可以使用队列填平,同时业务开发工作量也基本与单机事务没有差别,都不需要编写反向的业务逻辑过程。因此基于消息队列实现的事务是我们除了单机事务外最优先考虑使用的形态。

何时选择利用补偿实现的事务?

但是基于消息实现的事务并不能解决所有的业务场景,例如以下场景:某笔订单完成时,同时扣掉用户的现金。

这里事务发起方是管理订单库的服务,但对整个事务是否提交并不能只由订单服务决定,因为还要确保用户有足够的钱,才能完成这笔交易,而这个信息在管理现金的服务里。这里我们可以引入基于补偿实现的事务,其流程如下:

  • 创建订单数据,但暂不提交本地事务
  • 订单服务发送远程调用到现金服务,以扣除对应的金额
  • 上述步骤成功后提交订单库的事务

以上这个是正常成功的流程,异常流程需要回滚的话,将额外发送远程调用到现金服务以加上之前扣掉的金额。

以上流程比基于消息队列实现的事务的流程要复杂,同时开发的工作量也更多:

  • 编写订单服务里创建订单的逻辑
  • 编写现金服务里扣钱的逻辑
  • 编写现金服务里补偿返还的逻辑

可以看到,该事务流程相对于基于消息实现的分布式事务更为复杂,需要额外开发相关的业务回滚方法,也失去了服务间流量削峰填谷的功能。但其仅仅只比基于消息的事务复杂多一点,若不能使用基于消息队列的最终一致性事务,那么可以优先考虑使用基于补偿的事务形态。

阿里GTS/fescar本质上也是这补偿的编程模型,只不过补偿代码自动生成,无需业务干预,同时接管应用数据源,禁止业务修改处于全局事务状态中的记录。因此,其关于读场景的适用性,可参考补偿。但其在写的适用场景由于引入了全局事务时的写锁,其写适用性介于 TCC以及补偿之间 。

何时选择利用TCC实现的事务

然而基于补偿的事务形态也并非能实现所有的需求,如以下场景:某笔订单完成时,同时扣掉用户的现金,但交易未完成,也未被取消时,不能让客户看到钱变少了。

这时我们可以引入TCC,其流程如下:

  • 订单服务创建订单
  • 订单服务发送远程调用到现金服务,冻结客户的现金
  • 提交订单服务数据
  • 订单服务发送远程调用到现金服务,扣除客户冻结的现金

以上是正常完成的流程,若为异常流程,则需要发送远程调用请求到现金服务,撤销冻结的金额。

以上流程比基于补偿实现的事务的流程要复杂,同时开发的工作量也更多:

  • 订单服务编写创建订单的逻辑
  • 现金服务编写冻结现金的逻辑
  • 现金服务编写扣除现金的逻辑
  • 现金服务编写解冻现金的逻辑

TCC实际上是最为复杂的一种情况,其能处理所有的业务场景,但无论出于性能上的考虑,还是开发复杂度上的考虑,都应该尽量避免该类事务。

何时选择利用SAGA实现的事务?

SAGA可以看做一个异步的、利用队列实现的补偿事务。

其适用于无需马上返回业务发起方最终状态的场景,例如:你的请求已提交,请稍后查询或留意通知 之类。

将上述补偿事务的场景用SAGA改写,其流程如下:

  • 订单服务创建最终状态未知的订单记录,并提交事务
  • 现金服务扣除所需的金额,并提交事务
  • 订单服务更新订单状态为成功,并提交事务

以上为成功的流程,若现金服务扣除金额失败,那么,最后一步订单服务将会更新订单状态为失败。

其业务编码工作量比补偿事务多一点,包括以下内容:

  • 订单服务创建初始订单的逻辑
  • 订单服务确认订单成功的逻辑
  • 订单服务确认订单失败的逻辑
  • 现金服务扣除现金的逻辑
  • 现金服务补偿返回现金的逻辑

但其相对于补偿事务形态有性能上的优势,所有的本地子事务执行过程中,都无需等待其调用的子事务执行,减少了加锁的时间,这在事务流程较多较长的业务中性能优势更为明显。同时,其利用队列进行进行通讯,具有削峰填谷的作用。

因此该形式适用于不需要同步返回发起方执行最终结果、可以进行补偿、对性能要求较高、不介意额外编码的业务场景。

但当然SAGA也可以进行稍微改造,变成与TCC类似、可以进行资源预留的形态。

2PC事务

其适用于参与者较少,单个本地事务执行时间较少,并且参与者自身可用性很高的场景,否则,其很可能导致性能下降严重。

并非一种事务形态就能打遍天下

通过分析我们可以发现,并不存在一种事务形态能解决所有的问题,我们需要根据特定的业务场景选择合适的事务形态。甚至于有时需要混合多种事务形态才能更好的完成目标,如 上面提到的 订单、积分、钱包混合的场景:订单的成功与否需要依赖于钱包的余额,但不依赖于积分的多少,因此可以混合基于消息的事务形态以加积分 及 基于补偿的事务形态以确保扣钱成功,从而得到一个性能更好,编码量更少的形态。

然而目前很多框架都专注于某单一方面的事务形态,如TCC单独一个框架,可靠消息单独一个框架,SAGA单独一个框架,他们各自独立,容易导致以下问题:

  • 由于前期只采用了其中一种类型事务的框架,因为工具目前只有锤子,引入其他工具又涉及测试、阅读代码等过程,因此把所有问题都看做钉子,导致性能偏低或者实现不够优雅
  • 由于不同框架管理事务的形态可能不一致,导致不能很好的协调工作,如某一个TCC框架和另一个基于消息的事务框架无法很好融合。

解决方案

为了解决上面提到的问题,EasyTransaction这个基于Spring的分布式事务框架,实现了上述除2PC以外的所有事务形态,并提供了统一的使用接口,完美地解决了以上的问题。其主要特性如下:

  • 一个框架包含多种事务形态,一个框架搞定所有类型的事务
  • 多种事务形态可混合使用
  • 高性能,若不启用框架的幂等功能,对业务数据库的额外消耗仅为写入25字节的一行
  • 可选的框架幂等实现(包括调用次序错乱处理),大幅减轻业务开发工作量
  • 业务代码可实现完全无入侵
  • 支持嵌套事务
  • 无需额外部署协调者,不同APP的服务协调自身发起的事务
  • 分布式事务ID可关联业务ID,业务类型,APPID,便于监控各个业务的分布式事务执行情况

若各位对ET兴趣,可以到 https://github.com/QNJR-GROUP/EasyTransaction查看详细介绍及示例,本文不再深入介绍

总结

不同业务场景应按需引入不同的事务形态,在条件允许的情况下,个人建议按照如下次序选择对应的事务形态:

      单机事务》基于消息的事务》基于补偿的事务》TCC事务

因SAGA事务的形态需要配合较为明显的前端业务交互变更,个人建议在单一事务执行过程较长、存在较多子事务,并且无法使用基于消息的事务形态时使用。

相关 [选择 分布 tcc] 推荐:

如何选择分布式事务形态(TCC,SAGA,2PC,补偿,基于消息最终一致性等等) - YOYO&# - 博客园

- -
分布式事务有多种主流形态,包括:. 基于补偿实现的分布式事务(gts/seata自动补偿的形式). 基于TCC实现的分布式事务. 基于SAGA实现的分布式事务. 基于2PC实现的分布式事务. 因为任何事情都没有银弹,只有最合适当前场景的解决方案. 这些形态的原理已经在很多文章中进行了剖析,用“分布式事务”关键字就能搜到对应的文章,本文不再赘述这些形态的原理,并将重点放在如何根据业务选择对应的分布式事务形态上.

分布式事务中间件 TCC-Transaction 源码分析 —— 项目实战

- - IT瘾-geek
摘要: 原创出处 http://www.iocoder.cn/TCC-Transaction/http-sample/「芋道源码」欢迎转载,保留摘要,谢谢. 本文主要基于 TCC-Transaction 1.2.3.3 正式版. 4.2 Confirm / Cancel 阶段. 微信公众号:【芋道源码】有福利:.

分布式事务的典型处理方式:2PC、TCC、异步确保和最大努力型

- - 研发管理 - ITeye博客
柔性事务满足BASE理论(基本可用,最终一致). 本文主要围绕分布式事务当中的柔性事务的处理方式进行讨论. 由于支付宝整个架构是SOA架构,因此传统单机环境下数据库的ACID事务满足了分布式环境下的业务需要,以上几种事务类似就是针对分布式环境下业务需要设定的. 两阶段型:就是分布式事务两阶段提交,对应技术上的XA、JTA/JTS.

终于有人把“TCC分布式事务”实现原理讲明白了! - JaJian - 博客园

- -
之前网上看到很多写分布式事务的文章,不过大多都是将分布式事务各种技术方案简单介绍一下. 很多朋友看了还是不知道分布式事务到底怎么回事,在项目里到底如何使用. 所以这篇文章,就用大白话+手工绘图,并结合一个电商系统的案例实践,来给大家讲清楚到底什么是 TCC 分布式事务. 首先说一下,这里可能会牵扯到一些 Spring Cloud 的原理,如果有不太清楚的同学,可以参考之前的文章:.

TCC两阶段补偿型

- - 互联网 - ITeye博客
TCC方案是可能是目前最火的一种柔性事务方案了. 关于TCC(Try-Confirm-Cancel)的概念,最早是由Pat Helland于2007年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出. 在该论文中,TCC还是以Tentative-Confirmation-Cancellation命名.

[探讨]分布式文件系统的应用及选择

- - CSDN博客推荐文章
当下,互联网行业发展非常迅猛,分布式文件系统在其中的应用也非常普遍. 一些朋友问起一些相关问题,如:. 搜索引擎类的那些页面文本文件存储,用什么DFS比较好. 海量小图片类的,如taobao里头,好多商家图片,用什么存储. 视频类的,如优酷,用什么DFS. 它只需要能把那些文本文件分块分散到各个节点上进行顺序存储就行了.

分布式服务框架选型:面对 Dubbo,阿里巴巴为什么选择了 HSF?

- - IT瘾-tuicool
阿里巴巴集团内部使用的分布式服务框架 HSF(High Speed Framework,也有人戏称“好舒服”)已经被很多技术爱好者所熟知,目前已经支撑着近 2000 多个应用的运行. 其对应早期的开源项目 Dubbo(因为某些原因,Dubbo 项目在 2012 年年底,阿里巴巴就停止了对此开源项目的更新),则更是在互联网领域有着非常高的知名度和广泛的使用.

转载 选择

- bravusliu - caowumao的博客

CSS4 选择器

- iVane - 幸福收藏夹
CSS3 还没完全用上,CSS4 已经提上日程. 官方发布了 update to the working Selectors Level 4 spec,对选择器做了一些升级. 前端最大的优点就是技术更新快,可以经常学到新东西;最大的缺点也是技术更新快,要跟上潮流还真不是那么简单. 不过,这次更新有像“父选择器”这样让人兴奋的内容,让我们先睹为快,了解一下吧:.

JQuery 选择器

- - CSDN博客Web前端推荐文章
}

点击我

.    像上面这样把JavaSript代码和HTML代码混杂在一起的做法同样也非常不妥,因为它并没有将网页内容和行为分离,所以才有JQuery选择器的学习.

点击我

. //给class为demo的元素添加行为.