分布式事务的解决方案（欢迎讨论~）

标签：事务 Saga 解决方案协调者阶段提交参与者分布式

背景

CAP定理

BASE理论

背景

首先必须介绍一下分布式中至关重要的两个理论：CAP 理论和 BASE 理论。

我们抽蚕拨丝一步一步来~

CAP定理

1998年，加州大学的计算机科学家 Eric Brewer提出，分布式系统有三个指标：

· Consistency (一致性)

· Availability (可用性)

· Partition tolerance (分区容错性)

Eric Brewer 说，分布式系统无法同时满足这三个指标。

这个结论就叫做CAP 定理。

BASE理论

BASE理论是对CAP的一种解决思路，包含三个思想：

1.Basically Available (基本可用) ：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。

2.SoftState (软状态)：在一定时间内，允许出现中间状态，比如临时的不一致状态。

3.Eventually Consistent (最终一致性) : 虽然无法保证强一致性, 但是在软状态结束后, 最终达到数据一致。

而分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论：

•AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。

• CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。

场景重现

分布式事务常见的解决分案

分布式事务是在分布式系统中，跨越多个计算机节点或数据存储系统进行的事务，在这种环境下保证事务的ACID（原子性、一致性、隔离性、持久性）属性是一大挑战。

1.二段提交

二阶段提交协议（Two-phase commit protocol），简称 2PC。两阶段提交是一种强一致性事务协议，它分为准备阶段和提交阶段。

在准备阶段，协调者节点询问所有参与者是否准备好提交事务，如果所有参与者都答应准备好了，那么在提交阶段，协调者会通知所有参与者提交事务。

如果有任何一个参与者在准备阶段没有准备好，那么协调者会通知所有参与者回滚事务。

有熟悉 MySQL 的同学可能马上想到了，MySQL 的事务提交就是通过几种日志来实现二阶段提交的。

如果有任何一个参与者在准备阶段没有准备好，那么协调者会通知所有参与者回滚事务。

有熟悉 MySQL 的同学可能马上想到了，MySQL 的事务提交就是通过几种日志来实现二阶段提交的。

1.1优点

原子性保证：2PC 协议可以保证所有参与者要么全部提交成功，要么全部失败回滚，从而实现跨多个分布式节点的事务的原子性。

简单直观：2PC 的设计思路简单，逻辑清晰，容易理解，这使得它在很多传统的数据库和分布式系统中得到了广泛的应用，比如 MySQL 从 5.5 版本开始支持。

1.2缺点

同步阻塞：在 2PC 的第一阶段，所有参与者在响应协调者的准备请求后，必须等待最终的提交或回滚指令。这期间，所有参与者都处于阻塞状态，无法进行其他操作，导致资源锁定时间较长，在高并发场景下很明显不太适用。

单点故障：如果协调者在第二阶段崩溃，参与者可能会无限期地等待指令，因为它们不知道应该提交还是回滚。这使得整个系统容易受到单点故障的影响。

单点故障：如果协调者在第二阶段崩溃，参与者可能会无限期地等待指令，因为它们不知道应该提交还是回滚。这使得整个系统容易受到单点故障的影响。

单点故障：如果协调者在第二阶段崩溃，参与者可能会无限期地等待指令，因为它们不知道应该提交还是回滚。这使得整个系统容易受到单点故障的影响。

2.三段提交

三阶段提交协议（Three-phase commit protocol），简称 3PC。三阶段提交（3PC）是两阶段提交（2PC）的改进版本，它旨在减少在协调者和参与者之间的阻塞时间，同时增加系统在某些故障情况下的容错能力，以下是 3PC 的三个阶段：

CanCommit 阶段

协调者行动: 发送 CanCommit 请求到所有参与者，并等待回应。
协调者行动: 发送 CanCommit 请求到所有参与者，并等待回应。

PreCommit 阶段

协调者行动: 如果所有参与者回答 Yes，协调者发送 PreCommit 请求给所有参与者，并进入 Prepared 阶段；如果有任何参与者回答 No，或者等待超时，协调者发送 abort 请求。
协调者行动: 如果所有参与者回答 Yes，协调者发送 PreCommit 请求给所有参与者，并进入 Prepared 阶段；如果有任何参与者回答 No，或者等待超时，协调者发送 abort 请求。

DoCommit 阶段

协调者行动: 一旦协调者收到所有参与者的 ACK，它会进入 DoCommit 阶段，发送 commit 请求给所有参与者

与 2PC 相比，3PC 在 PreCommit 阶段引入了超时机制，允许参与者在没有接收到协调者的最终指令时自行决定中止事务，这减少了协调者成为单点故障的可能性。

1.2实际业务场景

3PC通常用于需要较高可靠性的分布式系统中，尤其是在那些不能接受长时间锁定资源的场景。例如：

