概述

分布式事务是指在分布式系统中，跨越多个网络资源（如数据库、消息队列等）的事务处理。在分布式系统中，事务需要确保多个服务或资源之间的操作要么全部成功，要么全部失败，以保持数据的一致性和完整性。

产生原因

分布式事务产生的原因是多方面的，主要包括以下几点：

1. 数据库分库分表：随着数据量的增长，单数据库无法承载大量数据的存储和访问需求，因此需要对数据库进行分库分表操作。这样，原本在一个数据库中可以完成的操作可能需要跨越多个数据库来完成，这就要求保证这些跨库操作的一致性，从而产生了分布式事务的需求 。

2. 应用SOA化（Service-Oriented Architecture）：在SOA架构下，业务被拆分成多个服务，每个服务可能对应不同的数据库。当一个业务流程需要跨越多个服务（即多个数据库）时，为了保证数据一致性，就需要分布式事务来确保这些服务的原子性和一致性 。

3. 微服务架构：在微服务架构中，一个复杂的业务操作可能需要调用多个服务来完成。这些服务可能涉及到不同的数据库操作，为了保证整个业务流程的数据一致性，需要分布式事务来协调这些服务的执行 。

4. CAP定理和BASE理论：CAP定理指出，在分布式系统中，一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）三者不能同时满足。BASE理论则强调基本可用性、软状态和最终一致性。这些理论指导了分布式系统设计，也说明了在分布式系统中实现强一致性是非常具有挑战性的，因此需要分布式事务来解决数据一致性问题 。

5. 高并发和高性能需求：在高并发场景下，为了保证系统的高性能，需要减少锁的竞争和资源的争用。分布式事务可以通过异步处理和消息队列等方式来提高系统的吞吐量和响应速度，同时保证数据的最终一致性 。

6. 故障容错：分布式系统需要能够处理节点故障和网络分区等问题。在出现故障时，系统需要能够恢复到一致的状态，这就要求分布式事务能够提供故障恢复和数据回滚的能力 。

总结来说，分布式事务产生的原因在于分布式系统的复杂性，包括数据量的增长、服务的拆分、高并发和高性能的需求，以及对故障容错的能力。这些因素共同推动了分布式事务技术的发展和应用。

关键点

分布式事务的挑战主要来自于网络的不可靠性、服务的独立性以及数据的分布性。以下是分布式事务的一些关键点：

1. 原子性（Atomicity）：事务中的所有操作要么全部完成，要么全部不完成，不会结束在中间某个点。

2. 一致性（Consistency）：事务必须使系统从一个一致的状态转换到另一个一致的状态。

3. 隔离性（Isolation）：事务的执行不会被其他事务干扰，每个事务都感觉像是在系统中单独执行。

4. 持久性（Durability）：一旦事务提交，它对系统的影响应该是永久性的，即使系统发生故障。

在分布式系统中，实现分布式事务通常会遇到以下问题：

• 网络分区：网络问题可能导致服务之间的通信失败。
• 服务故障：单个服务可能因为各种原因失败，需要重启或恢复。
• 数据不一致：由于网络延迟或服务故障，不同服务可能无法同步更新数据。

为了解决这些问题，分布式事务通常采用以下模型或协议：

1. 两阶段提交（2PC）：这是一种传统的分布式事务协议，包括准备阶段和提交阶段。协调者（Coordinator）负责询问所有参与者（Participants）是否准备好提交事务，然后根据参与者的响应来决定是提交还是回滚事务。

2. 三阶段提交（3PC）：这是2PC的改进版本，增加了一个额外的阶段来减少阻塞。它包括询问、准备、提交三个阶段。

3. 补偿事务（Sagas）：这是一种基于补偿的长事务解决方案，将长事务拆分为一系列较短的本地事务，每个本地事务都有一个对应的补偿事务，用于在出错时撤销之前的操作。

4. 本地消息表：在微服务架构中，服务可以使用本地消息表来记录消息，然后异步地将消息发送到其他服务。如果消息发送失败，可以重试或补偿。

