常用的分布式事务解决方案介绍最新PPT
分布式事务解决方案
分布式事务解决方案引言随着互联网应用的快速发展，分布式系统的应用越来越广泛。
分布式系统的一个主要挑战是如何处理分布式事务。
分布式事务是指要在多个不同的计算节点上完成的事务，其中每个节点都可以拥有自己的本地数据库。
在传统的关系型数据库系统中，通过ACID（原子性、一致性、隔离性和持久性）的事务特性来保证数据的一致性。
然而，在分布式系统中，ACID的事务特性并不容易实现，因为分布式系统中各个节点之间的通信延迟和故障可能会导致事务的失败。
为了解决分布式系统中的事务问题，需要采用一些特殊的技术和策略。
本文将介绍一些常用的分布式事务解决方案，并对它们的优缺点进行分析。
1. 两阶段提交（2PC）两阶段提交是最常见的分布式事务解决方案之一。
它通过协调器（coordinator）和参与者（participant）之间的通信来保证事务的一致性。
1.1 原理两阶段提交的工作流程如下：1.协调器向所有参与者发送事务准备请求（Prepare Request）。
2.参与者执行事务，并将事务的执行结果和意见（同意或拒绝）发送给协调器。
3.协调器根据所有参与者的意见来决定事务是否可以提交。
4.如果所有参与者都同意提交，协调器发送事务提交请求（CommitRequest）给所有参与者。
5.参与者收到提交请求后执行事务的最终提交操作。
6.参与者向协调器发送事务提交完成的通知。
7.协调器收到所有参与者的通知后，完成事务。
1.2 优缺点优点：•简单易用，容易实现。
•可以保证事务的一致性。
缺点：•同步阻塞：所有参与者都需要等待协调器的指令，导致事务的执行效率较低。
•单点故障：协调器是系统的关键节点，一旦协调器宕机，整个系统将无法正常工作。
•数据不一致：在两阶段提交过程中，如果某个参与者在第一阶段执行成功后崩溃，则无法得知其最终的意见，可能导致数据不一致。
•过于严格的锁定：在两阶段提交过程中，参与者需要锁定资源，导致其他事务无法对该资源进行修改。
常用的分布式事务解决方案介绍
CAP定理
定理: 对于共享数据系统，最多只能同时拥有CAP 其中的两个，没法三者兼顾。
• 任两者的组合都有其适用场景 • 真实系统应当是ACID与BASE的混合体 • 不同类型的业务可以也应当区别对待
原子性（A）与持久性（D）必须根本保障 为了可用性、性能与降级服务的需要，只有降低一致性( C ) 与 隔离性( I ) 的要求
酸碱平衡(ACID-BASE Balance)
结论：最重要的是满足业务需求，而不是追求抽象、绝对的系统特性。
柔性事务
两阶段型 补偿型 异步确保型 最大努力通知型
EJB：基于组件的应用编程模型，通过声明式事务管理进一步 简化事务应用的编程。
优点 • 简单一致的编程模型 • 跨域分布处理的ACID保证
JavaEE分布式事务服务层次示意图，图中的粉红小半圆代表JTA规范
局限 • DTP模型本身的局限
标准分布式事务解决方案的利弊
优点：严格的ACID
实现方式二 系统缓存所有请求与处理结果 检测到重复请求之后，自动返回之前的处理结果
超级教程系列 《微服务架构的分布式事务解决方案》
柔性事务中的服务模式：TCC操作
缺点：效率非常低（微服务架构下已不太适用） • 全局事务方式下，全局事务管理器（TM）通过XA接口使用二阶段提交协议（ 2PC ）与资源层（如数据
库）进行交互。使用全局事务，数据被Lock的时间跨整个事务，直到全局事务结束。
• 2PC 是反可伸缩模式，在事务处理过程中，参与者需要一直持有资源直到整个分布式事务结束。这样， 当业务规模越来越大的情况下，2PC 的局限性就越来越明显，系统可伸缩性会变得很差。
分布式事务管理与恢复课件
基于复制的恢复
主从复制
一个主节点处理事务并将更改同步到 从节点。在主节点故障时，可以切换 到从节点以继续处理事务。
异步复制
事务更改首先写入本地数据库，然后 再异步复制到其他节点。这种方式可 以减少延迟，但可能增加数据不一致 的风险。
分布式事务管理与恢复ppt课件
• 分布式事务概述 • 分布式事务管理技术 • 分布式事务恢复策略 • 分布式事务管理案例分析 • 分布式事务管理面临的挑战与未
来发展
01 分布式事务概述
分布式事务的定义
分布式事务
指在分布式系统中，由多个参与者共同完成一项任务 ，并涉及到跨多个资源或服务的事务处理。
典型案例
解决方案： 使用分布式事务管理框架，如两阶段 提交（2PC）或多阶段提交（3PC），来确保跨多 个数据库或服务的事务完整性。
银行转账系统是一个典型的分布式事务应用场景 。在多银行、多分支机构的网络环境中，如何保 证转账操作的原子性、一致性、隔离性和持久性 是关键。
挑战与应对： 面临的挑战包括网络分区、节点故 障等。需要设计恢复策略，如重试、补偿事务等 ，以应对这些异常情况。
03
TCC（Try-Confirm-Cancel）：先尝试执行事务，如果成功则确认， 否则取消。
04
本地消息队列事务（Local Message Queue）：将本地消息队列作 为参与者，通过消息队列实现事务的异步处理和恢复。
02 分布式事务管理技术
两阶段提交（2PC）
两阶段提交协议是一种经典的分布式事务管理协议，用于确保分布式系统中的事务要么全部提交， 要么全部回滚。
案例三：电商系统
解析分布式事务的四种解决方案
解析分布式事务的四种解决方案分布式事务指事务的操作位于不同的节点上，需要保证事务的 AICD 特性。
例如在下单场景下，库存和订单如果不在同一个节点上，就涉及分布式事务。
在分布式系统中，要实现分布式事务，无外乎那几种解决方案。
一、两阶段提交（2PC）两阶段提交（Two-phase Commit，2PC），通过引入协调者（Coordinator）来协调参与者的行为，最终决定这些参与者是否要真正执行事务。
1、运行过程①准备阶段：协调者询问参与者事务是否执行成功，参与者发回事务执行结果。
②提交阶段：如果事务在每个参与者上都执行成功，事务协调者发送通知让参与者提交事务；否则，协调者发送通知让参与者回滚事务。
需要注意的是，在准备阶段，参与者执行了事务，但是还未提交。
只有在提交阶段接收到协调者发来的通知后，才进行提交或者回滚。
2、存在的问题①同步阻塞：所有事务参与者在等待其它参与者响应的时候都处于同步阻塞状态，无法进行其它操作。
②单点问题：协调者在 2PC 中起到非常大的作用，发生故障将会造成很大影响。
特别是在阶段二发生故障，所有参与者会一直等待状态，无法完成其它操作。
③数据不一致：在阶段二，如果协调者只发送了部分 Commit 消息，此时网络发生异常，那么只有部分参与者接收到 Commit 消息，也就是说只有部分参与者提交了事务，使得系统数据不一致。
④太过保守：任意一个节点失败就会导致整个事务失败，没有完善的容错机制。
二、补偿事务（TCC）TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。
它分为三个阶段：①Try 阶段主要是对业务系统做检测及资源预留。
②Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行Confirm阶段时，默认 Confirm阶段是不会出错的。
即：只要Try成功，Confirm一定成功。
③Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。
详解Java分布式事务的6种解决方案
详解Java分布式事务的6种解决⽅案介绍在分布式系统、微服务架构⼤⾏其道的今天，服务间互相调⽤出现失败已经成为常态。
如何处理异常，如何保证数据⼀致性，成为微服务设计过程中，绕不开的⼀个难题。
在不同的业务场景下，解决⽅案会有所差异，常见的⽅式有：1. 阻塞式重试；2. 2PC、3PC 传统事务；3. 使⽤队列，后台异步处理；4. TCC 补偿事务；5. 本地消息表（异步确保）；6. MQ 事务。
本⽂侧重于其他⼏项，关于 2PC、3PC 传统事务，⽹上资料已经⾮常多了，这⾥不多做重复。
阻塞式重试在微服务架构中，阻塞式重试是⽐较常见的⼀种⽅式。
伪代码⽰例：m := db.Insert(sql)err := request(B-Service,m)func request(url string,body interface{}){for i:=0; i<3; i ++ {result, err = request.POST(url,body)if err == nil {break}else {log.Print()}}}如上，当请求 B 服务的 API 失败后，发起最多三次重试。
如果三次还是失败，就打印⽇志，继续执⾏下或向上层抛出错误。
这种⽅式会带来以下问题1. 调⽤ B 服务成功，但由于⽹络超时原因，当前服务认为其失败了，继续重试，这样 B 服务会产⽣ 2 条⼀样的数据。
2. 调⽤ B 服务失败，由于 B 服务不可⽤，重试 3 次依然失败，当前服务在前⾯代码中插⼊到 DB 的⼀条记录，就变成了脏数据。
3. 重试会增加上游对本次调⽤的延迟，如果下游负载较⼤，重试会放⼤下游服务的压⼒。
第⼀个问题：通过让 B 服务的 API ⽀持幂等性来解决。
第⼆个问题：可以通过后台定时脚步去修正数据，但这并不是⼀个很好的办法。
第三个问题：这是通过阻塞式重试提⾼⼀致性、可⽤性，必不可少的牺牲。
阻塞式重试适⽤于业务对⼀致性要求不敏感的场景下。
分布式事务处理方案
分布式事务处理方案以下是 7 条关于分布式事务处理方案的内容：1. 嘿，你想想看啊，分布式事务处理方案就像是一个超级团队的协作策略！就好比一场足球比赛，每个球员都有自己的任务，但又必须紧密配合。
比如说在电商平台上，下单、库存管理和支付这几个环节，不就跟球员们在球场上的配合一样吗？如果没有好的分布式事务处理方案，那不就乱套啦！2. 哇哦，分布式事务处理方案可以说是解决复杂问题的秘密武器呀！这就像拼图游戏一样，每一块都有它的位置和作用。
比如银行转账系统，不同的账户和操作都要精准无误地协同，不然岂不是糟糕啦？要是没有强大的分布式事务处理方案，那不是要出大问题嘛！3. 嘿呀，分布式事务处理方案可是个了不起的东西呢！它就如同乐队演奏，各种乐器要和谐共处，才能奏出美妙的乐章。
像物流系统中，货物的运输、仓储和配送，不就得靠优秀的分布式事务处理方案来统筹吗？要是没弄好，那货不乱套啦！4. 哎呀，分布式事务处理方案简直太重要啦！它仿若一个大型建筑的根基。
你看，在一个大企业的业务流程中，多个部门和系统同时运作，不就需要可靠的分布式事务处理方案来保障稳定吗？不然出了岔子可咋办呀！5. 哇塞，分布式事务处理方案真的超级关键啊！就好像是一部精密机器的运行机制。
比如在大型医疗系统中，患者信息、诊断和治疗安排，这不就得靠有力的分布式事务处理方案来协调吗？没有它怎么行呢！6. 嘿哟，分布式事务处理方案可是不能小瞧的哦！它类似一个智能交通指挥系统。
想想看，海量数据和操作在网络世界中穿梭，没有出色的分布式事务处理方案来指挥调度，那不就成一团乱麻啦！7. 好啦，总之呢，分布式事务处理方案就是现代信息技术中不可或缺的一部分！它就像是我们生活中的氧气一样，虽然平时可能感觉不到它的存在，但一旦缺少就会出大问题。
不管是电商、金融还是其他领域，都离不开它呀！只有把分布式事务处理方案做好了，才能让各种系统顺畅运行，不然一切都得乱套喽！。
分布式事务管理与恢复ppt课件
Distributed DBMS
University of Shanghai for Science and Technology
Page 7
举例-续
一致性要求 事务执行后A 和 B账号的总 金额不变 原子性要求 如果事务在第3步和第6步 之间故障, 系统应该保证事务对数据库的 修改没有产生,否则将导致不一致性
复时,搜索Log, 确定Rollback的Trans. Distributed DBMS
Page 13
分布式事务结构
Begin Trans . . . .
Abort/Commit
Begin Trans T1 [ T2 [ . . .
Distributed DBMS
Tn [ Abort/Commit
University of Shanghai for Science and Technology
Page 24
分布式事务 管理器
命令
局部事务 管理器
回答
临时数据
命令
回答
局部事务 管理器
数据库
三角控制
数据库
Distributed DBMS
University of Shanghai for Science and Technology
Page 25
分布式事务 管理器
数据库
命令
回答
命令
局部事务 管理器
分布式事务管理与恢复
事务概念
事务是访问或更新各种数据项的程序 执行单元. 事务必须保证数据库的一致性 事务执行期间数据库可能不一致
Distributed DBMS
University of Shanghai for Science and Technology
分布式事务
分布式事务的消除
• 增加表 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毫秒，一但涉及到分布式事务，提交时节点 间的网络通信往返过程也为毫秒级别，对事务响应时间的 影响也不可忽视。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
库）进行交互。使用全局事务，数据被Lock的时间跨整个事务，直到全局事务结束。
? 2PC 是反可伸缩模式，在事务处理过程中，参与者需要一直持有资源直到整个分布式事务结束。这样， 当业务规模越来越大的情况下，2PC 的局限性就越来越明显，系统可伸缩性会变得很差。
– 可以使用业务单据号（如订单号） – 或者使用系统分配的操作流水号（如支付记录流水号） – 或者使用操作资源的组合组合标识（如商户号 +商户订单号） ? 操作有唯一的、确定的时间 (约定以谁的时间为准 )
业务服务
? 单笔查询 ? 使用全局唯一的服务操作标识，查询操作执行结果 ? 注意状态判断，小心 “处理中 ”的状态
? 批量查询 ?使用时间区段与 (或)一组服务操作的标识，查询一批操作执行结果
柔性事务中的服务模式：幂等操作
doX 业务服务
? 幂等性（ Idempotenty ） f(f(x)) = f(x)
? 幂等操作 ? 重复调用多次产生的业务结果与调用一次产生的业务结果相同
? 实现方式一 ? 通过业务操作本身实现幂等性
? 原子性（A）与持久性（D）必须根本保障 ? 为了可用性、性能与降级服务的需要，只有降低一致性( C ) 与 隔离性( I ) 的要求
? 酸碱平衡(ACID-BASE Balance)
? 结论：最重要的是满足业务需求，而不是追求抽象、绝对的系统特性。
柔性事务
? 两阶段型 ? 补偿型 ? 异步确保型 ? 最大努力通知型
全局事务（DTP模型）--XA
? XA是由X/Open 组织提出的分布式事务的规范。 X部A)资规源范管主理要器定义(R了M)(之全间局的)事接务口管。理主器流(的TM关) 和系型(局 数据库产品都是实现了 XA接口的。
? （间XA形T接M成口）通是以信双及桥向一梁的个。系或统多接个口资，源在管事理务器管（理R器M）之
? 与本地事务相比，XA 协议的系统开销相当大，因而应当慎重考虑是否确实需要分布式事务。而且只有 支持 XA 协议的资源才能参与分布式事务。
CAP定理
? 定理: 对于共享数据系统，最多只能同时拥有CAP 其中的两个，没法三者兼顾。
? 任两者的组合都有其适用场景 ? 真实系统应当是ACID与BASE的混合体 ? 不同类型的业务可以也应当区别对待
? 实现方式二 系统缓存所有请求与处理结果 检测到重复请求之后，自动返回之前的处理结果
超级教程系列 《微服务架构的分布式事务解决方案》
? 结论：分布式系统中，很难满足绝对的系统特性。
一致性
Consistency
（所有用户看到 一致的数据）
可用性 Availability
（总能找到一个 可用的数据复本）
分区容错性 Tolerance to Network Partition
（容忍网络中断）
BASE理论
? BASE
? BA: Basic Availability 基本业务可用性（支持分区失败） ? S: Soft state 柔性状态（状态允许有短时间不同步，异步） ? E: Eventual consistency 最终一致性（最终数据是一致的，但不是实时一致）
? XA之所以需要引入事务管理器是因为，在分布 式系统中，从理论上讲两台机器理论上无法达 到一致的状态，需要引入一个单点进行协调。
? 由全局事务管理器管理和协调的事务，可以跨
越多个资源（如数据库或 JMS队行交互。
XA 二阶段提交协议
两阶段提交(Two Phase Commit)
柔性事务中的服务模式
? 可查询操作 ? 幂等操作 ? TCC操作 ? 可补偿操作
注：服务模式为是实现柔性事务流程中的特殊操作模式实现（实现上对应业务服务要提供相应模式的功能接口）， 还不是某一种柔性事务解决方案。
柔性事务中的服务模式：可查询操作
doX
queryX batchQueryX
? 服务操作的可标识性 ? 服务操作具有全局唯一标识
可以是一个 DBMS，或者消息服务器管理系统） 应用程序通过资源管理器对资源进行控制，资 源必须实现 XA 定义的接口；
? TM(Transaction Manager) ：事务管理器，负
责协调和管理事务，提供给 接口以及管理资源管理器。
AP 应用程序编程
? 事务管理器控制着全局事务，管理事务生命周 期，并协调资源。资源管理器负责控制和管理 实际资源。
? 两阶段提交协议（ Two-phase commit protocol ） 是XA 用于在全局事务中协调多个资源的机制。
? TM和RM间采取两阶段提交 (Two Phase Commit) 的方案来解决一致性问题。
? 两阶段提交需要一个协调者（ TM）来掌控所有参与 者要节最点终（提交RM。）的操作结果并且指引这些节点是否需
JavaEE平台中的分布式事务实现
? JTA（Java Transaction API）：面向应用、应用服务器与资 源管理器的高层事务接口。
? JTS（Java Transaction Service ）：JTA 事务管理器的实现标 准，向上支持 JTA，向下通过 CORBA OTS实现跨事务域的互 操作性。
第03节--常用的分布式事务解决方案介绍
事务
本地事务
? 在单个数据库的本地并且限制在单 个进程内的事务
? 本地事务不涉及多个数据来源
全局事务（DTP模型）--标准分布式事务
? AP(Application Program) ：也就是应用程序， 可以理解为使用 DTP 的程序；
? RM(Resource Manager) ：资源管理器（这里
? EJB：基于组件的应用编程模型，通过声明式事务管理进一步 简化事务应用的编程。
JavaEE分布式事务服务层次示意图，图中的粉红小半圆代表JTA规范
? 优点 ? 简单一致的编程模型 ? 跨域分布处理的 ACID保证
? 局限 ? DTP模型本身的局限
标准分布式事务解决方案的利弊
? 优点：严格的ACID