【分布式事务】微服务架构下的分布式事务问题

一、基本概念

ACID理论：关系型数据库的事务满足 ACID 的特性，具有 ACID 特性的数据库支持数据的强一致性，保证了数据本身不会出现不一致。适用于传统的单体架构。
CAP理论：在分布式系统下，包含三个要素：Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性），并且三者不可兼得。分布式系统要求保证分区容错性，只能在数据强一致性（C）和可用性（A）之间做平衡，即选择CP或者AP。比如Zookeeper为CP系统保证强一致性牺牲一定的可用性；Eureka为AP系统保证较高可用性牺牲一定的一致性。另外，CAP理论中是忽略网络延迟，也就是当事务提交时，从节点A复制到节点B，但是在现实中这个是明显不可能的，所以总会有一定的时间是不一致。所以CAP一般适用于局域网系统的理论基础。
BASE理论：解决 CAP 理论中分布式系统的可用性和一致性不可兼得的问题，提出最终一致性。即，最终数据是一致的就可以了，而不是实时保持强一致。例如，支付成功，订单也成功，但增加积分失败，此时，不应回滚支付和订单，而应通过一些补偿方法来让积分得以正确地增加。

二、解决方案

方案	解决思路	适用场景	说明
本地事务	基于数据库的ACID理论基于undo、redo日志记录 undo日志实现回滚、redo日志实现commit场景异常的恢复	传统单体架构分布式事务要求不高的场景	分布式系统场景出现问题怎么办？日志记录--监控告警–人工干预修复问题溯源，例如：维修工单可以创建，但是维修费用调用失败导致整个事务回滚可能维修费用自身问题，如性能压力过大导致请求时，触发调用失败回滚可能维修费用操作依据成功了，但是返回
两阶段提交	基于XA协议，依赖TM、RM的交互，依赖数据库的能力 TM存在单点故障，锁资源占用时间较长	面向多数据源或者分布式数据库设计（XA本质是TM与RM之间的规范）适用于多数据源的架构 Mycat也实现了XA协议，一些公司的分布式事务使用该方案，但是应用层非微服务架构适用于并发量不大，处理时间较短的核心交易业务场景	XA协议：
三阶段提交	基于TCC协议在数据库外部实现事务机制达到最终一致性牺牲了应用的灵活性，需要提供Try、Confirm、Cancel的具体实现，且需要小心保证幂等操作	跨应用，但需要实现TCC接口，对已有系统侵入较大，适用于新系统不强依赖数据库特性，TCC是一个通用的模型参考实现：https://github.com/liuyangming/ByteTCC/	TCC协议：
可靠消息模式	大事务转变为小事务，小事物之间的不一致通过额外的轮训任务进行补偿该思路最初由Ebay提出：https ://queue.acm.org/detail.cfm?id=1394128 可分为基于本地事件、基于外部事件两种模式业务逻辑需要保证幂等性	适用于核心模块的改造，或者完全基于消息驱动的架构，否则对已有系统入侵较大另外，如果需要回滚，超过两个实务操作的场景比较复杂，所以这种场景需要遵守最终一致性原则，失败不会滚，直到补偿成功依赖具备事务功能的消息系统或者数据库，如：RabbitMQ、Kafka、RocketMQ等	基于本地事件：基于外部事件：
可靠消息变种	不依赖消息队列通信，将消息队列的功能包装为Rest服务，屏蔽消息队列的接口将基于可靠消息模式对架构和应用入侵的缺点降低	最大努力通知型如支付宝的回调机制，可以设置指数时间重试，参考阿里实现：https://zhuanlan.zhihu.com/p/26114119
可靠消息变种		下游应用轮询如微信的轮询机制，由下游应用自己保证一致性
SAGA方案	基于工作流的思路，原理：https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf 定义顺序操作、回滚操作的流程，交给事务协调器统一管理一些应用框架实现了该方案，如CQRS框架Axonframework：https://github.com/AxonFramework/AxonFramework，又如华为servicecomb：https://github.com/apache/incubator-servicecomb-saga	应用方定义工作流，交给SAGA进行管理，虽然这种方案不火热，但是对应用入侵较小，且符合分层的设计原则，添加一个composite层单独实现需要分布式事务的流程即可	SAGA工作流：
阿里GTS	优化XA架构的路线，使用上与XA类似，业务入侵较小，添加注解 GTS参考：https://zhuanlan.zhihu.com/p/32684212 仿GTS实现：https://github.com/wxbty/meepo https://github.com/chenjy16/gts 与GTS类似的：https://github.com/codingapi/tx-lcn 看起来最成熟的开源方案	适用于阿里云方案，专线也可以接入使用，第三方系统遵循TCC的也可以接入
总结建议	如果非必要，不引入分布式事务，每个微服务保证自身的高可用，基本能够保证数据的一致性，极端的情况除外。--事实上微服务的架构BAT十年前就在使用，没有分布式事务也一样，因为基础设施、每个微服务自身可用性比较高，所以不需要引入更大的复杂性如果必要，首先保证核心业务的数据一致性，比如交易业务，可以采用消息机制、最大努力通知、轮询机制的方案，他们的本质都是记账，即使出了问题也有据可查--这部分一般借助第三方支付系统的能力即可满足如果只是较少量的业务需要分布式事务特性，可以局部使用基于可靠消息的方案，参考：https://github.com/vvsuperman/coolmq，这种方案需要注意很多细节，理论上每个环节都可能出现网络异常，都需要有相应的措施保障，比如：如果建立指数时间重试机制，下游服务接口需要保证幂等，该方案相当于业务自己负责维护一致性如果大量业务需要分布式事务，也可以引入类似DelayMq的服务做解耦，利用该服务提供回调服务将服务链串联起来（消息中包含回调的Url、参数），但是下游的服务接口需要保证幂等性--PaaS平台可以提供类似的服务，参考：https://zhuanlan.zhihu.com/p/26114119。该方案需要能够接受部分代码的重构如果大量业务需要分布式事务，可以引入类似GTS对业务入侵较小的框架，避免更新架构和代码，代码添加必要的注解即可，如：https://github.com/codingapi/tx-lcn --开源方案，建议经过测试之后谨慎上线，这个能力也可以研究下看看能不能做到PaaS平台数据一致性是一个系统工程，仅仅在事务框架层面解决是不够的，还需要配套的规范措施--如请求RequestID、链路追踪、接口幂等、日志输出规范、关键日志记录规范等，出现问题可以快速定位，这部分的数据可以让PaaS接管，提供链路服务、监控告警服务等完善基础设施，降低网络问题的影响是重要前提。对于实际调用已经成功，返回时网络异常的问题，需要补偿机制--PaaS可以提供类似DelayMq的服务完善应用的监控告警设施，如应用的API、访问次数、失败次数等监控，及时告警--PaaS可以提供应用的实时监控告警能力

