4. 分布式事务核心概念：ACID、CAP、BASE 理论回顾
在深入事件风暴与分布式事务选型之前，必须重新校准三个基础理论坐标系。ACID 定义了单机强一致性的黄金标准；CAP 揭示了分布式系统下一致性、可用性与分区容忍性的不可能三角；BASE 则提供了面向大规模系统的柔性妥协方案。这三者构成了分布式事务架构师进行技术决策的底层逻辑。
4.1 ACID：单机事务的黄金标准
ACID 是数据库事务正确执行的四个基本要素，由 IBM 在 20 世纪 70 年代提出，至今仍是衡量事务可靠性的基准。
| 属性 | 全称 | 核心含义 | 违反后果 |
|---|---|---|---|
| A | 原子性 (Atomicity) | 事务中的所有操作要么全部成功，要么全部回滚 | 部分更新导致数据不一致 |
| C | 一致性 (Consistency) | 事务执行前后，数据库完整性约束不被破坏 | 脏读、幻读、违反业务规则 |
| I | 隔离性 (Isolation) | 并发执行的事务之间互不干扰 | 丢失更新、脏写、不可重复读 |
| D | 持久性 (Durability) | 已提交的事务结果永久保存 | 系统崩溃后数据丢失 |
架构师视角： ACID 是分布式事务的“理想参照系”。在分布式环境中，我们无法完全实现 ACID，但可以通过补偿、重试、幂等设计来“模拟”其效果。例如，Saga 模式通过一系列本地事务 + 补偿操作来保证最终一致性，本质上是对原子性的妥协实现。
4.2 CAP 定理：分布式系统的“不可能三角”
2000 年，Eric Brewer 提出 CAP 猜想，2002 年被证明为定理。它指出：在分布式系统中，一致性 (Consistency)、可用性 (Availability)、分区容忍性 (Partition Tolerance) 三者最多只能同时满足两个。
- C (Consistency - 一致性)：所有节点在同一时刻看到相同的数据。写操作完成后，任何后续读操作都能读到最新值。
- A (Availability - 可用性)：每个请求都能获得一个（非错误的）响应，但不保证响应包含最新数据。
- P (Partition Tolerance - 分区容忍性)：系统中任意节点间出现网络分区（消息丢失或延迟）时，系统仍能继续运行。
由于网络分区在分布式系统中是必然发生的，因此 P 是必选项。实际架构决策是在 CP 与 AP 之间做选择。
选型启示： 在事件风暴中，当识别出“强一致性”业务规则（如账户扣款不能超支）时，应优先考虑 CP 系统（如 ZooKeeper、etcd 或 XA 协议）；当业务容忍短暂不一致但要求高可用（如用户点赞数）时，应选择 AP 系统（如 Cassandra、DynamoDB 或异步事件驱动架构）。
4.3 BASE 理论：大规模系统的柔性基石
BASE 理论由 eBay 架构师 Dan Pritchett 提出，是对 CAP 中 AP 路线的实践总结。它放弃了强一致性，追求最终一致性，是分布式事务设计的重要指导思想。
| 要素 | 全称 | 核心含义 | 与 ACID 对比 |
|---|---|---|---|
| BA | Basically Available (基本可用) | 系统允许出现降级，但核心功能可用 | 弱化 A，允许部分不可用 |
| S | Soft State (软状态) | 允许系统状态在一段时间内不一致 | 弱化 C，允许中间状态 |
| E | Eventually Consistent (最终一致) | 经过一段时间后，所有副本数据最终达到一致 | 弱化 C，但保证最终收敛 |
4.4 从 ACID 到 BASE：分布式事务的演进路径
下图展示了分布式事务从强一致到最终一致的演进路径，以及各阶段对应的典型技术方案。
4.5 三理论在事件风暴中的映射关系
在事件风暴工作坊中，这三个理论直接指导我们如何对“领域事件”进行分类和事务边界划分：
- ACID 映射：当领域事件之间存在严格的因果依赖（如“订单已创建”必须发生在“支付已成功”之前），且业务要求强一致时，应将这些事件放在同一个聚合（Aggregate）内，使用本地事务保证 ACID。
- CAP 映射：当识别出跨聚合或跨限界上下文的领域事件时，必须做出 CP 或 AP 的选择。例如，“库存已扣减”与“订单已确认”分属不同服务，若选择 CP，则使用分布式锁或 XA；若选择 AP，则使用 Saga 或事件驱动。
- BASE 映射：在事件风暴的“热点区域”（Hot Spot），即业务规则复杂、需要补偿逻辑的地方，BASE 理论指导我们设计“补偿事件”（如“库存扣减失败已回滚”）和“幂等事件处理器”，确保最终一致性。
常见误区： 不要试图在分布式系统中实现完全的 ACID。许多架构师在事件风暴中识别出“强一致性需求”后，盲目引入分布式事务协调器（如 Seata AT），导致系统可用性急剧下降。正确的做法是：先尝试通过聚合设计将强一致需求限制在单机事务内；如果必须跨服务，再根据业务容忍度选择 Saga（AP）或 TCC（CP）。
4.6 核心概念速查表
| 理论 | 核心主张 | 适用场景 | 典型技术 | 事件风暴中的角色 |
|---|---|---|---|---|
| ACID | 强一致、可回滚、持久化 | 单机事务、金融核心、库存扣减 | MySQL InnoDB、XA、2PC | 定义聚合边界和本地事务 |
| CAP | CP 或 AP 二选一 | 分布式协调、配置中心、注册中心 | ZooKeeper (CP)、Eureka (AP) | 决定跨服务事务的选型方向 |
| BASE | 基本可用、软状态、最终一致 | 大规模互联网、社交、日志、推荐 | Kafka、Saga、CQRS、Event Sourcing | 设计补偿事件和幂等处理器 |