5. 最终一致性：在某些场景下，系统可以接受短暂的数据不一致，只要最终达到一致状态即可。这种模型通常用于高吞吐量和高可用性的系统。

分布式事务的实现和协调通常依赖于事务管理器、消息队列、分布式缓存等中间件的支持。在设计分布式系统时，需要仔细考虑事务的需求和系统的整体架构，以选择最合适的事务处理策略。

分布式事务解决方案

分布式事务的解决方案有多种，每种方案都有其特点和适用场景。以下是一些常见的分布式事务解决方案：

1. 两阶段提交（2PC）：

   • 这是基于XA协议实现的分布式事务，分为准备阶段和提交阶段。事务管理器作为全局调度者，负责协调所有参与者（本地资源管理器，如数据库）的事务状态。
   • 优点是对业务入侵小，使用方可以像使用本地事务一样使用分布式事务。
   • 缺点是性能较差，因为它是一个强一致性的同步阻塞协议，在事务执行过程中需要锁定所有资源。适用于执行时间确定的短事务，但在高并发场景下不是最佳选择。

2. 三阶段提交（3PC）：

   • 这是2PC的改进版本，增加了一个额外的阶段来减少阻塞。在协调者和参与者中都引入了超时机制，以解决协调者故障后参与者的阻塞问题。
   • 虽然解决了协调者故障后的阻塞问题，但增加了一次网络通信，性能上可能更差，不太推荐使用。

3. TCC（Try-Confirm-Cancel）：

   • TCC是业务层的两阶段提交变种，需要在业务层编写代码实现。它包括Try、Confirm和Cancel三个操作，Try阶段预留资源，Confirm阶段提交资源，Cancel阶段释放资源。
   • TCC的优点是没有资源阻塞问题，因为每个方法都直接进行事务的提交。缺点是对业务侵入性强，开发量大，需要考虑接口的幂等性。

4. Saga事务模型：

   • Saga将长事务拆分为多个本地短事务，由Saga事务协调器协调。如果正常结束则完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作。
   • Saga并发度高，不用长期锁定资源，但需要定义正常操作以及补偿操作，开发量比XA大，一致性较弱。

5. 基于消息队列的最终一致性：

   • 通过消息中间件实现分布式事务的最终一致性。将本地事务和发消息放在同一个事务里，保证本地操作和发送消息同时成功。
   • 适用于高并发场景，牺牲数据的强一致性换取性能的大幅提升，实现成本和复杂度较高。

6. Seata：

   • Seata是一款开源的分布式事务解决方案，支持AT、TCC、SAGA和XA等事务模式。Seata通过在业务库中创建UNDO_LOG表来记录回滚日志，以支持事务的回滚。
   • Seata的优势在于它提供了多种事务模式，并且对业务的侵入性较小，同时支持高性能的分布式事务处理。

7. 最大努力通知：

   • 这是一种轻量级的分布式事务解决方案，事务的主动方会尽最大努力发送消息给被动方，但如果消息未被接收，被动方会定期轮询主动方以获取消息。
   • 这种方法适用于对数据一致性要求不是非常高的场景，因为它不保证消息一定会被送达。

每种方案都有其适用场景和限制，选择哪种方案取决于具体的业务需求和系统特性。在实际开发中，可能需要根据业务场景的不同选择不同的事务实现方式。

3PC

三阶段提交（3PC）是二阶段提交（2PC）的改进版本，旨在解决2PC中的一些局限性，特别是在事务协调者出现单点故障时的问题。3PC通过引入超时机制和将准备阶段分为两个步骤来提高分布式事务的可靠性和容错性。以下是3PC的详细说明：

3PC的三个阶段：

1. CanCommit阶段：

   • 事务询问：协调者向所有参与者发送包含事务内容的CanCommit请求，询问是否可以执行事务提交操作。
   • 反馈询问响应：参与者收到CanCommit请求后，根据自身逻辑判断是否可以顺利执行事务，反馈Yes或No。这个阶段类似于2PC的准备阶段，但不会在本阶段执行事务操作，只是进行询问和资源预留。