1.分布式数据库系统：分布式数据库可能使用 3PC 来确保跨多个数据中心的事务一致性。例如，一个全球性的银行可能需要在不同国家的分支机构之间处理账户转账，这时3PC可以减少在网络延迟或某个分支机构失去响应时的影响。

2.电信网络：在电信运营商的计费系统中，可能会使用 3PC 来同步跨多个服务点的账单信息，这些系统通常要求高可用性和快速响应，因此不能长时间阻塞。

3.大型分布式系统：对于需要跨多个服务和组件协调工作的大型分布式系统，比如云计算平台，3PC可以在保持事务一致性的同时，减少参与者等待协调者指令的时间

3.TCC模式

TCC（Try-Confirm-Cancel）是一种应用层的分布式事务解决方案，它将事务分为三个步骤：尝试（Try）、确认（Confirm）和取消（Cancel）：

在 Try 阶段，会预留必要的业务资源；
在 Confirm 阶段，如果所有相关的业务操作都成功了，则正式执行业务操作；
如果有操作失败，则在 Cancel 阶段执行补偿操作，回滚之前的预留资源。

假设我们买一张从深圳到北京的火车票，票价为 360 元，TCC 分为这三个步骤：

Try：检查钱包的钱是否大于等于 360，并锁住资源（360 元和这张车票）；

Cancel：如果有一个资源锁定失败，则进行 cancel 释放资源，这个过程中无论 cancel 还是其它操作失败都进行重试 cancel，所以需要保证幂等性；

Confirm：如果资源锁定都成功，则进行 confirm，资源交换，这个过程中无论 confirm 还是其它操作失败都进行重试 confirm，都需保证幂等性。

TCC 的出现解决二阶段提交的几个缺点：

单点故障问题：引入了多个业务活动管理器，集群下高可用；

数据不一致问题：引入超时补偿机制，由业务活动管理器来控制一致性；

同步阻塞问题：引入超时补偿机制，不会锁定同步，将资源转换为业务逻辑形式，粒度更小

TCC模式的每个阶段是做什么的?
Try：资源检查和预留
Confirm: 业务执行和提交
Cancel: 预留资源的释放

TCC的优点是什么?
· 一阶段完成直接提交事务，释放数据库资源，性能好
· 相比AT模型，无需生成快照，无需使用全局锁，性能最强
· 不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库TCC的缺点是什么?
有代码侵入, 需要人为编写 try、 Confirm和 Cancel接口, 太麻烦
软状态，事务是最终一致
需要考虑 Confirm和 Cancel的失败情况, 做好幂等处理。

4.分布式补偿事务（Saga）

Saga 是一种长事务的解决方案，它将一个大的分布式事务拆分成多个较小的本地事务，这些本地事务通过异步消息传递串联起来。

每个本地事务执行成功后，会发送消息触发下一个事务的执行。如果某个本地事务失败，Saga 会执行一系列补偿操作（回滚之前的操作）来保持数据的一致性。

假设有一个旅游网站，用户可以通过它预订机票、酒店和租车服务。每个预订步骤都可以视为一个 Saga 中的小事务：

用户预订机票。

用户预订酒店。

用户预订租车服务。

如果用户成功完成了所有预订步骤，那么整个旅行预订就完成了。但如果在预订租车服务时失败了，那么 Saga 会开始执行补偿操作：

取消酒店预订。

取消机票预订。

通过这种方式，Saga 确保了用户不会因为部分服务预订失败而损失金钱或留下未处理的预订。

1.4优点
灵活性：Saga 允许每个小事务独立管理，提高了系统的灵活性。

减少资源锁定：由于 Saga 不需要在事务执行过程中持续占用资源，因此可以减少长时间的资源锁定，提高系统的并发能力。

容错性：Saga 通过定义补偿操作来处理失败，增强了系统的容错能力。

适用于微服务架构：在微服务架构中，Saga 可以跨服务边界管理事务，每个服务独立处理自己的事务和补偿逻辑。

1.4.2.缺点
复杂性：实现 Saga 需要定义每个小事务的补偿操作，这可能会增加系统的复杂性。

数据一致性：Saga 不能提供 2PC 那样的即时一致性保证，它只能保证最终一致性，这在某些业务场景中可能是不够的。

补偿操作的难度：在某些情况下，补偿操作可能很难实现，尤其是当事务有副作用时（比如发送了一个不可撤销的通知）。

测试和调试：由于 Saga 涉及多个服务和补偿逻辑，测试和调试可能会更加困难。

在选择使用 Saga 模式时，需要仔细考虑业务场景是否适合最终一致性，以及是否能够有效地实现和管理补偿逻辑。对于那些需要高度一致性保证的场景，可能需要考虑其他事务管理机制。、