三、参考资料

再有人问你分布式事务，把这篇扔给他：https://mp.weixin.qq.com/s/W7XeNKIwB-JxnyStq0xD6g
GTSDemo介绍：https://help.aliyun.com/document_detail/57267.html?spm=a2c4g.11174283.3.5.6eea735d9NoIS6
ByteTCC：https://github.com/liuyangming/ByteTCC/
GTS解密--GTS的原理、架构与特点：https://zhuanlan.zhihu.com/p/32684212
分布式事务系列：https://blog.csdn.net/qq_27384769/article/details/79305402

四、GitHub相关项目

原文地址：https://www.cnblogs.com/junneyang/p/9736746.html

时间： 2024-10-02 20:48:01

【分布式事务】微服务架构下的分布式事务问题的相关文章

微服务架构下处理分布式事务，你必须知道的事儿

根据微服务架构的鼻祖 Martin Fowler 的忠告,微服务架构中应当尽量避免分布式事务.然而,在某些领域,分布式事务如同宿命中的对手无法避免. 在工程领域,分布式事务的讨论主要聚焦于强一致性和最终一致性的解决方案. 典型方案包括: 两阶段提交(2PC, Two-phase Commit)方案. eBay 事件队列方案. TCC 补偿模式. 缓存数据最终一致性. 一致性理论分布式事务的目的是保障分库数据一致性,而跨库事务会遇到各种不可控制的问题,如个别节点永久性宕机,像单机事务一样的 AC

微服务架构下的分布式限流方案思考

1.微服务限流随着微服务的流行,服务和服务之间的稳定性变得越来越重要.缓存.降级和限流是保护微服务系统运行稳定性的三大利器.缓存的目的是提升系统访问速度和增大系统能处理的容量,而降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉,待高峰或者问题解决后再打开,而有些场景并不能用缓存和降级来解决,比如稀缺资源.数据库的写操作.频繁的复杂查询,因此需有一种手段来限制这些场景的请求量,即限流. 比如当我们设计了一个函数,准备上线,这时候这个函数会消耗一些资源,处理上限是1秒服务3000个QPS

微服务架构下分布式事务解决方案——阿里云GTS