2. PreCommit阶段：

   • 发送预提交请求：如果所有参与者都返回Yes，则协调者向参与者发送PreCommit请求，并进入预备状态。
   • 事务预提交：参与者接收到PreCommit请求后，执行事务操作，并将Undo和Redo信息记录到事务日志中，但不会提交事务。
   • 响应反馈：如果参与者成功执行了事务操作，则返回ACK响应，并等待协调者的最终指令。

3. 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

TCC（Try-Confirm-Cancel）事务是一种分布式事务解决方案，它通过将事务操作分为三个阶段来保证跨多个服务的操作要么全部成功，要么全部失败，从而维护数据的一致性。下面是TCC事务的详细介绍：

TCC事务的三个阶段：

1. Try阶段：在这一阶段，所有参与者尝试执行操作，并预留所需的资源。这个步骤是事务的准备阶段，主要目的是对业务系统进行检测及资源预留，以便后续的确认操作可以顺利执行。例如，在扣款场景中，Try操作会检查账户余额是否充足，并冻结相应的金额。

2. Confirm阶段：如果所有参与者在Try阶段都成功，那么进入Confirm阶段，正式完成操作，使用之前预留的资源。这个阶段是在所有Try操作成功后执行的，目的是使用Try阶段预留的资源来提交事务。

3. 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模式的执行流程大致如下：

1. 在执行正常业务逻辑时，框架会解析SQL语句，并生成对应的SELECT语句和UNDO语句模板。
2. 在同一个本地事务中，框架会注册分支事务、查询前象、执行SQL、查询后象、记录UNDO LOG。
3. 如果过程中出现异常，会释放全局锁；否则，会等待分支事务提交/回滚时再释放全局锁。
4. Confirm阶段相对简单，主要是删除UNDO LOG并释放全局锁。
5. Cancel阶段则稍微复杂，需要检查当前数据是否符合Try中查询的后象，执行UNDO语句，再检查数据是否符合Try中查询的前象，最后删除UNDO LOG并释放全局锁。如果出现前象或后象不一致时，回滚本地事务，不释放全局锁，等待人工介入处理异常事务。

FMT模式的优势在于它支持可重入锁，能够处理更复杂的应用场景，如在一条主事务中，多个分支事务对数据表中某一行数据进行了多次操作，包括增、改、删等。这种场景下，如果需要回滚主事务，会涉及到按倒序回滚改操作、增操作，即反向执行可重入锁。FMT模式能够支持处理重入锁场景的回滚操作，这是它相比其他同类型模式的一个显著优势。

总的来说，FMT模式通过框架管理事务，提供了一种简单、高效、无侵入的方式来实现分布式事务，特别适合对易用性有较高要求的业务场景。

Saga

Saga模式是一种用于处理分布式系统中长事务的解决方案，它通过将一个长事务拆分成一系列本地事务来实现。每个本地事务都有相应的正向操作和补偿操作。如果所有本地事务都成功，那么整个Saga事务就完成了。如果其中任何一个本地事务失败，就会触发补偿操作，以撤销之前已经成功的操作，从而保证数据的最终一致性。

Saga模式的工作原理：

1. 正向操作：每个本地事务首先执行其正向操作。
2. 补偿操作：如果任何一个本地事务失败，Saga会按照失败点之前所有成功事务的相反顺序执行补偿操作，以回滚已经执行的操作。

Saga模式的特点：

• 长事务支持：Saga特别适合处理需要长时间执行的事务，如旅游订票等场景。
• 事件驱动：Saga模式通常由事件驱动，各个参与者之间可以异步执行。
• 最终一致性：Saga模式保证了事务的最终一致性，但不保证中间状态的一致性。
• 灵活性：Saga模式允许业务开发者根据业务场景灵活实现分布式事务。

Saga模式的优缺点：

优点：

• 高性能：Saga模式一阶段就提交本地事务，无锁，适合长流程情况下保证性能。
• 易于实现：补偿服务即正向服务的“反向”，易于理解和实现。
• 异步执行：参与者可以采用事务驱动异步执行，提高吞吐量。

