分布式事务入门，最终一致性方案

分布式事务

回顾分布式事务

上篇内容我们说到了分布式事务的基本内容，讲到了分布式事务的实现主要有事务协调以及最终一致性两件事情来完成整个逻辑。
那么上个文章我们说过了 2PC、3PC、XA 三种协调事务的协议，这次我们来说事务协调处理完成后，对于我们事务完成的最终一致性如何保证的问题。今天主要说到的是三种最终一致性的方案：本地消息表、TCC、SAGA。

为什么要有最终一致性？

2PC（两阶段提交）和 3PC（三阶段提交）协议虽然旨在提高分布式事务的可靠性，但它们并不能完全消除故障的可能性。2PC可能因为协调器的单点故障而导致事务挂起，而3PC尽管通过引入额外的预提交阶段来减少这种风险，但在网络分区或多个节点同时故障的情况下仍可能遇到问题。XA标准提供了一种分布式事务处理的框架，但实现复杂，且在出现网络问题或参与者故障时也可能导致数据不一致。因此，这些传统协议虽然减少了某些类型故障的影响，但在高可用性、可伸缩性和网络稳定性要求的现代分布式系统中，它们可能不足以完全保证事务的一致性和可靠性。

在分布式事务中，最终一致性是关键，因为它确保在系统的不同部分最终会达到一致的状态，即使在面临网络延迟、系统故障或数据复制延迟等分布式环境固有的问题时。这对于保持数据的整体一致性和可靠性至关重要，特别是在涉及多个服务或数据库的复杂系统中。没有最终一致性，系统的不同部分可能会长时间保持不一致状态，导致数据丢失、应用逻辑错误或用户体验差等问题。因此，设计一个能够确保最终一致性的分布式事务解决方案是维持系统整体健康和功能性的基础。

CAP 与 ACID 中的一致性

了解 CAP 定理和 ACID 属性对学习分布式系统非常有帮助，因为它们为理解分布式系统的基本权衡和设计原则提供了框架。CAP 定理阐明了在分布式系统设计中一致性、可用性和分区容错之间的权衡。ACID 属性定义了数据库事务的四个关键特性：原子性、一致性、隔离性和持久性，这些都是分布式设计的基石。通过先学习这些基本概念，可以更好地理解分布式系统的复杂性和设计挑战，为深入学习打下坚实的基础。

什么是 CAP

CAP 定理（Consistency、Availability、Partition Tolerance Theorem），也称为 Brewer 定理，起源于在 2000 年 7 月，是加州大学伯克利分校的 Eric Brewer 教授于“ACM 分布式计算原理研讨会（PODC）”上提出的一个猜想。

CAP 定理图

CAP 分别代表的含义：

一致性（Consistency）： 代表数据在任何时刻、任何分布式节点中所看到的都是符合预期的。一致性在分布式研究中是有严肃定义、有多种细分类型的概念，以后讨论分布式共识算法时，我们还会再提到一致性，那种面向副本复制的一致性与这里面向数据库状态的一致性严格来说并不完全等同，具体差别我们将在后续分布式共识算法中再作探讨。

可用性（Availability）： 代表系统不间断地提供服务的能力，理解可用性要先理解与其密切相关两个指标：可靠性（Reliability）和可维护性（Serviceability）。可靠性使用平均无故障时间（Mean Time Between Failure，MTBF）来度量；可维护性使用平均可修复时间（Mean Time To Repair，MTTR）来度量。可用性衡量系统可以正常使用的时间与总时间之比，其表征为：A=MTBF/（MTBF+MTTR），即可用性是由可靠性和可维护性计算得出的比例值，譬如 99.9999%可用，即代表平均年故障修复时间为 32 秒。

分区容忍性（Partition Tolerance）： 代表分布式环境中部分节点因网络原因而彼此失联后，即与其他节点形成“网络分区”时，系统仍能正确地提供服务的能力。

CAP 的场景说明

下面我们根据一个简单的例子说明为什么 CAP 定理中一般在分布式系统中只能最多实现两个。

想象一个简单的游戏，比如玩具店，有两个门：一个在前面，一个在后面。现在，玩具店决定在每个门安装一个计数器来记录进出的顾客数量。为了保持这两个计数器同步，每当一个顾客进入或离开时，他们需要更新两个计数器。这就是一致性（C）。如果玩具店非常忙，更新两个计数器可能会导致顾客等待，这就牺牲了可用性（A）。如果店里的网络出问题，连接前门和后门的系统可能无法通信，这就是分区容错性（P）。在这种情况下，玩具店必须决定是确保两个计数器完全一致（牺牲P），还是让顾客不用等待（牺牲C），因为同时做到这三点是很困难的。

---

CAP 相关的影