分布式事务处理技术分享共38页文档

合集下载

分布式事务的处理流程

分布式事务的处理流程

分布式事务的处理流程“分布式事务”是指在企业应用中,同时和多个独立系统进行交互时所发生的各种事务,这些事务必须满足原子性,一致性,隔离性和持久性(ACID),以确保系统最终一致性和数据完整性。

近年来,经济社会发展及大数据技术发展的不断提升,分布式事务技术也取得了长足的发展,并在企业应用中得以广泛应用。

本文将从分布式事务的基本概念入手,结合实际应用梳理出分布式事务处理流程,有助于我们更加深入地了解和利用这项技术。

一、什么是分布式事务分布式事务(Distributed Transactions)是指从多个节点(例如:企业应用服务器、业务处理系统、存储设备、云服务等)中同时处理的事务。

这些事务的处理必须满足数据库的ACID(Atomicity、Consistency、Isolation、 Durability)事务特性。

此外,分布式事务也必须满足完整性(completeness),这意味着所有的事务参与者都必须有能力完成当前事务,并对其结果负责,否则系统处于不一致的状态。

二、分布式事务的处理流程1、定义事务参与者:首先,必须明确事务参与者以及其角色,例如:表示需要执行的操作的服务器、存储设备和云服务。

事务参与者将根据其角色执行不同的事务任务,这些任务将确定事务范围及其特征(例如:涉及的资源、执行的操作)。

2、初始化事务:在定义了事务参与者和任务之后,就可以初始化事务了。

分布式事务的初始化需要创建一个全局ID,用于标识事务在所有参与者中的唯一性,以及确保参与者之间的事务同步。

3、预处理阶段:在预处理阶段,事务参与者将根据本地的预执行规则按照预定的顺序执行事务,这些处理操作可以被视为初始处理步骤,它们在实际执行前先被分配给每个参与者,以供执行。

4、提交阶段:在提交阶段,事务参与者将发起一次或多次提交操作,以记录已完成的执行结果。

由于事务的ACID性质,在提交操作完成后,所有参与者必须同时完成提交操作,以确保事务的整体一致性。

常用的分布式事务解决方案介绍

常用的分布式事务解决方案介绍
• 与本地事务相比,XA 协议的系统开销相当大,因而应当慎重考虑是否确实需要分布式事务。而且只有 支持 XA 协议的资源才能参与分布式事务。
CAP定理
定理: 对于共享数据系统,最多只能同时拥有CAP 其中的两个,没法三者兼顾。
• 任两者的组合都有其适用场景 • 真实系统应当是ACID与BASE的混合体 • 不同类型的业务可以也应当区别对待
原子性(A)与持久性(D)必须根本保障 为了可用性、性能与降级服务的需要,只有降低一致性( C ) 与 隔离性( I ) 的要求
酸碱平衡(ACID-BASE Balance)
结论:最重要的是满足业务需求,而不是追求抽象、绝对的系统特性。
柔性事务
两阶段型 补偿型 异步确保型 最大努力通知型
EJB:基于组件的应用编程模型,通过声明式事务管理进一步 简化事务应用的编程。
优点 • 简单一致的编程模型 • 跨域分布处理的ACID保证
JavaEE分布式事务服务层次示意图,图中的粉红小半圆代表JTA规范
局限 • DTP模型本身的局限
标准分布式事务解决方案的利弊
优点:严格的ACID
实现方式二 系统缓存所有请求与处理结果 检测到重复请求之后,自动返回之前的处理结果
超级教程系列 《微服务架构的分布式事务解决方案》
柔性事务中的服务模式:TCC操作
缺点:效率非常低(微服务架构下已不太适用) • 全局事务方式下,全局事务管理器(TM)通过XA接口使用二阶段提交协议( 2PC )与资源层(如数据
库)进行交互。使用全局事务,数据被Lock的时间跨整个事务,直到全局事务结束。
• 2PC 是反可伸缩模式,在事务处理过程中,参与者需要一直持有资源直到整个分布式事务结束。这样, 当业务规模越来越大的情况下,2PC 的局限性就越来越明显,系统可伸缩性会变得很差。

Java 分布式事务

Java 分布式事务

分布式事务分布式事务指事务的操作位于不同的节点上,需要保证事务的 ACID 特性。