缺点：

• 不保证隔离性：Saga模式由于一阶段已经提交本地事务，且没有进行“预留”动作，所以不能保证隔离性。
• 补偿操作的复杂性：需要为每个本地事务设计和实现补偿操作，增加了开发的复杂性。
• 可能的一致性延迟：由于事务和补偿操作是异步执行的，可能存在一致性延迟。

Saga模式的应用场景：

Saga模式适用于业务流程长且需要保证事务最终一致性的业务系统，特别是在服务由多个公司开发具有不可控性时，可以使用Saga模式进行分布式事务的处理。

Saga模式的实现：

Saga模式的实现通常涉及以下几个关键组件：

• Saga协调器：管理和监控Saga中所有事务的执行。
• 本地事务：每个微服务处理的分段称为本地事务。
• 补偿事务：如果某个本地事务失败，Saga模式将触发补偿事务来回滚之前成功的事务。

在实际应用中，Saga模式可以通过编程式补偿或基于事件的方式来实现。例如，Seata提供了基于状态机引擎的Saga实现，它支持服务编排的需求，包括单项选择、并发、异步、子状态机调用等功能。

🔍 Saga模式中的补偿事务具体是如何工作的？

Saga模式中的补偿事务是实现分布式事务最终一致性的关键机制。当分布式事务中的某个本地事务失败时，Saga模式通过执行补偿事务来回滚之前已经成功执行的本地事务，从而保证整个分布式系统的数据一致性。以下是补偿事务的工作流程和一些关键点：

补偿事务的工作流程：

1. 正常执行：在Saga模式中，每个本地事务都尝试正常执行其业务操作。如果所有本地事务都成功执行，那么整个分布式事务就完成了。

2. 失败检测：如果某个本地事务执行失败，Saga模式会检测到这个失败，并开始补偿流程。

3. 补偿执行：对于每个已经成功执行的本地事务，Saga模式会按相反的顺序执行其对应的补偿事务。补偿事务的目的是撤销该本地事务对系统状态所做的更改。

4. 回滚操作：补偿事务通常包含回滚操作，这些操作会将数据状态恢复到本地事务执行之前的状态。

5. 最终状态：如果所有补偿事务都成功执行，那么整个分布式事务将回滚到一个一致的状态，尽管这意味着事务最终没有完成。

补偿事务的关键点：

• 幂等性：补偿事务需要是幂等的，这意味着无论执行多少次，补偿事务都能将系统状态恢复到相同的状态。这是确保系统一致性的重要属性。

• 空补偿：在某些情况下，可能需要执行“空补偿”，即在没有执行原始业务操作的情况下执行补偿操作。这要求系统能够处理这种情况，并且不会因此导致数据不一致。

• 防止资源悬挂：必须确保补偿事务能够正确地撤销资源的预留或更改，以避免资源悬挂，即资源被预留或更改后，由于补偿失败而未能释放或回滚。

• 隔离性保证：在设计补偿事务时，需要考虑事务的隔离性，确保补偿操作不会与其他事务的操作冲突。

• 实现复杂性：补偿事务的实现可能相当复杂，因为它们需要根据具体的业务逻辑来定制。开发人员需要仔细设计这些操作，以确保它们能够正确地撤销原始操作的影响。

• 顺序和并发：在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模式。

1. AT模式：

   • AT模式是一种无侵入的分布式事务解决方案，它通过代理数据源来拦截和修改SQL，自动生成事务的二阶段提交和回滚操作。
   • 在一阶段，Seata会拦截业务SQL，记录操作前后的数据镜像，形成回滚日志（undo log），并将其与业务数据的更新在同一个本地事务中提交。
   • 在二阶段，如果全局事务需要提交，Seata会异步删除回滚日志；如果需要回滚，则会根据回滚日志还原业务数据。
   • AT模式的优点是对业务无侵入，操作简单，但可能会影响高并发系统的性能，因为它需要添加全局事务锁。

