3. 分布式事务理论：CAP定理、BASE理论、最终一致性
在构建分布式系统时，事务的ACID（原子性、一致性、隔离性、持久性）特性无法在跨网络、跨节点的环境中完美实现。分布式事务理论的核心在于权衡——在可用性、一致性与分区容错性之间做出符合业务场景的选择。本章将深入剖析CAP定理、BASE理论以及最终一致性模型，为后续的事件风暴画布设计奠定理论基础。
3.1 CAP定理：分布式系统的“不可能三角”
CAP定理由Eric Brewer教授于2000年提出，它指出一个分布式系统最多只能同时满足以下三个特性中的两个：
| 特性 | 全称 | 核心含义 | 类比说明 |
|---|---|---|---|
| C | Consistency（一致性） | 所有节点在同一时刻看到的数据完全相同。写操作完成后，任何后续读操作都能读到最新的写入值。 | 银行账户余额：转账后，所有ATM机查询结果必须一致。 |
| A | Availability（可用性） | 每个请求都能在合理时间内获得非错误的响应，但不保证响应包含最新数据。 | 搜索引擎：即使索引未完全同步，用户也能收到搜索结果。 |
| P | Partition Tolerance（分区容错性） | 系统在网络分区（节点间通信中断）时仍能正常运行。 | 跨机房部署：即使光纤被挖断，系统仍能对外提供服务。 |
关键认知： 在分布式系统中，网络分区是必然发生的，因此P（分区容错性）是必须选择的。实际决策是在CP（强一致+分区容忍）与AP（高可用+分区容忍）之间做取舍。
下图展示了CAP定理的“三选二”决策模型，以及不同组合对应的典型系统类型：
3.2 BASE理论：对CAP的务实妥协
BASE理论由eBay的架构师Dan Pritchett提出，是对CAP中AP（高可用+分区容忍）路线的实践总结。它放弃了强一致性，转而追求基本可用和最终一致性。
- BA（Basically Available）基本可用：系统允许出现部分功能降级，但核心功能始终可用。例如：电商大促时，允许“查看历史订单”功能延迟加载，但“下单”功能必须正常。
- S（Soft State）软状态：允许系统在不同节点间存在数据不一致的中间状态，这种状态是暂时的、可接受的。
- E（Eventually Consistent）最终一致性：在没有新写入操作的情况下，经过一段时间的异步同步，所有副本最终会达到一致状态。
实践启示： 在事件风暴画布设计中，BASE理论指导我们：
1. 使用事件溯源（Event Sourcing）记录所有状态变更，而非直接更新数据库。
2. 通过异步事件驱动（Event-Driven）实现服务间解耦，允许短暂的不一致窗口。
3. 设计补偿事务（Saga模式）来处理最终一致性失败时的回滚逻辑。
1. 使用事件溯源（Event Sourcing）记录所有状态变更，而非直接更新数据库。
2. 通过异步事件驱动（Event-Driven）实现服务间解耦，允许短暂的不一致窗口。
3. 设计补偿事务（Saga模式）来处理最终一致性失败时的回滚逻辑。
3.3 最终一致性：从理论到工程实现
最终一致性是BASE理论的核心，也是分布式事务在工程落地中最常用的模型。它不保证数据在写入后立即对所有节点可见，但保证在没有新写入的前提下，所有副本最终会收敛到相同的值。
根据一致性保证的强弱，最终一致性可细分为以下级别：
| 一致性级别 | 描述 | 典型场景 | 延迟窗口 |
|---|---|---|---|
| 因果一致性 | 如果进程A通知进程B它已更新数据，则B的后续读操作一定能看到A的更新。无因果关系的并发写入可被不同顺序看到。 | 社交评论：用户先发帖，好友才能看到该帖下的评论。 | 毫秒级 |
| 读己之写一致性 | 用户总能读到自己的写入。其他用户的写入可能延迟可见。 | 用户修改个人资料后刷新页面，立即看到更新。 | 秒级 |
| 会话一致性 | 在同一个会话（Session）内，保证读己之写一致性。跨会话时可能读到旧数据。 | Web应用：用户登录后的操作在本次会话内一致。 | 会话生命周期 |
| 单调读一致性 | 如果用户读到某个值，后续读操作不会读到更旧的值。 | 新闻推送：用户看到一条新闻后，刷新页面不会看到该新闻消失。 | 分钟级 |
| 单调写一致性 | 系统保证来自同一用户的写操作按顺序执行。 | 订单状态流转：必须先“已支付”才能“已发货”。 | 严格顺序 |
下图展示了最终一致性的典型工作流程——通过异步事件总线实现跨服务的数据同步：
3.4 理论在事件风暴画布中的映射
在后续的事件风暴画布设计中，我们将基于以下理论映射来指导架构决策：
- 识别核心聚合（Aggregate）：每个聚合内部保证强一致性（ACID），聚合之间通过事件实现最终一致性（BASE）。
- 定义事件边界：跨聚合的状态变更必须通过领域事件（Domain Event）异步传播，事件本身是不可变的、可追溯的。
- 选择一致性模型：对于资金类、库存扣减等关键路径，采用“读己之写”或“因果一致性”；对于非关键路径（如日志、统计），采用宽松的最终一致性。
- 设计补偿策略：在事件风暴画布中，每个可能失败的异步事件都需要标注对应的补偿事件（Compensation Event），形成完整的Saga流程。
常见误区：
1. 不要试图在分布式系统中实现全局强一致性——这会导致可用性急剧下降，甚至系统不可用。
2. 不要忽略“不一致窗口”对业务的影响——必须与产品团队明确约定：用户在多长时间内可能看到旧数据，以及如何处理边界情况。
3. 不要认为最终一致性等于“最终不管”——必须设计监控、告警和自动补偿机制，确保不一致窗口不会无限延长。
1. 不要试图在分布式系统中实现全局强一致性——这会导致可用性急剧下降，甚至系统不可用。
2. 不要忽略“不一致窗口”对业务的影响——必须与产品团队明确约定：用户在多长时间内可能看到旧数据，以及如何处理边界情况。
3. 不要认为最终一致性等于“最终不管”——必须设计监控、告警和自动补偿机制，确保不一致窗口不会无限延长。