2PC两阶段提交(Two-phase Commit,2PC)是基于分布式架构下的所有节点在进行事务提交时保持一致性而设计的一种算法。

在分布式系统中,每个节点虽然可以知晓自己的操作成功或者失败,却无法知道其他节点的操作成功或失败。

当一个节点跨域多个节点时,为了保证事务的 ACID 特性,需要引入一个协调者(Coordinator)来统一掌握所有节点(参与者)的操作结果并最终指示这些节点是否要把操作结果真正提交。

思路参与者将操作成败通知协调者,再由协调者根据所有参与者反馈情况决定各参与者是否提交操作还是终止操作。

2 个阶段阶段1:请求阶段(commit-request phase)/ 表决阶段(voting phase)•协调者节点向所有参与者节点询问是否可以执行提交操作,并开始等待各参与者节点的响应。

•参与者节点执行询问发起为止的所有事务操作•各参与者节点响应协调者发起的询问阶段2:提交阶段(commit phase)如果事务在每个参与者上都执行成功,事务协调者发送通知让参与者提交事务;否则,协调者发送通知让参与者回滚事务。

需要注意的是,在准备阶段,参与者执行了事务,但是还未提交。

只有在提交阶段接收到协调者发来的通知后,才进行提交或者回滚。

存在的问题•同步阻塞所有事务参与者在等待其它参与者响应的时候都处于同步阻塞状态,无法进行其它操作。

•单点问题协调者在 2PC 中起到非常大的作用,发生故障将会造成很大影响。

特别是在阶段二发生故障,所有参与者会一直等待,无法完成其它操作。

•数据不一致在阶段二,如果协调者只发送了部分 Commit 消息,此时网络发生异常,那么只有部分参与者接收到 Commit 消息,也就是说只有部分参与者提交了事务,使得系统数据不一致。

•太过保守任意一个节点失败就会导致整个事务失败,没有完善的容错机制。

分布式事务消息技术介绍

分布式事务消息技术介绍
分布式事务消息技术介绍
目录
l 分布式应用的新需求 l 事务消息的价值 l 行业典型的方案 l 我们的实践
分布式新需求
异步化 实现应用解耦
可靠,可用的抉择
事务消息的价值
消息中间件
消息中间件利用高效消息传递机制进行平台无关的 数据交流,并基于数据通信来进行分布式系统的集 成。
事务消息
事务原子性:场景中一系列的操作要么全部成功操作,要么一 个都不操作。 消息生命周期: 生产,传输,消费 生命周期整体事务拆分: 生产者事务: 业务处理日志跟踪方案[事务方向:生成/撤销] 传输事务:异常重试方案[事务方向:必须成功] 消费者事务: 异常重试方案[事务方向:必须成功]
柔性事务
柔性事务: 相对于数据库ACID刚性事务而言的,实现数据最终一致性; 柔性事务分为:异步确保型、补偿型[TCC] 、最大努力通知型、两阶 段型[2PC]
事务消息
1、业务开始生2消息事务ID 2、 本 地 业 务 3 D 3、业务结束/记事务ID状态 4、按照事务ID状态确认:发送/1 肖
5、 4 输 消 息 通 过 重 试 机 制 确 保 2 功
生产消息 生产4输
消费4输
1、消费4输分为两种: 推送,拉 取
2、 4 输 失 败 通 过 重 试 确 保 2功 ;
3、 消 费 失 败 直 接 合 I 5 消 费 4 输 事务中统一控制。
消费消息
行业典型方案
行业典型方案
我们的实践
我们的实践
感谢聆听!
Thank you for listening.
Hale Waihona Puke

分布式事务

分布式事务