2. TCC模式：

   • TCC模式需要用户根据自己的业务场景实现Try、Confirm和Cancel三个操作。
   • Try阶段负责资源的检测和预留；Confirm阶段负责执行业务操作提交；Cancel阶段负责预留资源的释放。
   • TCC模式的优点是高性能，适用于对性能要求较高的场景，但业务侵入性强，实现难度大。

3. Saga模式：

   • Saga模式适用于长事务，将分布式事务拆分为一系列本地事务，每个本地事务都有一个与之关联的补偿操作。
   • 如果任何一个操作执行失败，Saga会执行前面各参与者的逆向回滚操作，以保证事务的最终一致性。
   • Saga模式的优点是异步协调，容错性好，但一致性难以保证，开发复杂。

4. XA模式：

   • XA模式是基于XA协议的分布式事务解决方案，它要求事务资源（如数据库）本身提供对XA协议的支持。
   • XA模式通过两阶段提交来保证所有资源同时提交或回滚任何特定的事务。
   • XA模式的优点是业务无侵入，数据库支持广泛，但可能存在数据锁定和协议阻塞的问题。

Seata通过这些事务模式，结合其核心组件（Transaction Coordinator、Resource Manager和Transaction Manager），提供了一个全面且灵活的分布式事务解决方案。开发者可以根据自己的业务需求和场景，选择合适的事务模式来实现数据的一致性管理。

基于消息队列

基于消息队列的分布式事务处理是一种通过异步消息传递来保证不同服务之间数据一致性的解决方案。在这种模式下，消息队列作为核心组件，它负责在不同的服务或系统之间传递消息，以确保事务的最终一致性。以下是几种常见的基于消息队列的分布式事务处理模式的详细说明：

1. 事务消息（半消息）：
   事务消息，也称为半消息，是一种特殊的MQ消息，它需要消息队列系统支持事务消息的功能。事务消息的发送分为两个阶段：

   • 第一阶段：消息生产者向消息队列发送一个半消息，这个消息对消费者不可见。
   • 第二阶段：消息生产者根据本地事务的执行结果，决定是提交还是回滚这个半消息。如果本地事务成功，消息队列会将半消息标记为可消费；如果本地事务失败，消息队列会回滚并删除这个半消息。
     这种机制确保了消息的发送与本地事务的执行是原子的，从而保证了数据的一致性。RocketMQ等消息队列支持事务消息的功能 。

2. 本地消息表：
   本地消息表是一种在应用数据库中维护一个消息表的方案。当本地事务执行并提交后，将消息写入本地消息表，然后通过后台进程或消息队列异步地将消息表中的消息发送出去。

   • 优点：实现简单，对业务无侵入，不需要消息队列支持事务消息。
   • 缺点：需要额外的存储空间来维护消息表，且在高并发下可能存在性能瓶颈 。

3. 异步确保型事务：
   异步确保型事务适用于内部系统的数据一致性保障，它通过消息队列来异步处理事务。这种模式下，事务的发起方发送一个消息到消息队列，然后消息队列将这个消息异步传递给事务的参与者。

   • 优点：解耦了事务的发起方和参与者，提高了系统的可用性和伸缩性。
   • 缺点：需要处理消息的重复消费和消息丢失的情况 。

4. 最大努力通知型事务：
   最大努力通知型事务适用于外部系统之间的数据一致性保障，它通过消息队列来尽可能地确保消息的传递。这种模式下，事务的发起方发送一个消息到消息队列，然后消息队列尽可能地将这个消息传递给事务的参与者。

   • 优点：适用于跨网络系统级别的对接，如支付平台与运营商的对接。
   • 缺点：由于网络环境的复杂性，不能保证消息的100%传递成功 。

在实现基于消息队列的分布式事务时，需要考虑消息的幂等性、消息的顺序性、消息的丢失和重复消费等问题。此外，还需要实现事务的回查机制，以确保在消息队列出现故障时能够恢复事务的状态 。

相关文献

【分布式技术】分布式共识算法Raft
【分布式技术】分布式共识算法Paxos