ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

分布式事务及解决方案

2020-06-23 17:38:56  阅读:176  来源: 互联网

标签:事务 解决方案 数据库 消息 一致性 RM 分布式


在讲分布式事务之前,我们需要先了解事务

1:
1.1事务的概念:

事务:指作为单个逻辑工作单元执行的一系列操作,这些操作要么同时成功,要么同时失败(同生共死).
1.2本地事务(Local Transaction)
概念:本地事务也称为数据库事务或传统事务(相对于分布式事务而言)。它的执行模式就是常见的
1.transaction begin(开启事务)
2.insert/delete/update
3…
4.transaction commit/rollback
本地事务的特征:
1.一次事务只连接一个支持事务的数据库(一般来说都是关系型数据库,如mysql)
2.事务的执行结果保证ACID
3.会用到数据库锁
ACID:
Atomicity 原子性-undo log:
1.all or nothing,它的意思是数据库要么被修改了,要么保持原来的状态。所谓保持原来的状态不是我先insert再delete,而是压根就没有发生过任何操作。因为insert然后再delete实际上还是修改了数据库状态的,至少在数据库日志层面是这样。
2.indivisible,不可分割,一个事务就是一个最小的无法分割的独立单元,不允许部分成功部分失败。
Consistency 一致性-基于其他三个:
一致性要求任何写到数据库的数据都必须满足于预先定义的规则(比如余额不能小于0、外键约束等),简单来说就是在任何时间点都不能出现违反一致性要求的状态。
Isolation 隔离性-锁&MVCC
隔离性要求如果两个事务修改同一个数据,则必须按顺序执行,并且前一个事务如果未完成,那么未完成的中间状态对另一个事务不可见。
Durability 持久性 redo log
持久性的关键在于一旦“完成提交”(committed),那么数据就不会丢失。
数据库锁&MVCC
在提到隔离性的时候我们提到,在修改同一份数据的情况下,两个事务必须挨个执行以免出现冲突情况。而数据库有四种隔离级别(注意:不是所有数据库支持所有隔离级别)

Isolation Level隔离级别 Dirty Reads 脏读 Non-Repeatable Reads不可重复读 Phantom Reads幻读
Read uncommitted 允许 允许 允许
Read committed 不允许 允许 允许
Repeatable reads 不允许 不允许 允许
Serializable 不允许 不允许 不允许