分布式事务的消除
• 增加表 message_applied(msg_id)记录被成功应用的消息,则产生最终的解决方案: • begin; INSERT INTO transaction VALUES(xid, $seller_id, $buyer_id, $amount); put_to_queue “update user(“seller”, $seller_id, amount); put_to_queue “update user(“buyer”, $buyer_id, amount); commit; • for each message in queue begin; SELECT count(*) as cnt FROM message_applied WHERE msg_id = message.id; if cnt = 0 then if message.type = “seller” then UPDATE user SET amt_sold = amt_sold + message.amount WHERE id = er_id; else UPDATE user SET amt_bought = amt_bought + message.amount WHERE id = er_id; end INSERT INTO message_applied VALUES(message.id); end commit; • if 上述事务成功 dequeue message DELETE FROM message_applied WHERE msg_id = message.id; end end
分布式事务的消除
• 分布式事务提供的ACID保证是以损害系统的可用性、性 能与可伸缩性为代价的。只有在参与分布式事务的各个数 据库实例都能够正常工作的前提下,分布式事务才能够顺 利完成,只要有一个工作不正常,整个事务就不能完成。 • 从性能和可伸缩性角度看,首先是事务的总持续时间通常 是各实例操作时间之和,因为一个事务中的各个操作通常 是顺序执行的,这样事务的响应时间就会增加很多;其次 是一般Web应用的事务都不大,单机操作时间也就几毫 秒甚至不到1毫秒,一但涉及到分布式事务,提交时节点 间的网络通信往返过程也为毫秒级别,对事务响应时间的 影响也不可忽视。

分布式事务的处理方案

分布式事务的处理方案

分布式事务的处理方案以下是 9 条关于分布式事务处理方案的内容:1. 两阶段提交不就是分布式事务处理的一个经典方案吗?就好比大家一起干活,先一起约定怎么做,然后再统一行动。

比如说在电商系统中,下单时要同时更新库存和订单状态,这时候两阶段提交就派上大用场啦!2. 补偿机制也很棒啊!就好像我们走路不小心摔了一跤,得赶紧爬起来弥补一下。

比如在银行转账中,要是中间出了差错,就可以通过补偿机制来让一切恢复正常呀!3. 消息队列是个好东西呀!这不就像我们传纸条一样,把要做的事情通过纸条传递出去。

像外卖系统中,订单信息可以通过消息队列来确保各个环节的处理呢!4. TCC 模式也不能小瞧呀!这就如同搭积木,先准备好,再执行,最后确认或回滚。

在一些金融交易场景中,TCC 模式能保障事务的准确进行呢,难道你不想试试吗?5. 最大努力通知很实用呢!这不就像是给朋友不断提醒一样,直到对方知道为止。

比如物流配送的通知,一遍又一遍地去告知,多执着呀!6. 基于可靠消息的最终一致性也很厉害哟!就好像接力比赛,一棒接一棒,最终到达终点。

像电商退款流程,就可以通过可靠消息来保证事务的最终一致呀,多神奇!7. 分布式事务中间件就像是一个超级管家!它把所有复杂的事情都包揽了。

比如在大型企业的业务系统里,有了它,处理分布式事务就轻松多了呀!8. 事务分组也很有意思哟!可以想象成把一堆任务分成小组来管理,更有条理啦。

像复杂的业务流程中,通过事务分组来让处理更清晰呢,多赞啊!9. 分布式事务的混合方案简直太强大了!就像一个武器库,各种工具都有,按需选用。

在各种多变的场景下,混合方案可以应对自如呀,这不是超厉害的嘛!我的观点结论就是:这些分布式事务处理方案各有各的优势和适用场景,我们要根据实际需求灵活选择和运用,才能更好地处理分布式事务中的各种问题!。

什么是分布式事务以及有哪些解决方案?

什么是分布式事务以及有哪些解决方案?

什么是分布式事务以及有哪些解决⽅案?1、什么是分布式事务?答:指⼀次⼤的操作由不同的⼩操作组成的,这些⼩的操作分布在不同的服务器上,分布式事务需要保证这些⼩操作要么全部成功,要么全部失败。

从本质上来说,分布式事务就是为了保证不同数据库的数据⼀致性。

2、分布式事务产⽣的原因?2.1 数据库分库分表 当数据库单表数据达到千万级别,就要考虑分库分表,那么就会从原来的⼀个数据库变成多个数据库。

例如如果⼀个操作即操作了01库,⼜操作了02库,⽽且⼜要保证数据的⼀致性,那么就要⽤到分布式事务。

2.2 应⽤SOA化 所谓的SOA化,就是业务的服务化。

例如电商平台下单操作就会产⽣调⽤库存服务扣减库存和订单服务更新订单数据,那么就会设计到订单数据库和库存数据库,为了保证数据的⼀致性,就需要⽤到分布式事务。

总结:其实上⾯两种场景,归根到底是要操作多数据库,并且要保证数据的⼀致性,⽽产⽣的分布式事务的。

3、分布式事务解决⽅案3.1 两阶段提交(2PC) XA是⼀个分布式事务协议,由Tuxedo提出。

