分布式事务是企业集成的一个技术难点，也是每个分布式系统架构，尤其是微服务架构都会涉及到的。表示这是不可避免的。 酸 指数据库事务正确执行的四个基本要素： 原子性 一致性 隔离 耐用性 帽 CAP原理，也称为CAP定理，指的是分布式系统中的一致性、可用性和分区容错性。 CAP原则意味着这三个要素最多只能同时达到两点，不可能三者兼顾。 一致性：分布式系统中所有数据备份是否同时具有相同的值。 可用性：集群中部分节点发生故障后，整个集群是否还能响应客户端的读写请求。 分区容忍性：实际上，分区相当于通信的时间限制要求。如果系统在时限内无法达到数据一致性，则说明发生了分区，当前操作必须在C和A之间做出选择。 基础理论 BASE理论是CAP中一致性和可用性之间权衡的结果。该理论的核心思想是：我们无法做到强一致性，但每个应用可以根据自身业务特点采取适当的方法，使系统达到最终一致性。 基本可用 软状态 最终一致 两阶段提交2PC是分布式事务中最强大的事务类型之一。两阶段提交是分两个阶段提交。第一阶段询问每个交易数据源是否准备好，第二阶段真正将数据提交给交易。数据源。 为了保证事务能够满足ACID，引入了协调器（Cooradinator）。其他节点称为参与者。协调者负责调度参与者的行为，并最终决定这些参与者是否应该提交事务。处理流程如下： 第一阶段 a) 协调者将交易内容发送给所有参与者，询问是否可以提交交易，并等待回复。 b) 每个参与者执行事务操作，并在事务日志中记录撤消和重做信息（但不提交事务）。 c) 如果参与者执行成功，则向协调者反馈yes，否则反馈no。 第二阶段如果协调者收到参与者的失败消息或超时，则直接向每个参与者发送回滚消息；否则，它会发送一条提交消息。两种情况处理如下： 情况1：当所有参与者都回答yes时，提交交易 a) 协调者向所有参与者发出提交事务的正式请求（即提交请求）。 b) 参与者执行提交请求并释放整个事务期间占用的资源。 c) 每个参与者向协调者反馈ack（响应）完成消息。 d) 协调者收到所有参与者的ack消息后，交易提交完成。 情况2：当参与者回答“否”时，事务回滚 a) 协调者向所有参与者发出回滚请求（即rollback request）。 b) 参与者使用阶段1中的undo信息执行回滚操作，释放整个事务期间占用的资源。 c) 每个参与者向协调者反馈ack完成消息。 d) 协调者收到所有参与者的ack消息后，交易完成。 1）性能问题：在事务提交阶段，所有参与者都处于同步阻塞状态，占用系统资源，容易导致性能瓶颈。 2）可靠性问题：如果协调器出现单点故障或失效，则提供者将始终被锁定。 3）数据一致性问题：在第2阶段，如果协调者和参与者都挂掉，可能会导致数据不一致。 优点：尽量保证数据的强一致性，适合需要数据强一致性的关键领域。 （事实上​​，强一致性并不能保证100%）。 缺点：实现复杂，牺牲可用性，性能影响较大。不适合高并发、高性能的场景。 三阶段提交是两阶段提交的改进版本。 3PC最关键需要解决的是协调者和参与者同时挂掉的问题，所以3PC又把2PC的准备阶段一分为二，从而出现三阶段提交。处理流程如下： 第一阶段 a) 协调者向所有参与者发出包含事务内容的canCommit请求，询问事务是否可以提交，并等待所有参与者的响应。 b) 参与者收到canCommit请求后，如果认为可以进行交易操作，则反馈yes并进入准备状态，否则反馈no。 第二阶段 协调员根据参与者的反应有以下两种可能性。 情况1：所有参与者都回答yes，协调者预执行交易 a) 协调者向所有参与者发出preCommit请求，进入准备阶段。b) 参与者收到preCommit请求后，执行事务操作，并将undo和redo信息记录在事务日志中（但不提交事务）。 c) 每个参与者向协调者反馈ack响应或no响应，并等待最终指令。 情况二：只要有一个参与者反馈“否”，或者协调者等待超时后无法收到所有提供者的反馈，交易就会中断。 a) 协调者向所有参与者发出中止请求。 b) 无论收到协调者的中止请求或等待协调者请求超时，参与者都会中断事务。 第三阶段 实际的交易提交是在这个阶段进行的，也可以分为以下两种情况。 场景1：所有参与者响应ack并执行真正的事务提交 a) 如果协调者正在工作，则向所有参与者发出 do Commit 请求。 b) 参与者收到do Commit请求后，将正式执行交易提交，并释放整个交易过程中占用的资源。 c) 每个参与者向协调者反馈ack完成消息。 d) 协调者收到所有参与者的ack消息后，交易提交完成。 情况2：只要有一个参与者反馈“否”，或者协调组在等待超时后无法收到所有提供者的反馈，则交易将被回滚。 a) 如果协调者处于工作状态，则向所有参与者发出回滚请求。 b) 参与者使用阶段1中的undo信息执行回滚操作，释放整个事务期间占用的资源。 c) 各参与者向协调组反馈ack完成消息。 d) 协调组收到所有参与者的ack消息后，事务回滚完成。 优点：与两阶段提交相比，三阶段提交减少了阻塞范围，协调者或参与者等待超时后会中断事务。避免了协调器单点问题。当第3阶段协调者出现问题时，参与者继续提交交易。 缺点：数据不一致的问题依然存在。当参与者收到preCommit请求后等待do commit指令时，如果协调者请求中断事务而协调者无法与参与者正常通信，则参与者将继续提交事务。造成数据不一致。 TCC是服务的两阶段编程模型，采用的补偿机制为： 健康）状况： 需要实现确认和补偿逻辑 需要支持幂等性 处理流程： a) Try阶段主要是测试业务系统和预留资源。 该阶段主要完成： 完成所有业务检查（一致性）。 预留必要的业务资源（准隔离）。 尝试开展业务。b) 确认阶段主要是业务系统的确认和提交。 当Try阶段执行成功并执行Confirm阶段时，Confirm阶段默认不会出错。即：只要Try成功，Confirm就一定会成功。 c) Cancel阶段主要是当业务执行错误需要回滚时取消业务并释放预留资源。 优势： 性能提升：针对特定业务控制资源锁的粒度变小，不会锁定整个资源。 数据最终一致性：基于Confirm和Cancel的幂等性，保证交易最终被确认或取消，保证数据一致性。 可靠性：解决了XA协议协调器的单点故障问题。业务主体发起并控制整个业务活动。业务活动管理器也变为多点并引入集群。 缺点：TCC的Try、Confirm、Cancel操作功能必须根据具体业务来实现，业务耦合度较高，增加了开发成本。 核心思想是将分布式事务拆分为本地事务进行处理。 解决方案是在消费者中创建一个额外的交易消息表。消费者处理业务并将交易消息记录在本地交易中。它轮询交易消息表的数据并发送交易消息。提供者基于消息中间件来消费交易消息表中的交易。 健康）状况： 服务消费者需要创建一个消息表来记录消息状态。 服务消费者和提供者需要支持幂等性。 需要补偿逻辑。 每个节点上启动一个定时线程，检查未处理或失败的消息并重新发送消息，即重试机制和幂等机制。 处理流程： 1. 服务消费者将业务数据和消息一起提交并发起交易。 2、消息通过MQ发送给服务提供者，服务消费者等待处理结果。 3. 服务提供者接收消息，完成业务逻辑，并将处理后的消息通知消费者。 容错处理如下： 当第1步发生错误时，事务回滚，相当于什么也没发生。 当步骤2和步骤3出现错误时，由于消息保存在消费者表中，因此可以重新发送到MQ进行重试。 如果第3步出现错误，且是业务失败，则服务提供者发送消息通知消费者事务失败，此时消费者发起回滚事务，执行回滚逻辑。 优点：消息数据的可靠性是从应用设计和开发的角度实现的。消息数据的可靠性不依赖于消息中间件，弱化了对MQ中间件特性的依赖。 缺点：与特定业务场景绑定，耦合性强，无法公开共享。消息数据和业务数据在同一个数据库，占用业务系统资源。当业务系统使用关系型数据库时，消息服务性能会受到关系型数据库并发性能的限制。 MQ事务消息（最终一致性）MQ 以类似于两阶段提交的方式支持事务消息。 基于MQ的分布式事务解决方案实际上是对本地消息表的封装。本地消息表是基于MQ的。协议的其他方面与本地消息表基本一致。 健康）状况： a) 需要补偿逻辑 b) 业务处理逻辑需要幂等 处理流程： c) 消费者向MQ发送半条消息。 d) MQ Server 持久化消息后，向发送方发送ack，确认消息发送成功。 e) 消费者开始执行交易逻辑。 f) 消费者根据本地事务执行结果向MQ Server提交二次确认或回滚。 g) 当 MQ Server 收到提交状态时，它会将半条消息标记为可传递。 h) 服务提供者接收消息并执行本地业务逻辑。返回处理结果。 优势： 消息数据独立存储，减少业务系统与消息系统的耦合度。 吞吐量优于本地消息表方案。 缺点： 发送一条消息需要两次网络请求（半条消息+提交/回滚）。 需要实现消息审核接口。 Saga模式是分布式异步事务、最终一致事务、灵活事务。有两种不同的方式来实现 saga 事务。两种最流行的方式是： 1. 事件/编排：当没有中央协调器（没有单点风险）时，每个服务生成并侦听来自其他服务的事件，并决定是否应采取行动。 此实现首先为事务提供服务，然后发布事件。该事件由一个或多个服务侦听，然后执行本地事务并发布（或不发布）新事件。当最后一个服务执行本地事务并且没有发布任何事件时，意味着分布式事务结束，或者它发布的事件没有被任何Saga参与者听到，则意味着事务结束。 处理流程： 订单服务保存新订单，将状态设置为待处理，并发布名为 ORDER_CREATED_EVENT 的事件。 支付服务侦听 ORDER_CREATED_EVENT 并发布事件 BILLED_ORDER_EVENT。 库存服务侦听 BILLED_ORDER_EVENT、更新库存并发布 ORDER_PREPARED_EVENT。 运输服务侦听 ORDER_PREPARED_EVENT，然后交付产品。最后，它发布 ORDER_DELIVERED_EVENT。 最后，订单服务侦听 ORDER_DELIVERED_EVENT 并将订单的状态设置为包含。假设库存服务在交易过程中出现故障。要执行回滚： 库存服务生成 PRODUCT_OUT_OF_STOCK_EVENT 订购服务和支付服务将从上面的库存服务监听此事件： ①支付服务将款项退还给顾客。 ②订单服务将订单状态设置为失败。 优点：事件/编排是实现 Saga 模式的自然方式；它简单、易于理解，不需要太多的努力来构建，并且所有参与者都是松散耦合的，因为他们彼此没有直接耦合。如果您的交易涉及 2 到 4 个步骤，这可能是一个不错的选择。 2. 命令/协调编排器：中央协调器负责集中决策和事件的业务逻辑排序。 saga Orchestrator 以命令/回复的方式与每个服务进行通信，告诉它们应该执行哪些操作。 订单服务保存待处理状态，并请求 Order Saga Coordinator（简称 OSO）启动订单交易。 OSO 向收款服务发送执行收款命令，收款服务回复一条 Payment Executed 消息。 OSO 向库存服务发送准备订单命令，库存服务将回复 OrderPrepared 消息。 OSO 向货运服务发送订单交付命令，货运服务将回复“订单已交付”消息。 OSO Order Saga 协调员必须提前了解执行“创建订单”事务所需的流程（通过读取 BPM 业务流程 XML 配置获得）。它还负责通过向每个参与者发送命令来协调分布式回滚，以在出现任何失败时撤消先前的操作。当你有一个中央协调器来协调一切时，回滚就会容易得多，因为协调器默认执行前向过程，而回滚时，它只需要执行反向过程。 优势： 避免服务之间的循环依赖，因为 saga 协调器调用 saga 参与者，但参与者不调用协调器。 分布式事务的集中编排。 只需要执行命令/回复（实际上回复消息也是一种事件消息），降低了参与者的复杂度。 随着新步骤的添加，事务复杂性保持线性，并且回滚更易于管理。 如果您想在第一个事务执行之前更改第二个事务的目标对象，您可以轻松地将其在协调器上暂停，直到第一个事务结束。​