网站维护模式,网页传奇游戏平台排行,免费注册网站空间,网站建设化学图片文章目录 概述产生原因关键点 分布式事务解决方案3PC3PC的三个阶段#xff1a;3PC相比于2PC的改进#xff1a;3PC的缺点#xff1a; TCCTCC事务的三个阶段#xff1a;TCC事务的设计原则#xff1a;TCC事务的适用场景#xff1a;TCC事务的优缺点#xff1a;如何解决TCC模… 文章目录 概述产生原因关键点 分布式事务解决方案3PC3PC的三个阶段3PC相比于2PC的改进3PC的缺点 TCCTCC事务的三个阶段TCC事务的设计原则TCC事务的适用场景TCC事务的优缺点如何解决TCC模式易用性问题 SagaSaga模式的工作原理Saga模式的特点Saga模式的优缺点Saga模式的应用场景Saga模式的实现 Saga模式中的补偿事务具体是如何工作的补偿事务的工作流程补偿事务的关键点 在分布式系统中Saga模式与两阶段提交有什么区别设计理念实现机制使用场景优缺点 Seata基于消息队列相关文献 概述 分布式事务是指在分布式系统中跨越多个网络资源如数据库、消息队列等的事务处理。在分布式系统中事务需要确保多个服务或资源之间的操作要么全部成功要么全部失败以保持数据的一致性和完整性。 产生原因
分布式事务产生的原因是多方面的主要包括以下几点 数据库分库分表随着数据量的增长单数据库无法承载大量数据的存储和访问需求因此需要对数据库进行分库分表操作。这样原本在一个数据库中可以完成的操作可能需要跨越多个数据库来完成这就要求保证这些跨库操作的一致性从而产生了分布式事务的需求 。 应用SOA化Service-Oriented Architecture在SOA架构下业务被拆分成多个服务每个服务可能对应不同的数据库。当一个业务流程需要跨越多个服务即多个数据库时为了保证数据一致性就需要分布式事务来确保这些服务的原子性和一致性 。 微服务架构在微服务架构中一个复杂的业务操作可能需要调用多个服务来完成。这些服务可能涉及到不同的数据库操作为了保证整个业务流程的数据一致性需要分布式事务来协调这些服务的执行 。 CAP定理和BASE理论CAP定理指出在分布式系统中一致性Consistency、可用性Availability和分区容错性Partition tolerance三者不能同时满足。BASE理论则强调基本可用性、软状态和最终一致性。这些理论指导了分布式系统设计也说明了在分布式系统中实现强一致性是非常具有挑战性的因此需要分布式事务来解决数据一致性问题 。 高并发和高性能需求在高并发场景下为了保证系统的高性能需要减少锁的竞争和资源的争用。分布式事务可以通过异步处理和消息队列等方式来提高系统的吞吐量和响应速度同时保证数据的最终一致性 。 故障容错分布式系统需要能够处理节点故障和网络分区等问题。在出现故障时系统需要能够恢复到一致的状态这就要求分布式事务能够提供故障恢复和数据回滚的能力 。
总结来说分布式事务产生的原因在于分布式系统的复杂性包括数据量的增长、服务的拆分、高并发和高性能的需求以及对故障容错的能力。这些因素共同推动了分布式事务技术的发展和应用。
关键点
分布式事务的挑战主要来自于网络的不可靠性、服务的独立性以及数据的分布性。以下是分布式事务的一些关键点 原子性Atomicity事务中的所有操作要么全部完成要么全部不完成不会结束在中间某个点。 一致性Consistency事务必须使系统从一个一致的状态转换到另一个一致的状态。 隔离性Isolation事务的执行不会被其他事务干扰每个事务都感觉像是在系统中单独执行。 持久性Durability一旦事务提交它对系统的影响应该是永久性的即使系统发生故障。
在分布式系统中实现分布式事务通常会遇到以下问题
网络分区网络问题可能导致服务之间的通信失败。服务故障单个服务可能因为各种原因失败需要重启或恢复。数据不一致由于网络延迟或服务故障不同服务可能无法同步更新数据。
为了解决这些问题分布式事务通常采用以下模型或协议 两阶段提交2PC这是一种传统的分布式事务协议包括准备阶段和提交阶段。协调者Coordinator负责询问所有参与者Participants是否准备好提交事务然后根据参与者的响应来决定是提交还是回滚事务。 三阶段提交3PC这是2PC的改进版本增加了一个额外的阶段来减少阻塞。它包括询问、准备、提交三个阶段。 补偿事务Sagas这是一种基于补偿的长事务解决方案将长事务拆分为一系列较短的本地事务每个本地事务都有一个对应的补偿事务用于在出错时撤销之前的操作。 本地消息表在微服务架构中服务可以使用本地消息表来记录消息然后异步地将消息发送到其他服务。如果消息发送失败可以重试或补偿。 最终一致性在某些场景下系统可以接受短暂的数据不一致只要最终达到一致状态即可。这种模型通常用于高吞吐量和高可用性的系统。
分布式事务的实现和协调通常依赖于事务管理器、消息队列、分布式缓存等中间件的支持。在设计分布式系统时需要仔细考虑事务的需求和系统的整体架构以选择最合适的事务处理策略。
分布式事务解决方案
分布式事务的解决方案有多种每种方案都有其特点和适用场景。以下是一些常见的分布式事务解决方案 两阶段提交2PC 这是基于XA协议实现的分布式事务分为准备阶段和提交阶段。事务管理器作为全局调度者负责协调所有参与者本地资源管理器如数据库的事务状态。优点是对业务入侵小使用方可以像使用本地事务一样使用分布式事务。缺点是性能较差因为它是一个强一致性的同步阻塞协议在事务执行过程中需要锁定所有资源。适用于执行时间确定的短事务但在高并发场景下不是最佳选择。 三阶段提交3PC 这是2PC的改进版本增加了一个额外的阶段来减少阻塞。在协调者和参与者中都引入了超时机制以解决协调者故障后参与者的阻塞问题。虽然解决了协调者故障后的阻塞问题但增加了一次网络通信性能上可能更差不太推荐使用。 TCCTry-Confirm-Cancel TCC是业务层的两阶段提交变种需要在业务层编写代码实现。它包括Try、Confirm和Cancel三个操作Try阶段预留资源Confirm阶段提交资源Cancel阶段释放资源。TCC的优点是没有资源阻塞问题因为每个方法都直接进行事务的提交。缺点是对业务侵入性强开发量大需要考虑接口的幂等性。 Saga事务模型 Saga将长事务拆分为多个本地短事务由Saga事务协调器协调。如果正常结束则完成如果某个步骤失败则根据相反顺序一次调用补偿操作。Saga并发度高不用长期锁定资源但需要定义正常操作以及补偿操作开发量比XA大一致性较弱。 基于消息队列的最终一致性 通过消息中间件实现分布式事务的最终一致性。将本地事务和发消息放在同一个事务里保证本地操作和发送消息同时成功。适用于高并发场景牺牲数据的强一致性换取性能的大幅提升实现成本和复杂度较高。 Seata Seata是一款开源的分布式事务解决方案支持AT、TCC、SAGA和XA等事务模式。Seata通过在业务库中创建UNDO_LOG表来记录回滚日志以支持事务的回滚。Seata的优势在于它提供了多种事务模式并且对业务的侵入性较小同时支持高性能的分布式事务处理。 最大努力通知 这是一种轻量级的分布式事务解决方案事务的主动方会尽最大努力发送消息给被动方但如果消息未被接收被动方会定期轮询主动方以获取消息。这种方法适用于对数据一致性要求不是非常高的场景因为它不保证消息一定会被送达。
每种方案都有其适用场景和限制选择哪种方案取决于具体的业务需求和系统特性。在实际开发中可能需要根据业务场景的不同选择不同的事务实现方式。
3PC
三阶段提交3PC是二阶段提交2PC的改进版本旨在解决2PC中的一些局限性特别是在事务协调者出现单点故障时的问题。3PC通过引入超时机制和将准备阶段分为两个步骤来提高分布式事务的可靠性和容错性。以下是3PC的详细说明
3PC的三个阶段 CanCommit阶段 事务询问协调者向所有参与者发送包含事务内容的CanCommit请求询问是否可以执行事务提交操作。反馈询问响应参与者收到CanCommit请求后根据自身逻辑判断是否可以顺利执行事务反馈Yes或No。这个阶段类似于2PC的准备阶段但不会在本阶段执行事务操作只是进行询问和资源预留。 PreCommit阶段 发送预提交请求如果所有参与者都返回Yes则协调者向参与者发送PreCommit请求并进入预备状态。事务预提交参与者接收到PreCommit请求后执行事务操作并将Undo和Redo信息记录到事务日志中但不会提交事务。响应反馈如果参与者成功执行了事务操作则返回ACK响应并等待协调者的最终指令。 DoCommit阶段 执行提交如果所有参与者节点都可以进行PreCommit提交协调者向所有参与者节点发送DoCommit请求。事务提交参与者收到DoCommit请求后执行本地事务提交操作并向协调者反馈ACK消息。完成事务协调者收到所有参与者的ACK消息后完成事务。
3PC相比于2PC的改进
超时机制3PC在协调者和参与者都引入了超时机制这样即使协调者出现故障参与者在超时后也可以自动进行本地commit或abort从而避免了2PC中的协调者单点故障问题。减少阻塞时间由于3PC将2PC的准备阶段分为两个阶段可以减少协议执行期间参与者的阻塞时间从而提高了系统的性能。提高可靠性3PC在CanCommit阶段引入了准备状态可以更好地判断参与者是否准备好提交事务从而提高了协议的可靠性和容错性。
3PC的缺点
尽管3PC在设计上解决了2PC中的一些问题但它仍然存在数据不一致的风险。例如在PreCommit阶段如果协调者发送了一部分PreCommit请求后宕机那么收到PreCommit请求的参与者会执行事务操作而未收到请求的参与者则不会执行导致数据不一致。此外3PC的实现复杂度也高于2PC因为它增加了额外的阶段和超时处理逻辑。
总的来说3PC通过引入超时机制和额外的缓冲阶段提高了分布式事务的可靠性和容错性但同时也增加了实现的复杂性。在实际应用中选择3PC还是2PC取决于系统对数据一致性、性能和复杂度的具体需求。
TCC
TCCTry-Confirm-Cancel事务是一种分布式事务解决方案它通过将事务操作分为三个阶段来保证跨多个服务的操作要么全部成功要么全部失败从而维护数据的一致性。下面是TCC事务的详细介绍
TCC事务的三个阶段 Try阶段在这一阶段所有参与者尝试执行操作并预留所需的资源。这个步骤是事务的准备阶段主要目的是对业务系统进行检测及资源预留以便后续的确认操作可以顺利执行。例如在扣款场景中Try操作会检查账户余额是否充足并冻结相应的金额。 Confirm阶段如果所有参与者在Try阶段都成功那么进入Confirm阶段正式完成操作使用之前预留的资源。这个阶段是在所有Try操作成功后执行的目的是使用Try阶段预留的资源来提交事务。 Cancel阶段如果任何一个参与者在Try阶段失败那么进入Cancel阶段所有参与者回滚在Try阶段执行的操作释放预留的资源。Cancel操作是为了处理事务执行失败时的回滚操作确保系统数据的一致性。
TCC事务的设计原则 业务操作分两阶段完成接入TCC前业务操作只需要一步就能完成但在接入TCC之后需要考虑如何将其分成两个阶段完成把资源的检查和预留放在Try操作中进行真正的业务操作执行放在Confirm操作中进行。Cancel操作则用于释放Try阶段的预留资源。 并发控制在实现TCC时应考虑并发性问题将锁的粒度降到最低以最大限度提高分布式事务的并发性。 允许空回滚在没有调用TCC资源Try方法的情况下可能调用来二阶段的Cancel方法Cancel方法需要识别出这是一个空回滚并直接返回成功。 幂等控制无论是网络数据包重传还是异常事务的补偿执行都可能导致TCC服务的Try、Confirm或Cancel操作被重复执行。因此需要考虑幂等控制即这些操作执行一次和多次的业务结果是一样的。
TCC事务的适用场景
TCC事务适用于需要强一致性保证的分布式事务场景如电商平台的订单系统、跨行转账、分布式资源预订系统和金融交易处理等。
TCC事务的优缺点
优点TCC可以在分布式系统中提供强一致性保证相比于其他分布式事务模式TCC允许更细粒度的控制和优化。缺点TCC的Try、Confirm和Cancel操作功能需要按具体业务实现业务耦合度较高提高了开发成本。此外资源锁定时间长系统依赖增加要求所有参与的系统都必须实现TCC协议。
在实现TCC时需要注意幂等性、资源预留策略、超时和异常处理、事务状态管理等关键因素以确保TCC事务正确执行。
如何解决TCC模式易用性问题 框架管理事务模式Framework-managed transactions简称 FMT是一种无侵入的分布式事务解决方案它旨在解决TCC模式的易用性问题。FMT模式的主要特点是易于使用、快速接入以及对业务代码无侵入非常适合需要快速实现分布式事务管理的场景。 在FMT模式下分布式事务框架通过解析SQL语句来自动生成Confirm和Cancel阶段的操作从而免去了人工编写这些操作的麻烦。这样开发者只需要关注于业务逻辑的实现而不需要深入了解复杂的事务管理细节。FMT模式通过框架自动完成事务的协调和管理极大地简化了分布式事务的使用。
FMT模式的执行流程大致如下
在执行正常业务逻辑时框架会解析SQL语句并生成对应的SELECT语句和UNDO语句模板。在同一个本地事务中框架会注册分支事务、查询前象、执行SQL、查询后象、记录UNDO LOG。如果过程中出现异常会释放全局锁否则会等待分支事务提交/回滚时再释放全局锁。Confirm阶段相对简单主要是删除UNDO LOG并释放全局锁。Cancel阶段则稍微复杂需要检查当前数据是否符合Try中查询的后象执行UNDO语句再检查数据是否符合Try中查询的前象最后删除UNDO LOG并释放全局锁。如果出现前象或后象不一致时回滚本地事务不释放全局锁等待人工介入处理异常事务。
FMT模式的优势在于它支持可重入锁能够处理更复杂的应用场景如在一条主事务中多个分支事务对数据表中某一行数据进行了多次操作包括增、改、删等。这种场景下如果需要回滚主事务会涉及到按倒序回滚改操作、增操作即反向执行可重入锁。FMT模式能够支持处理重入锁场景的回滚操作这是它相比其他同类型模式的一个显著优势。
总的来说FMT模式通过框架管理事务提供了一种简单、高效、无侵入的方式来实现分布式事务特别适合对易用性有较高要求的业务场景。
Saga Saga模式是一种用于处理分布式系统中长事务的解决方案它通过将一个长事务拆分成一系列本地事务来实现。每个本地事务都有相应的正向操作和补偿操作。如果所有本地事务都成功那么整个Saga事务就完成了。如果其中任何一个本地事务失败就会触发补偿操作以撤销之前已经成功的操作从而保证数据的最终一致性。 Saga模式的工作原理
正向操作每个本地事务首先执行其正向操作。补偿操作如果任何一个本地事务失败Saga会按照失败点之前所有成功事务的相反顺序执行补偿操作以回滚已经执行的操作。
Saga模式的特点
长事务支持Saga特别适合处理需要长时间执行的事务如旅游订票等场景。事件驱动Saga模式通常由事件驱动各个参与者之间可以异步执行。最终一致性Saga模式保证了事务的最终一致性但不保证中间状态的一致性。灵活性Saga模式允许业务开发者根据业务场景灵活实现分布式事务。
Saga模式的优缺点
优点
高性能Saga模式一阶段就提交本地事务无锁适合长流程情况下保证性能。易于实现补偿服务即正向服务的“反向”易于理解和实现。异步执行参与者可以采用事务驱动异步执行提高吞吐量。
缺点
不保证隔离性Saga模式由于一阶段已经提交本地事务且没有进行“预留”动作所以不能保证隔离性。补偿操作的复杂性需要为每个本地事务设计和实现补偿操作增加了开发的复杂性。可能的一致性延迟由于事务和补偿操作是异步执行的可能存在一致性延迟。
Saga模式的应用场景
Saga模式适用于业务流程长且需要保证事务最终一致性的业务系统特别是在服务由多个公司开发具有不可控性时可以使用Saga模式进行分布式事务的处理。
Saga模式的实现
Saga模式的实现通常涉及以下几个关键组件
Saga协调器管理和监控Saga中所有事务的执行。本地事务每个微服务处理的分段称为本地事务。补偿事务如果某个本地事务失败Saga模式将触发补偿事务来回滚之前成功的事务。
在实际应用中Saga模式可以通过编程式补偿或基于事件的方式来实现。例如Seata提供了基于状态机引擎的Saga实现它支持服务编排的需求包括单项选择、并发、异步、子状态机调用等功能。 Saga模式中的补偿事务具体是如何工作的
Saga模式中的补偿事务是实现分布式事务最终一致性的关键机制。当分布式事务中的某个本地事务失败时Saga模式通过执行补偿事务来回滚之前已经成功执行的本地事务从而保证整个分布式系统的数据一致性。以下是补偿事务的工作流程和一些关键点
补偿事务的工作流程 正常执行在Saga模式中每个本地事务都尝试正常执行其业务操作。如果所有本地事务都成功执行那么整个分布式事务就完成了。 失败检测如果某个本地事务执行失败Saga模式会检测到这个失败并开始补偿流程。 补偿执行对于每个已经成功执行的本地事务Saga模式会按相反的顺序执行其对应的补偿事务。补偿事务的目的是撤销该本地事务对系统状态所做的更改。 回滚操作补偿事务通常包含回滚操作这些操作会将数据状态恢复到本地事务执行之前的状态。 最终状态如果所有补偿事务都成功执行那么整个分布式事务将回滚到一个一致的状态尽管这意味着事务最终没有完成。
补偿事务的关键点 幂等性补偿事务需要是幂等的这意味着无论执行多少次补偿事务都能将系统状态恢复到相同的状态。这是确保系统一致性的重要属性。 空补偿在某些情况下可能需要执行“空补偿”即在没有执行原始业务操作的情况下执行补偿操作。这要求系统能够处理这种情况并且不会因此导致数据不一致。 防止资源悬挂必须确保补偿事务能够正确地撤销资源的预留或更改以避免资源悬挂即资源被预留或更改后由于补偿失败而未能释放或回滚。 隔离性保证在设计补偿事务时需要考虑事务的隔离性确保补偿操作不会与其他事务的操作冲突。 实现复杂性补偿事务的实现可能相当复杂因为它们需要根据具体的业务逻辑来定制。开发人员需要仔细设计这些操作以确保它们能够正确地撤销原始操作的影响。 顺序和并发在Saga模式中补偿事务通常按相反的顺序执行但有时也可以并发执行特别是当某些补偿事务不依赖于其他事务的结果时。 监控和日志Saga模式的实现通常包括对事务执行和补偿操作的监控和日志记录以便于故障排查和系统维护。
补偿事务是Saga模式中实现分布式事务管理的核心它们提供了一种机制来处理分布式系统中的失败情况确保系统即使在部分失败的情况下也能达到最终一致性。 在分布式系统中Saga模式与两阶段提交有什么区别
Saga模式和两阶段提交2PC都是分布式事务的解决方案但它们在设计理念、实现机制和使用场景上有明显的区别。以下是Saga模式与两阶段提交之间的主要区别
设计理念
两阶段提交2PC基于ACID事务原则追求强一致性和原子性。它通过一个中心化的协调者来确保所有参与者要么全部提交事务要么全部回滚事务。Saga模式基于BASE理论Basically Available, Soft state, Eventual consistency追求最终一致性。Saga允许分布式事务在全部提交前提前释放占用的某些资源通过补偿事务来处理失败的情况。
实现机制
两阶段提交2PC 第一阶段准备阶段协调者询问所有参与者是否准备好提交事务。第二阶段提交阶段如果所有参与者都准备好了协调者指示所有参与者提交事务否则它指示它们回滚。 Saga模式 由一系列本地事务组成每个本地事务都有相应的补偿事务。正向执行所有本地事务如果所有事务都成功则Saga事务完成。如果任何一个事务失败Saga会执行补偿事务来撤销之前已经成功的操作。
使用场景
两阶段提交2PC适用于需要强一致性保证的分布式事务场景如金融交易、数据同步等。Saga模式适用于业务流程长、业务流程多的场景特别是对于不可控的服务如第三方服务这些服务无法遵循2PC或TCC模式Saga模式提供了一种解决方案。
优缺点
两阶段提交2PC 优点保证了事务的原子性和一致性。缺点性能较差因为它是一个同步阻塞协议在事务执行过程中需要锁定所有资源存在单点故障风险。 Saga模式 优点一阶段提交本地事务无锁高性能参与者可异步执行高吞吐补偿服务易于实现。缺点不保证隔离性可能需要额外的业务逻辑来处理并发问题在某些情况下可能无法保证实时性因为回滚操作可能会耗时较长。
总的来说Saga模式提供了一种更灵活、性能更高的分布式事务解决方案适用于对最终一致性要求较高的场景。而两阶段提交则更适合需要强一致性保证的场景。在实际应用中选择哪种方案取决于具体的业务需求和系统特性。
Seata
Seata是一个开源的分布式事务解决方案它提供了一系列事务模式来帮助开发者在微服务架构下处理复杂的事务一致性问题。Seata的主要实现模式包括AT模式、TCC模式、Saga模式和XA模式。 AT模式 AT模式是一种无侵入的分布式事务解决方案它通过代理数据源来拦截和修改SQL自动生成事务的二阶段提交和回滚操作。在一阶段Seata会拦截业务SQL记录操作前后的数据镜像形成回滚日志undo log并将其与业务数据的更新在同一个本地事务中提交。在二阶段如果全局事务需要提交Seata会异步删除回滚日志如果需要回滚则会根据回滚日志还原业务数据。AT模式的优点是对业务无侵入操作简单但可能会影响高并发系统的性能因为它需要添加全局事务锁。 TCC模式 TCC模式需要用户根据自己的业务场景实现Try、Confirm和Cancel三个操作。Try阶段负责资源的检测和预留Confirm阶段负责执行业务操作提交Cancel阶段负责预留资源的释放。TCC模式的优点是高性能适用于对性能要求较高的场景但业务侵入性强实现难度大。 Saga模式 Saga模式适用于长事务将分布式事务拆分为一系列本地事务每个本地事务都有一个与之关联的补偿操作。如果任何一个操作执行失败Saga会执行前面各参与者的逆向回滚操作以保证事务的最终一致性。Saga模式的优点是异步协调容错性好但一致性难以保证开发复杂。 XA模式 XA模式是基于XA协议的分布式事务解决方案它要求事务资源如数据库本身提供对XA协议的支持。XA模式通过两阶段提交来保证所有资源同时提交或回滚任何特定的事务。XA模式的优点是业务无侵入数据库支持广泛但可能存在数据锁定和协议阻塞的问题。
Seata通过这些事务模式结合其核心组件Transaction Coordinator、Resource Manager和Transaction Manager提供了一个全面且灵活的分布式事务解决方案。开发者可以根据自己的业务需求和场景选择合适的事务模式来实现数据的一致性管理。
基于消息队列
基于消息队列的分布式事务处理是一种通过异步消息传递来保证不同服务之间数据一致性的解决方案。在这种模式下消息队列作为核心组件它负责在不同的服务或系统之间传递消息以确保事务的最终一致性。以下是几种常见的基于消息队列的分布式事务处理模式的详细说明 事务消息半消息 事务消息也称为半消息是一种特殊的MQ消息它需要消息队列系统支持事务消息的功能。事务消息的发送分为两个阶段 第一阶段消息生产者向消息队列发送一个半消息这个消息对消费者不可见。第二阶段消息生产者根据本地事务的执行结果决定是提交还是回滚这个半消息。如果本地事务成功消息队列会将半消息标记为可消费如果本地事务失败消息队列会回滚并删除这个半消息。 这种机制确保了消息的发送与本地事务的执行是原子的从而保证了数据的一致性。RocketMQ等消息队列支持事务消息的功能 。 本地消息表 本地消息表是一种在应用数据库中维护一个消息表的方案。当本地事务执行并提交后将消息写入本地消息表然后通过后台进程或消息队列异步地将消息表中的消息发送出去。 优点实现简单对业务无侵入不需要消息队列支持事务消息。缺点需要额外的存储空间来维护消息表且在高并发下可能存在性能瓶颈 。 异步确保型事务 异步确保型事务适用于内部系统的数据一致性保障它通过消息队列来异步处理事务。这种模式下事务的发起方发送一个消息到消息队列然后消息队列将这个消息异步传递给事务的参与者。 优点解耦了事务的发起方和参与者提高了系统的可用性和伸缩性。缺点需要处理消息的重复消费和消息丢失的情况 。 最大努力通知型事务 最大努力通知型事务适用于外部系统之间的数据一致性保障它通过消息队列来尽可能地确保消息的传递。这种模式下事务的发起方发送一个消息到消息队列然后消息队列尽可能地将这个消息传递给事务的参与者。 优点适用于跨网络系统级别的对接如支付平台与运营商的对接。缺点由于网络环境的复杂性不能保证消息的100%传递成功 。
在实现基于消息队列的分布式事务时需要考虑消息的幂等性、消息的顺序性、消息的丢失和重复消费等问题。此外还需要实现事务的回查机制以确保在消息队列出现故障时能够恢复事务的状态 。
相关文献
【分布式技术】分布式共识算法Raft 【分布式技术】分布式共识算法Paxos
