分布式事务特性,分布式事务处理

1:分布式事物的理解:

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。就是一次大的操作由不同的小操作组成,这些小的操作分布在不同的服务节点上,分布式事务需要保证这些小操作要么全部成功,要么全部失败;本质上来说,分布式事务就是为了保证不同数据库的数据一致性。

2:分布式失误产生的原因:

a)数据库分库分表;

当数据库单表一年产生的数据超过1000W,那么就要考虑分库分表,简单的说就是原来的一个数据库变成了多个数据库,这时候,如果一个操作既访问01库,又访问02库,而且要保证数据的一致性,那么就要用到分布式事务。

b)应用SOA化;

就是业务的服务化。比如原来单机支撑了整个电商网站,现在对整个网站进行拆解,分离出了订单中心、用户中心、库存中心等,对于订单中心,有专门的数据库存储订单信息,用户中心也有专门的数据库存储用户信息,库存中心也会有专门的数据库存储库存信息,如果要同时对订单和库存进行操作,那么就会涉及到订单数据库和库存数据库,为了保证数据一致性,就需要用到分布式事务。

以上两种情况表象不同,但是本质相同,都是因为要操作的数据库变多了。

3)分布式的使用场景:

支付:一笔支付,是对买家账户进行扣款,同时对卖家账户进行加钱,这些操作必须在一个事务里执行,要么全部成功,要么全部失败,并且卖家账户对应卖家数据库,买家对应买家的数据库,对不同数据库的操作必然需要引入分布式事务。

在线下单:在电商平台下单,往往会涉及到两个动作,一个是扣库存,第二个是更新订单状态,库存和订单一般属于不同的数据库,需要使用分布式事务保证数据一致性。

4)常见的分布式事物解决方案:

a)基于XA协议的两阶段提交,

XA是一个分布式事务协议,XA中大致分为两部分:事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现,而事务管理器作为全局的调度者,负责各个本地资源的提交和回滚。

XA协议比较简单,而且一旦商业数据库实现了XA协议,使用分布式事务的成本也,XA也有致命的缺点,那就是性能不理想,往往并发量很高,XA无法满足高并发场景。

b)消息事务+最终一致性

所谓的消息事务就是基于消息中间件的两阶段提交,本质上是对消息中间件的一种特殊利用,它是将本地事务和发消息放在了一个分布式事务里,保证要么本地操作成功成功并且对外发消息成功,要么两者都失败,开源的RocketMQ就支持这一特性。

具体原理:

其执行的顺序:

b.1)A系统向消息中间件发送一条预备消息;

b.2)消息中间件保存预备消息并返回成功;

b.3)消息中间件保存预备消息并返回成功;

b.4)A发送提交消息给消息中间件;

对于这个顺序执行的分析:

步骤一出错,则整个事务失败,不会执行A的本地操作;

步骤二出错,则整个事务失败,不会执行A的本地操作;

步骤三出错,这时候需要回滚预备消息,回滚方法,:A系统实现一个消息中间件的回调接口,消息中间件会去不断执行回调接口,检查A事务执行是否执行成功,如果失败则回滚预备消息。

步骤四出错,这时候A的本地事务是成功的,回滚本地A操作的成功,不需要回滚:其实通过回调接口,消息中间件能够检查到A执行成功了,这时候其实不需要A发提交消息了,消息中间件可以自己对消息进行提交,从而完成整个消息事务。

c)高并发场景下基于消息中间件的两阶段提交的分布式事物:

比如:将一个分布式事务拆成一个消息事务(A系统的本地操作+发消息)+B系统的本地操作

B系统的操作由消息驱动,只要消息事务成功,那么A操作一定成功,消息也一定发出来了,这时候B会收到消息去执行本地操作。如果B本地操作失败,消息会重投,直到B操作成功。这样就变相地实现了A与B的分布式事务。

虽然上面的方案能够完成A和B的操作,但是A和B并不是严格一致的,而是最终一致的,当然,这种玩法也是有风险的,如果B一直执行不成功,那么一致性会被破坏,具体要不要玩,还是得看业务能够承担多少风险。

d)TCC编程模式,

TCC编程模式,也是两阶段提交的一个变种。

TCC提供了一个编程框架,将整个业务逻辑分为三块:Try、Confirm和Cancel三个操作。

以在线下单为例:Try阶段会去扣库存,Confirm阶段则是去更新订单状态,如果更新订单失败,则进入Cancel阶段,会去恢复库存,TCC就是通过代码人为实现了两阶段提交,不同的业务场景所写的代码都不一样,复杂度也不一样,因此,这种模式并不能很好地被复用。

4)总结:

分布式事务,本质上是对多个数据库的事务进行统一控制,按照控制力度可以分为:不控制、部分控制和完全控制。不控制就是不引入分布式事务;部分控制就是各种变种的两阶段提交,包括上面提到的消息事务+最终一致性、TCC模式;完全控制就是完全实现两阶段提交。

部分控制的好处是并发量和性能很好,缺点是数据一致性减弱了,完全控制则是牺牲了性能,保障了一致性,具体用哪种方式,最终还是取决于业务场景
————————————————
版权声明:本文为CSDN博主「wanghang88」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/wanghang88/article/details/79762761

原文地址:https://www.cnblogs.com/spark9988/p/11516800.html

时间: 2024-10-11 23:33:28

分布式事务特性,分布式事务处理的相关文章