注意:大多数数据库默认隔离级别是Read committed,在实现事务隔离级别(Read uncommitted除外)时采用的机制是锁。这也就是为什么经常说当应用程序里大量使用事务或者高并发情况下会出现性能低下、死锁的问题。
2:分布式事务:
2.1:概念
分布式事务用于在分布式系统中保证不同节点之间的数据一致性。比如有个订单服务和一个库存服务,他们各自有自己的数据库表,在交易系统的业务逻辑中,一个商品在下单之前需要先调用库存服务,进行扣除库存,再调用订单服务,创建订单记录,正常情况下,两边数据库各自更新成功,两边数据保持一致性,但是在非正常情况下,有可能库存的扣减完成了,随后的订单记录却因为某些原因插入失败。这个时候,两边数据就失去了应有的一致性。这个时候就必须保持事务的一致性,单一的数据源的一致性只需要单机事务来保证就可以了,但多数据源就需要分布式数据来保证一致性了。
2.2CAP理论–多态服务器
Consistency(一致性): 性能比较低
一致性是指写操作后的读操作可以读取到最新的数据状态,当数据分布在多个节点上,从任意结点读取到的据都是最新的状态。
怎样实现一致性的:
1、写入主节点后要将数据同步到从节点。
2、 写入主节点,要将从节点同步期间要将从节点锁定,待同步完成后再释放锁,以免在新数据写入功后,向从从节点查询到旧的数据。
一致性的特点:
1、由于存在节点同步的过程,写操作的响应会有一定的延迟。
2、为了保证数据一致性会对资源暂时锁定 ,待数据同步完成释放锁定资源。
3.如果请求数据同步失败的结点则会返回错误信息, -定不会返回旧数据。
Availability(可用性):
可用性是指任何操作都可以得到响应结果,且不会出现响应超时或响应错误。
怎样实现可用性的:
1、写入主节点后要将数据同步到从节点。
2、由于要保证从节点的可用性,不可将从节点中的资源进行锁定。
3、即时数据还没有同步过来,从节点也要返回要查询的数据,哪怕是旧数据,如果连旧数据也没有则可以约定返回一个默认信息,但不能返回错误或响应超时。
分布式系统可用性的特点:
1、所有请求都有响应,且不会出现响应超时或响应错误。
Partition tolerance(分区容忍性) 可靠性
通常分布式系统的各结点部署在不同的子网,这就是网络分区,不可避免的会出现由于网络问题而导致结点之间通信失败,此时仍可对外提供服务,这叫分区容忍性。
如何实现分区容忍性?
1、尽量使用异步取代同步操作,例如使用异步方式将数据从主节点同步到从数据,这样结点之间能有效的实现松耦合。
2、添加从节点结点,其中一个从结点挂掉其它从结点提供服务。
分布式分区容忍性的特点:
1、分区容忍性分是布式系统具备的基本能力。
2、他有多个节点
2.3常见组合
定理:任何分布式系统都只能满足2中,没有办法同时满足三种
1:满足CA舍弃P,也就是满足一致性和可用性,舍弃容错性。但是这也就意味着你的系统不是分布式的了,因为涉及分布式的想法就是把功能分开,部署到不同的机器上。单个mysql服务器。
2:满足CP舍弃A,也就是满足一致性和容错性,舍弃可用性。如果你的系统允许有段时间的访问失效等问题,这个是可以满足的。就好比多个人并发买票,后台网络出现故障,你买的时候系统就崩溃了。 redis.set(key,value) 当我在进行操作的时候其他的要进行等待或者超时异常。
3:满足AP舍弃C,也就是满足可用性和容错性,舍弃一致性。这也就是意味着你的系统在并发访问的时候可能会出现数据不一致的情况。
一般情况下分布式都必须满足分区容忍性(P),所以另一个只能选择A或C,如果数据要求立即生效,选择c,否则运行一定的延迟a。
2.4BASE理论
1、理解强一致性和最终一致性
CAP理论告诉我们一个分布式系统最多只能同时满足一致性( Consistency)、可用性( Availability )和分区容忍性( Partition tolerance )这三项中的两项,其中AP在实际应用中较多, AP即舍弃一致性,保证可用性和分区容忍性,但是在实际生产中很多场景都要实现最终一致性,比如前边我们举的例子主节点向从节点同步数据,即使不要一致性,但是最终也要将数据同步成功来保证数据一致,这种一致性和CAP中的一致性不同, CAP中的一致性要求在任何时间查询每个结点数据都必须一致,它强调的是强一致性,但是最终一致性是允许可以在一段时间内每个结点的数据不一致,但是经过一段时间每个结点的数据必须一致,它强调的是最终一致性。
(1)强一致性
对于关系型数据库,要求更新过的数据能被后续的访问都能看到,这是强一致性。比如小明更新V0到V1,那么小华读取的时候也应该是V1。
(2)弱一致性
如果能容忍后续的部分或者全部访问不到,则是弱一致性。比如小明更新VO到V1,可以容忍那么小华读取的时候是V0。
(3)最终一致性
如果经过一段时间后要求能访问到更新后的数据,则是最终一致性。比如小明更新VO到V1,可以使得小华在一段时间之后读取的时候是V1。
为了保证分布式系统的可用性,牺牲强一致性,采用最终一致性。
2Base理论
BASE是Basically Available(基本可用)、Soft state(软状态)和Eventually consistent (最终一致性)三个短语的缩写。BASE理论是对CAP中AP的一个扩展,通过牺牲强一致性来获得可用性,当出现故障允许部分不可用但要保证核心功能可用,允许数据在一段时间内是不一致的,但最终达到一致状态。满足BASE理论的事务,我们称之为"柔性事务"。
●基本可用:分布式系统在出现故障时,允许损失部分可用功能,保证核心功能可用。如,电商网站交易付款出现问题了,商品依然可以正常浏览。
●软状态:由于不要求强一致性,所以BASE允许系统中存在中间状态(也叫软状态) ,这个状态不影响系统可用性,如订单的"支付中"、“数据同步中”等状态,待数据最终一致后状态改为“成功”状态。
●最终一致:最终一致是指经过一段时间后,所有节点数据都将会达到一致。如订单的"支付中"状态,最终会变为“支付成功”或者"支付失败" ,使订单状态与实际交易结果达成-致,但需要一定时间的延迟等待。
操作我时其他可用,但是有中间状态,但是要最终一致性。
p一定要满足,c和a二选1,ap用得最多,但是我们还要使用base理论来完成最终一致性
3:分布式事务的解决方案
3.1 2pc
3.1.1:2PC的概念
2PC即两阶段提交协议,是将整个事务流程分为两个阶段,准备阶段( Prepare phase).提交阶段
( commit phase ) , 2是指两个阶段, P是指准备阶段, C是指提交阶段。
在这里插入图片描述
在这里插入图片描述
都成功则成功,有一个失败就回滚
3.1.2.基于XA协议的两阶段提交方案
2PC的传统方案是在数据库层面实现的,如Oracle、MySQL都支持2PC协议,为了统一标准,减少行业内不必要的对接成本,需要制定标准化的处理模型及接口标准,国际开放标准组织Open Group定义了分布式事务处理模型DTP ( Distributed Transaction Processing Reference Model )。
DTP模型定义如下角色:
●AP(Application Program) :即应用程序,可以理解为使用DTP分布式事务的程序。
●RM(Resource Manager) :即资源管理器,可以理解为事务的参与者, 一般情况下是指一个数据库实例,通过资源管理器对该数据库进行控制,资源管理器控制着分支事务。
●TM(Transaction Manager) :事务管理器,负责协调和管理事务,事务管理器控制着全局事务,管理事务生命周期,并协调各个RM。
全局事务是指分布式事务处理环境中,需要操作多个数据库共同完成一个工作,这个工作即是一个全局事务。
●DTP模型定义TM和RM之间通讯的接口规范叫XA ,简单理解为数据库提供的2PC接口协议,基于数据库的XA协议来实现2PC又称为XA方案。
●以上三个角色之间的交互方式如下:
1 ) TM向AP提供应用程序编程接口, AP通过TM提交及回滚事务。
2 ) TM交易中间件通过XA接口来通知RM数据库事务的开始、结束以及提交、回滚等。
以以上案例为例步骤:
执行流程如下:
1、应用程序( AP )持有用户库和积分库两个数据源(RM)。
2、应用程序( AP )通过TM通知用户库RM新增用户,同时通知积分库RM为该用户新增积分, RM此时并未提交事务,此时用户和积分资源锁定。
3、TM收到执行回复,只要有一方失败则分别向其他RM发起回滚事务,回滚完毕,资源锁释放。
4、TM收到执行回复,全部成功,此时向所有RM发起提交事务,提交完毕,资源锁释放。
总结:
整个xa协议2PC的事务流程涉及到三个角色AP、RM、TM。 AP指的是使用2PC分布式事务的应用程序; RM指的是资源管理器,它控制着分支事务; TM指的是事务管理器,它控制着整个全局事务。
1 )在准备阶段RM执行实际的业务操作,但不提交事务,资源锁定;
2 )在提交阶段TM会接受RM在准备阶段的执行回复,只要有任一个RM执行失败 , TM会通知所有RM执行回滚操作,否则, TM将会通知所有RM提交该事务。提交阶段结束资源锁释放。
XA方案的问题:
1、需要本地数据库支持XA协议。
2、资源锁需要等到两个阶段结束才释放,性能较差。
3.1.3.Seata的两阶段提交方案
Seata是由阿里中间件团队发起的开源项目Fescar ,后更名为Seata ,它是一个是开源的分布式事务框架。传统2PC的问题在Seata中得到了解决,它通过对本地关系数据库的分支事务的协调来驱动完成全局事务,是工作在应用层的中间件。主要优点是性能较好,且不长时间占用连接资源,它以高效并且对业务0侵入的方式解决微服务场景下面临的分布式事务问题,它目前提供AT模式(即2PC)及TCC模式的分布式事务解决方案。
●Transaction Coordinator(TC):事务协调器,它是独立的中间件,需要独立部署运行,它维护全局事务的运行状态,接收TM指令发起全局事务的提交与回滚,负责与RM通信协调各各分支事务的提交或回滚。 相当于是一个软件需要单独部署
●Transaction Manager ™:事务管理器, TM需要嵌入应用程序中工作,它负责开启一个全局事务,并最终向TC发起全局提交或全局回滚的指令。
●Resource Manager (RM):控制分支事务, 负责分支注册、状态汇报,并接收事务协调器TC的指令, 驱动分支(本地)事务的提交和回滚。
在这里插入图片描述具体的执行流程如下:|
1.用户服务的TM向TC申请开启一个全局事务,全局事务创建成功并生成一个全局唯一的XID。
2.用户服务的RM向TC注册分支事务,该分支事务在用户服务执行新增用户逻辑,并将其纳入XID对应全局事务的管辖。
3.用户服务执行分支事务,向用户表插入一条记录。
4.逻辑执行到远程调用积分服务时(XID在微服务调用链路的,上下文中传播)。积分服务的RM向TC注册分支事务,该分支事务执行增加积分的逻辑,并将其纳入XID对应全局事务的管辖。
5.积分服务执行分支事务,向积分记录表插入一条记录,执行完毕后,返回用户服务。
3.1.4.Seata实现2PC与传统2PC的差别
架构层次方面,传统2PC方案的RM实际上是在数据库层, RM本质上就是数据库自身,通过XA协议实现,而Seata的RM是以jar包的形式作为中间件层部署在应用程序这一侧的。
两阶段提交方面,传统2PC无论第二阶段的决议是commit还是rollback ,事务性资源的锁都要保持到Phase2完成才释放。而Seata的做法是在Phase1就将本地事务提交,这样就可以省去Phase2持锁的时间,整体提高效率。
3.2.TCC (Try-Confirm-Cancle)
3.2.1.什么是TCC
概念:TCC, 是基于补偿型事务的AP系统的一种实现, 具有强一致性
在这里插入图片描述
事务开始时,业务应用会向事务协调器注册启动事务。之后业务应用会调用所有服务的try接口,完成一阶段准备。之后事务协调器会根据try接口返回情况,决定调用confirm接口或者cancel接口。如果接口调用失败,会进行重试。
3.2.2.优缺点
优点: 异步执行效率高
TCC能够对分布式事务中的各个资源进行分别锁定, 分别提交与释放, 例如, 假设有AB两个操作, 假设A操作耗时短, 那么A就能较快的完成自身的try-confirm-cancel流程, 释放资源. 无需等待B操作. 如果事后出现问题, 追加执行补偿性事务即可.
TCC是绑定在各个子业务上的(除了cancle中的全局回滚操作), 也就是各服务之间可以在一定程度上”异步并行”执行.
缺点:
对应用的侵入性强。业务逻辑的每个分支都需要实现try、confirm、cancel三个操作,应用侵入性较强,改造成本高。实现难度较大。需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。为了满足一致性的要求,confirm和cancel接口必须实现幂等-一个操作多次循环都是一样。
注意:
事务管理器(协调器)这个节点必须以带同步复制语义的高可用集群(HAC)方式部署.
事务管理器(协调器)还需要使用多数派算法来避免集群发生脑裂问题.
使用场景:
严格一致性
执行时间短
实时性要求高
举例: 红包, 收付款业务,秒杀等
3.3.可靠消息最终一致性
可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息,事务参与方(消息消费者)一定能够接收消息并处理事务成功,此方案强调的是只要消息发给事务参与方最终事务要达到一致
事务发起方-订单-改订单状态
事务参与方-库存-加库存
3.3.2.需要解决的问题
1)本地事务和消息发送原子性
本地事务与消息发送的原子性问题即:事务发起方在本地事务执行成功后消息必须发出去,否则就丢弃消息。即实现本地事务和消息发送的原子性,要么都成功,要么都失败。本地事务与消息发送的原子性问题是实现可靠消息最终一致性方案的关键问题。
2)事务参与方接收消息可靠性
事务参与方必须能够从消息队列接收到消息,如果接收消息失败可以重复接收消息
3)消息重复消息问题
由于网络2的存在,若某一个消费节点超时但是消费成功,此时消息中间件会重复投递此消息,就导致了消息的重复消费。要解决消息重复消费的问题就要实现事务参与方的方法幂等性。
3.3.3.本地消息表方案
地消息表这个方案最初是eBay提出的,此方案的核心是通过本地事务保证数据业务操作和消息的一致致性,然后通过定时任务将消息发送至消息中间件,待确认消息发送给消费方成功再将消息删除。
优点:简单
缺点:要创建很多本地消息表。
3.3.4.RocketMQ方案
RocketMQ是一个来自阿里巴巴的分布式消息中间件 ,于2012年开源,并在2017年正式成为Apache顶级项目。据了解,包括阿里云上的消息产品以及收购的子公司在内,阿里集团的消息产品全线都运行在
RocketMQ之.上,并且最近几年的双十一大促中, RocketMQ都有抢眼表现。Apache RocketMQ 4.3之后的版本正式支持事务消息;为分布式事务实现提供了便利性支持。
RocketMQ事务消息设计则主要是为了解决Producer端的消息发送与本地事务执行的原子性问题,
RocketMQ的设计中broker与producer端的双向通信能力,使得broker天生可以作为一个事务协调者存在;而RocketMQ本身提供的存储机制为事务消息提供了持久化能力; RocketMQ的高可用机制以及可靠消息设计则为事务消息在系统发生异常时依然能够保证达成事务的最终一致性。在RocketMQ 4.3后实现了完整的事务消息,实际上其实是对本地消息表的一个封装,将本地消息表移动到了MQ内部,解决Producer端的消息发送与本地事务执行的原子性问题。
执行的步骤如下:
1.MQ发送方发送远程事务消息到MQ Server;
2.MQ Server给予响应, 表明事务消息已成功到达MQ Server.
3.MQ发送方Commit本地事务.
4.若本地事务Commit成功, 则通知MQ Server允许对应事务消息被消费; 若本地事务失败, 则通知MQ Server对应事务消息应被丢弃.
5.若MQ发送方超时未对MQ Server作出本地事务执行状态的反馈, 那么需要MQ Servfer向MQ发送方主动回查事务状态, 以决定事务消息是否能被消费.
6.当得知本地事务执行成功时, MQ Server允许MQ订阅方消费本条事务消息.
3.4.最大努力通知
目标:发起通知方(接口提供方)通过一定的机制最大努力将业务处理结果通知到接收方(接口调用方)。
具体包括:
1、有一定的消息重复通知机制。
因为接收通知方可能没有接收到通知,此时要有一定的机制对消息重复通知。 10s 1min 10min 1h 5h 1d
2、消息校对机制。
如果尽最大努力也没有通知到接收方,或者接收方消费消息后要再次消费,此时可由接收方主动向通知方查询消息信息来满足需求
3.4.2.最大努力通知与可靠消息一致性有什么不同 ?
可靠消息最终一致性:自己处理完成,发消息让对方处理。
最大努力通知: 先调用别人,别人调用成功,再尽最大努力来通知我。我得到通知了以后再来操作。
3.5.各种方案选型
在学习各种分布式事务的解决方案后,我们了解到各种方案的优缺点:
2PC最大的诟病是一个阻塞协议。RM在执行分支事务后需要等待TM的决定,此时服务会阻塞并锁
定资源。由于其阻塞机制和最差时间复杂度高,因此,这种设计不能适应随着事务涉及的服务数量增加而扩
展的需要,很难用于并发较高以及子事务生命周期较长(long-running transactions)的分布式服务中。
如果拿TCC事务的处理流程与2PC两阶段提交做比较, 2PC通常都是在跨库的DB层面,而TCC则在应用层面的处理,需要通过业务逻辑来实现。这种分布式事务的实现方式的优势在于,可以让应用自己定义数据操作的粒度,使得降低锁冲突、提高吞吐量成为可能。而不足之处则在于对应用的侵入性非常强,业务逻辑的每个分支都需要实现try、confirm、 cancel三个操作。 此外,其实现难度也比较大,需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。典型的使用场景:登录送优惠券等。
可靠消息最终一致性事务适合执行周期长且实时性要求不高的场景。引入消息机制后,同步的事务操作变
为基于消息执行的异步操作,避免了分布式事务中的同步阻塞操作的影响,并实现了两个服务的解耦。典型的使用场景:注册送积分,登录送优惠券等。
最大努力通知是分布式事务中要求最低的一种,适用于一些最终一致性时间敏感度低的业务 ;允许发起通知方处理业务失败,在接收通知方收到通知后积极进行失败处理,无论发起通知方如何处理结果都会不影响到接收通知方的后续处理;发起通知方需提供查询执行情况接口,用于接收通知方校对结果。典型的使用 场景:银行通知、支付结果通知等。
在这里插入图片描述
总结:
在条件允许的情况下,我们尽可能选择本地事务单数据源,因为它减少了网络交互带来的性能损耗,且避
免了数据弱一致性带来的种种问题。若某系统频繁且不合理的使用分布式事务,应首先从整体设计角度观察服务的拆分是否合理,是否高内聚低耦合?是否粒度太小?分布式事务一直是业界难题,因为网络的不确定性,
而且我们习惯于拿分布式事务与单机事务ACID做对比。
无论是数据库层的XA、还是应用层TCC、可靠消息、最大努力通知等方案,都没有完美解决分布式事务问题,它们不过是各自在性能、一致性、可用性等方面做取舍,寻求某些场景偏好下的权衡。

标签:事务,解决方案,数据库,消息,一致性,RM,分布式
来源: https://blog.csdn.net/java_nanhai/article/details/106870943

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有