https://blog.csdn.net/jiangyu_gts/article/details/79470240 1 微服务的发展微服务倡导将复杂的单体应用拆分为若干个功能简单.松耦合的服务,这样可以降低开发难度.增强扩展性.便于敏捷开发.当前被越来越多的开发者推崇,很多互联网行业巨头.开源社区等都开始了微服务的讨论和实践.Hailo有160个不同服务构成,NetFlix有大约600个服务.国内方面,阿里巴巴.腾讯.360.京东.58同城等很多互联网公司都进行了微服务化实践.当前微服务的开

微服务架构下分布式事务方案

1 微服务的发展微服务倡导将复杂的单体应用拆分为若干个功能简单.松耦合的服务,这样可以降低开发难度.增强扩展性.便于敏捷开发.当前被越来越多的开发者推崇,很多互联网行业巨头.开源社区等都开始了微服务的讨论和实践.Hailo有160个不同服务构成,NetFlix有大约600个服务.国内方面,阿里巴巴.腾讯.360.京东.58同城等很多互联网公司都进行了微服务化实践.当前微服务的开发框架也非常多,比较著名的有Dubbo.SpringCloud.thrift .grpc等. 2 微服务落地存在的问题

阿里微服务架构下分布式事务解决方案－GTS

虽然微服务现在如火如荼,但对其实践其实仍处于初级阶段.即使互联网巨头的实践也大多是试验层面,鲜有核心业务系统微服务化的案例.GTS是目前业界第一款,也是唯一的一款通用的解决微服务分布式事务问题的中间件,而且可以保证数据的强一致性.本文将对GTS做出深入解读. 微服务倡导将复杂的单体应用拆分为若干个功能简单的.松耦合的服务,这样可以降低开发难度.增强扩展性.便于敏捷开发.概念2012年提出迅速火遍全球,被越来越多的开发者推崇,很多互联网行业巨头.开源社区等都开始了微服务的讨论和实践.根据Netfl

三分钟彻底弄懂什么是分布式和微服务架构

一.微服务简介 1. 微服务的诞生微服务是基于分而治之的思想演化出来的.过去传统的一个大型而又全面的系统,随着互联网的发展已经很难满足市场对技术的需求,于是我们从单独架构发展到分布式架构,又从分布式架构发展到 SOA 架构,服务不断的被拆分和分解,粒度也越来越小,直到微服务架构的诞生. 微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调.互相配合,为用户提供最终价值. 每个服务运行在其独立的进程中,服务和服务间采用轻量级的通信机制互相沟通(通常是基于 HTTP

Re：从 0 开始的微服务架构--(四)如何保障微服务架构下的数据一致性--转

原文地址:http://mp.weixin.qq.com/s/eXvoJew3bjFKzLLJpS0Otg 随着微服务架构的推广,越来越多的公司采用微服务架构来构建自己的业务平台.就像前边的文章说的,微服务架构为业务开发带来了诸多好处的同时,例如单一职责.独立开发部署.功能复用和系统容错等等,也带来一些问题. 例如上手难度变大,运维变得更复杂,模块之间的依赖关系更复杂,数据一致性难以保证,等等.但是办法总是比问题多,本篇文章就来介绍一下我们是如何保障微服务架构的数据一致性的. 微服务架构的数据一

微服务架构下的数据一致性：概念及相关模式

主页:http://www.howardliu.cn/ 博客:微服务架构下的数据一致性:概念及相关模式从2014年开始,微服务逐渐进入大家的实现,被认为是下一代实现信息化的有效手段.设计到系统,其中绕不开的就是数据一致性,从本地事务,到后来的分布式事务,都能够有效的保证数据一致性.但是在微服务架构中,这两种方式都不是最好的选择. 1. 使用本地事务和分布式事务保证一致性在传统的单击应用中,最简单.最直接.最普遍的会使用一个关系型数据库,通过关系型数据库的事务保证数据的一致性.这种事务有四个基

从 0 开始的微服务架构：（四）如何保障微服务架构下的数据一致性

虽然已经红了很久,但是"微服务架构"正变得越来越重要,也将继续火下去.各个公司与技术人员都在分享微服务架构的相关知识与实践经验,但我们发现,目前网上的这些相关文章中,要么上来就是很有借鉴意义的干货,要么就是以高端的专业术语来讲述何为微服务架构.就是没有一个做到成熟地将技术传播出来,同时完美地照顾"初入微服务领域人员",从 0 开始,采用通俗易懂的语言去讲解微服务架构的系列.所以,我们邀请青柳云的苏槐与 InfoQ 一起共建微服务架构专题"Re:从 0 开始