3. 分布式事务核心概念：事务、ACID、CAP理论、BASE理论、最终一致性
在深入分布式事务的接口契约之前，必须建立一套精确的概念坐标系。本章将拆解事务的原子本质、ACID的强约束、CAP的不可兼得三角、BASE的柔性妥协以及最终一致性的收敛模型。这些概念构成了分布式事务设计的所有决策依据。
3.1 事务：从本地到分布式的演化
事务（Transaction）是一组不可分割的操作单元，要么全部成功提交，要么全部回滚。在单机数据库中，事务通过锁和日志实现；在分布式系统中，事务跨越多个独立节点，需要引入协调者与参与者之间的通信协议。
| 维度 | 本地事务 | 分布式事务 |
|---|---|---|
| 参与者数量 | 单个数据库实例 | 多个服务/数据库实例 |
| 协调机制 | 数据库内部锁+日志 | 外部协调者（如TC） |
| 回滚范围 | 单机Undo日志 | 跨节点补偿操作 |
| 隔离级别 | SQL标准隔离级别 | 全局快照或业务补偿 |
| 典型实现 | MySQL InnoDB | XA、TCC、Saga |
关键认知：分布式事务不是本地事务的简单放大。本地事务依赖共享内存和磁盘，分布式事务依赖网络通信和共识协议。网络不可靠、节点故障、时钟偏差等新问题，使得ACID在分布式环境下必须重新诠释。
3.2 ACID：强一致性的黄金标准
ACID是数据库事务正确执行的四个属性，由Jim Gray等人于20世纪70年代提出，至今仍是事务系统的理论基石。
- 原子性（Atomicity）：事务中的所有操作要么全部完成，要么全部不做。在分布式场景下，原子性要求所有参与者节点对事务结果达成一致。
- 一致性（Consistency）：事务执行前后，数据库必须满足所有预定义的约束（如主键、外键、业务规则）。一致性是应用层的语义保证，而非系统层的自动属性。
- 隔离性（Isolation）：并发执行的事务之间互不干扰。隔离级别从低到高包括：读未提交、读已提交、可重复读、可串行化。
- 持久性（Durability）：已提交的事务结果必须永久保存，即使系统崩溃也不会丢失。
分布式陷阱：在分布式事务中，隔离性是最难实现的属性。全局可串行化需要分布式锁或全局时钟，性能代价极高。因此，大多数分布式事务方案（如TCC、Saga）选择放弃全局隔离性，转而通过业务补偿来保证最终一致性。
3.3 CAP理论：分布式系统的不可兼得三角
CAP理论由Eric Brewer于2000年提出，2002年被证明为定理。它指出：在分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）三者最多只能同时满足两个。
实践解读：由于网络分区（P）在分布式系统中必然发生，所以设计者实际上只能在CP和AP之间做选择。CP系统（如ZooKeeper、etcd）在分区时牺牲可用性保证一致性；AP系统（如Cassandra、Eureka）在分区时牺牲一致性保证可用性。分布式事务方案通常属于CP系统，但会通过最终一致性来缓解可用性损失。
3.4 BASE理论：柔性事务的哲学基础
BASE理论由Dan Pritchett于2008年提出，是对CAP理论中AP路线的实践总结。BASE是以下三个要素的缩写：
| 要素 | 全称 | 核心含义 | 与ACID对比 |
|---|---|---|---|
| BA | Basically Available | 基本可用：系统允许部分功能降级，但核心服务保持可用 | 弱化可用性要求 |
| S | Soft State | 软状态：系统状态可以在一段时间内不一致 | 放弃强一致性 |
| E | Eventually Consistent | 最终一致性：经过一段时间后，系统状态会收敛到一致 | 用时间换空间 |
BASE理论的核心思想是：放弃强一致性，允许系统在一段时间内处于不一致状态，但保证最终会达到一致。这种设计哲学直接催生了TCC、Saga、可靠消息等分布式事务方案。
BASE vs ACID 选择矩阵：
- 金融转账、库存扣减：优先ACID，使用XA或TCC强一致性方案。
- 社交点赞、日志收集：优先BASE，使用消息队列+异步补偿。
- 订单创建、支付流程：混合策略——核心链路用TCC保证原子性，非核心链路用消息保证最终一致性。
3.5 最终一致性：收敛模型与实现路径
最终一致性（Eventual Consistency）是BASE理论的核心承诺。它不是一个单一模型，而是一族收敛模型的统称。根据Werner Vogels的分类，最终一致性包含以下变体：
最终一致性的实现路径通常包含以下步骤：
- 异步复制：主节点写入后立即返回成功，通过后台线程将数据复制到从节点。
- 冲突检测：使用版本号、时间戳或向量时钟检测并发写入冲突。
- 冲突解决：采用最后写入者胜出（LWW）、CRDT或自定义合并策略解决冲突。
- 补偿机制：当检测到不一致时，通过补偿事务（如Saga的补偿步骤）回滚或修正。
- 幂等保证：所有补偿操作必须幂等，防止重复执行导致数据错误。
工程陷阱：最终一致性不等于“最终会自己变对”。如果没有正确的冲突检测和补偿机制，系统可能永远无法收敛。例如，两个节点同时扣减库存，如果没有分布式锁或乐观锁，最终库存可能变成负数。最终一致性需要显式的收敛逻辑，而不是放任不管。
3.6 概念关系总结
| 概念 | 核心主张 | 适用场景 | 典型技术 |
|---|---|---|---|
| ACID | 强一致性、强隔离性 | 金融、库存、账务 | XA、2PC、3PC |
| CAP | 三者不可兼得 | 分布式系统设计决策 | CP vs AP 权衡 |
| BASE | 基本可用、软状态、最终一致 | 高可用、大规模系统 | TCC、Saga、消息队列 |
| 最终一致性 | 状态随时间收敛 | 非实时一致性场景 | 异步复制、CRDT、补偿 |
课程衔接：本章的概念体系是后续所有接口契约设计的理论基础。第4章将基于这些概念，定义分布式事务画布的核心数据模型和Go接口原型。理解ACID的强约束与BASE的柔性妥协之间的张力，是设计出健壮分布式事务系统的前提。