4. 分布式事务基础：ACID、CAP、BASE 与分布式事务的挑战
聊 Exactly Once 语义，绕不开分布式事务。很多同学一听到「分布式事务」就头大，觉得理论太多、落地太难。我刚开始接触这块时也踩过不少坑，今天咱们就把这几个基础理论掰开揉碎，看看它们到底在说什么，以及跟 Exactly Once 有什么关系。
一句话总结：ACID 是单机事务的黄金标准，CAP 是分布式系统的残酷现实，BASE 是我们在现实中的妥协方案。理解这三者的关系，是理解 Exactly Once 的前提。
4.1 ACID 理论：单机事务的基石
ACID 是数据库事务的四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。说白了，就是保证一个事务要么全做，要么全不做，而且做完之后数据是靠谱的。
| 特性 | 含义 | 我见过的坑 |
|---|---|---|
| 原子性 | 事务中的所有操作，要么全部成功，要么全部回滚 | 曾经有个同事在事务里混用了多个数据源，结果部分成功部分失败，数据对不上了 |
| 一致性 | 事务执行前后，数据必须满足所有约束 | 很多人把一致性和 CAP 的 C 搞混，其实完全两码事 |
| 隔离性 | 并发事务之间互不干扰 | 默认的读已提交隔离级别，在高并发下经常出现幻读 |
| 持久性 | 事务一旦提交，数据永久保存 | 磁盘坏了就没办法了，所以得靠副本 |
在单机数据库里，ACID 靠锁、日志、回滚段这些机制实现。但到了分布式环境，事情就变了——你没法用一个全局的锁来控制所有节点。
我的经验：ACID 在单机环境下很完美，但别试图在分布式系统中完全复刻它。成本太高，性能太差。我见过有人硬要在跨库事务上实现 Serializable 隔离级别，结果系统吞吐量直接掉了两个数量级。
4.2 CAP 理论：分布式系统的不可能三角
CAP 理论是分布式系统的「紧箍咒」。它说：一个分布式系统，最多只能同时满足一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）中的两个。
为什么会这样？你想想看，当网络出现分区时，节点之间没法通信了。这时候你面临一个选择：
- 选 C（一致性）： 拒绝服务，等网络恢复后再响应。用户会看到超时或错误。
- 选 A（可用性）： 继续服务，但不同节点可能返回不同数据。用户看到的数据可能不一致。
说白了，P 是必选的——因为网络分区一定会发生。所以实际的选择是在 CP 和 AP 之间做取舍。
| 组合 | 典型系统 | 适用场景 |
|---|---|---|
| CP | ZooKeeper、etcd | 配置中心、分布式锁，宁可不可用也不能数据错 |
| AP | Eureka、Cassandra | 服务发现、日志收集，宁可数据有点偏差也不能挂 |
注意：CAP 里的 C 是「线性一致性」，跟 ACID 的 C 完全不是一回事。ACID 的 C 是业务约束，CAP 的 C 是数据副本之间的实时一致。我见过不少面试者把这两个 C 混为一谈，结果被面试官问住了。
4.3 BASE 理论：向现实妥协的智慧
BASE 是 Basically Available（基本可用）、Soft State（软状态）、Eventually Consistent（最终一致性）的缩写。它是对 CAP 中 AP 路线的实践总结。
- 基本可用： 系统允许出现部分功能降级，比如双十一时把非核心功能关掉。
- 软状态： 数据副本之间可以暂时不一致，允许中间状态存在。
- 最终一致性： 经过一段时间后，所有副本最终会达成一致。
我个人习惯把 BASE 理解为「有底线的妥协」。你不需要实时一致，但必须保证最终能对上账。很多消息中间件（包括 Kafka、Pulsar）的 Exactly Once 语义，本质上就是 BASE 思想的体现——先保证消息不丢，再通过幂等和事务机制保证最终一致。
核心观点：Exactly Once 不是 ACID 那种强一致，而是 BASE 框架下的最终一致。它允许中间状态存在，但通过重试、幂等、事务日志等手段，保证最终结果正确。
4.4 分布式事务的四大挑战
了解了理论，咱们来看看实际落地时遇到的难题。我在项目中总结出四个核心挑战：
- 网络不可靠： 消息可能延迟、丢失、乱序。你发一个提交请求，对方可能没收到，或者收到了但响应丢了。
- 节点故障： 任何一个节点都可能随时宕机。事务进行到一半，协调者挂了怎么办？参与者挂了怎么办？
- 时钟不同步： 不同机器的系统时间不一致，导致超时判断、顺序判定都出问题。我遇到过因为时钟偏差导致事务超时误判的案例，排查了两天才找到原因。
- 状态不一致： 部分节点提交了，部分节点回滚了，数据就分裂了。这是分布式事务最头疼的问题，也是 Exactly Once 要解决的核心。
避坑指南：我曾经在一个跨机房部署的项目中，因为忽略了网络延迟的波动，导致两阶段提交频繁超时。后来改用 Saga 模式 + 补偿事务，才把问题解决。记住：分布式事务没有银弹，选型要看业务场景。
4.5 知识体系总览
下面这张图把本章的核心概念串起来了。你可以看到 ACID、CAP、BASE 之间的关系，以及它们如何影响分布式事务的设计。
4.6 小结
这一章我们聊了三个理论和四个挑战。ACID 是理想，CAP 是现实，BASE 是出路。分布式事务的挑战说白了就是：在不可靠的网络和节点上，如何保证数据最终一致。
这些理论不是纸上谈兵。后面讲 Exactly Once 的实现时，你会发现每一步都在跟这些挑战打交道——幂等性解决重复问题，事务日志解决状态不一致，协调者选主解决节点故障。嗯，打好这个基础，后面的路就好走了。