设计----【分布式事务】分布式事务和解决方案

一.前言 分布式事务是企业集成中的一个技术难点,也是每一个分布式系统架构中都会涉及到的一个东西,特别是在微服务架构中,几乎可以说是无法避免,本文就分布式事务来简单聊一下. 二.数据库事务 在说分布式事务之前,我们先从数据库事务说起. 数据库事务可能大家都很熟悉,在开发过程中也会经常使用到.但是即使如此,可能对于一些细节问题,很多人仍然不清楚.比如很多人都知道数据库事务的几个特性:原子性(Atomicity ).一致性( Consistency ).隔离性或独立性( Isolation)和持久性(

【分布式事务】分布式事务解决方案

一.第一种方案:能不用分布式事务就不用 明确系统是否真的需要分布式事务: 因为不论任何一种分布式解决方案都会增加你系统的复杂度,这样的成本还是挺高的,千万不要因为追求某些设计,而引入不必要的成本和复杂度. 二.第二种方案:XA 分布式事务 (MySQL是支持XA事务的) 属于2PC:XA是由X/Open组织提出的分布式事务的规范. X/Open DTP(X/Open Distributed Transaction Processing Reference Model) 是X/Open 这个组织定

使用事件和消息队列实现分布式事务(转+补充)

虽然本文并非笔者原创,但是我们在非强依赖的事务中原理上也是采用这种方式处理的,不过因为没有仔细去总结,最近在整理和总结时看到了,故转载并做部分根据我们实际情况的完善和补充. 不同于单一架构应用(Monolith), 分布式环境下, 进行事务操作将变得困难, 因为分布式环境通常会有多个数据源, 只用本地数据库事务难以保证多个数据源数据的一致性. 这种情况下, 可以使用两阶段或者三阶段提交协议来完成分布式事务.但是使用这种方式一般来说性能较差, 因为事务管理器需要在多个数据源之间进行多次等待. 有一

分布式事务:两段式提交(最终一致性)

[MySQL如何实现分布式事务?] http://www.linuxidc.com/Linux/2013-10/91925.htm Innodb存储引擎支持XA事务,通过XA事务可以支持分布式事务的实现.分布式事务指的是允许多个独立的事务资源(transac tional resources)参与一个全局的事务中.事务资源通常是关系型数据库系统,也可以是其它类型的资源. 全局事务要求在其中所有参与的事务要么全部提交,要么全部回滚,这对于事务原有的ACID要求又有了提高.另外,在使用分布式事务时候

Spring.Net+WCF实现分布式事务

项目背景:ITOO.Teacher.Service提供一套访问教师数据库的WCF服务,ITOO.Student.Service提供一套访问学生数据库的WCF服务.学生服务端的B层在进行业务处理时,需要调用教师的WCF服务,我们需要在学生服务端的B层加上分布式事务处理,向教师库和学生库更新数据,要么都成功,要么都不成功. 1.在教师服务端,我们需要在WCF的接口上加上WCF分布式事务特性: [OperationContract] [TransactionFlow(TransactionFlowOp

还不理解“分布式事务”?这篇给你讲清楚!

这篇文章将介绍什么是分布式事务,分布式事务解决什么问题,对分布式事务实现的难点,解决思路,不同场景下方案的选择,通过图解的方式进行梳理.总结和比较. 相信耐心看完这篇文章,谈到分布式事务,不再只是有“2PC”.“3PC”.“MQ的消息事务”.“最终一致性”.“TCC”等这些知识碎片,而是能够将知识连成一片,形成知识体系. 什么是事务 介绍分布式事务之前,先介绍什么是事务. 事务的具体定义 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元,组成事务的所有操作只有在所有操作均能正

分布式事务及其解决方法

分布式事务是企业集成中的一个技术难点,也是每一个分布式系统架构中都会涉及到的一个东西,特别是在微服务架构中,几乎可以说是无法避免,本文就分布式事务来简单聊一下. 数据库事务 在说分布式事务之前,我们先从数据库事务说起. 数据库事务可能大家都很熟悉,在开发过程中也会经常使用到.但是即使如此,可能对于一些细节问题,很多人仍然不清楚.比如很多人都知道数据库事务的几个特性:原子性(Atomicity ).一致性( Consistency ).隔离性或独立性( Isolation)和持久性(Durabil

一文解读分布式事务 (转)

这篇文章将介绍什么是分布式事务,分布式事务解决什么问题,对分布式事务实现的难点,解决思路,不同场景下方案的选择,通过图解的方式进行梳理.总结和比较. 相信耐心看完这篇文章,谈到分布式事务,不再只是有“2PC”.“3PC”.“MQ的消息事务”.“最终一致性”.“TCC”等这些知识碎片,而是能够将知识连成一片,形成知识体系. 什么是事务 介绍分布式事务之前,先介绍什么是事务. 事务的具体定义 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元,组成事务的所有操作只有在所有操作均能正

[转帖]聊聊分布式事务,再说说解决方案

https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html 需要多学习一下. 前言 最近很久没有写博客了,一方面是因为公司事情最近比较忙,另外一方面是因为在进行 CAP 的下一阶段的开发工作,不过目前已经告一段落了. 接下来还是开始我们今天的话题,说说分布式事务,或者说是我眼中的分布式事务,因为每个人可能对其的理解都不一样. 分布式事务是企业集成中的一个技术难点,也是每一个分布式系统架构