XA中⼤致分为两部分:事务管理器和本地资源管理器。

其中本地资源管理器往往由数据库实现,⽐如Oracle、Mysql等数据库都实现了XA接⼝,⽽事务管理器作为全局的调度者,负责各个本地资源的提交回滚。

XA实现分布式事务的原理如下:总结 ⼆阶段提交看起来确实能够提供原⼦性的操作,但是它存在⼏个缺点:1、同步阻塞问题:执⾏过程中,所有参与节点都是事务阻塞型的。

当参与者占有公共资源时,其他第三⽅节点访问公共资源不得不处于阻塞状态。

2、单点故障:由于(事务管理器)协调者的重要性,⼀旦协调者发⽣故障。

(本地资源管理器)参与者会⼀直阻塞下去。

尤其在第⼆阶段,协调者发⽣故障,那么所有的参与者还都处于锁定事务资源的状态中,⽽⽆法继续完成事务操作。

(如果是协调者挂掉,可以重新选举⼀个协调者,但是⽆法解决因为协调者宕机导致的参与者处于阻塞状态的问题)3、数据不⼀致:在⼆阶段提交的阶段⼆中,当协调者向参与者发送commit请求之后,发⽣了局部⽹络异常或者在发送commit请求过程中协调者发⽣了故障,这会导致只有⼀部分参与者接收到了commit请求。

分布式事务-厦门大学数据库室

分布式事务-厦门大学数据库室

2019/7/5
5.1.2.1 分布式事务概念
定义2:分布式事务对分布式数据库的存取,经转换、分解、优化后,产生一 个涉及到用通讯原语联系的、针对多个局部数据的存取操作序列,称为分布 执行计划(DEP)。这个分布执行计划可以分解为“涉及相应场地上的局部 数据库的操作序列”,即各场地上的子DEP组成。通常称分布式事务为全局 事务,而涉及各相应场地的子DEP称之为子事务。
1、 事务
事务是用户定义的一个数据库操作序列,这些操作要 么全做,要么全不做,是一个不可分割的工作单位。
2、 集中式事务模型
事务由标识符、头 部、数据库的操作、结 束处理组成。
其中Commit表示提 交,Abort (或Rollback)
Ti: Begin Transaction . . DB operation .
《分布式数据库》
厦门大学计算机科学系
林子雨
ziyulin@
2019/7/5
5.1.2.2 分布式事务过程
从分布式系统的概念来分析,分布式事务的过程如下:
分布式事务在执行时将被分解为若干个和各场地上计算机相关的操作序列, 即子事务 为了保证事务的正确调度执行,分布式事务必须为每个子事务在相应场地上 的计算机上创建一个代理进程执行该子事务,称局部进程。只有当各子事务均正 常结束后,分布式事务才可以提交 在子事务的调度执行中,必须有一个协调者进程去协调各子事务的执行。一 般来说,这样的协调进程由分布式事务的始发场地事务,即根事务承担 在分布式事务中,由于各子事务分布在系统中的多个场地的计算机上执行, 因此子事务之间存在大量的数据及控制信息需要传输。这些传输由系统中提供的 通讯原语完成,同时子事务间的协调亦由控制原语完成
定义1:分布式事务是一个应用的操作序列,是用户对数 据库存取操作序列的执行的最小单元。
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

ห้องสมุดไป่ตู้
分布式事务处理技术分享
21、没有人陪你走一辈子,所以你要 适应孤 独,没 有人会 帮你一 辈子, 所以你 要奋斗 一生。 22、当眼泪流尽的时候,留下的应该 是坚强 。 23、要改变命运,首先改变自己。
24、勇气很有理由被当作人类德性之 首,因 为这种 德性保 证了所 有其余 的德性 。--温 斯顿. 丘吉尔 。 25、梯子的梯阶从来不是用来搁脚的 ,它只 是让人 们的脚 放上一 段时间 ,以便 让别一 只脚能 够再往 上登。
66、节制使快乐增加并使享受加强。 ——德 谟克利 特 67、今天应做的事没有做,明天再早也 是耽误 了。——裴斯 泰洛齐 68、决定一个人的一生,以及整个命运 的,只 是一瞬 之间。 ——歌 德 69、懒人无法享受休息之乐。——拉布 克 70、浪费时间是一桩大罪过。——卢梭
相关文档
最新文档