3. 分布式事务基础理论：ACID与BASE理论、CAP定理、两阶段提交(2PC)、三阶段提交(3PC)、TCC模式
在深入 Kafka 吞吐量压测之前，必须理解分布式事务的理论基石。这些理论决定了我们在压测场景中如何设计事务边界、选择一致性模型以及评估性能损耗。本章将系统梳理从传统单体事务到分布式柔性事务的演进路径。
3.1 ACID 与 BASE 理论
ACID 是传统关系型数据库事务的黄金标准，而 BASE 则是分布式系统为了可用性和性能而做出的权衡。两者并非对立，而是不同场景下的设计哲学。
| 特性 | ACID（强一致性） | BASE（最终一致性） |
|---|---|---|
| 原子性 (Atomicity) | 事务要么全部成功，要么全部回滚 | 基本可用 (Basically Available)：系统允许部分失败 |
| 一致性 (Consistency) | 事务前后数据完整约束不变 | 软状态 (Soft State)：允许中间状态存在 |
| 隔离性 (Isolation) | 并发事务互不干扰 | 最终一致性 (Eventually Consistent)：经过一段时间后数据达成一致 |
| 持久性 (Durability) | 提交后数据永久保存 | 基本持久，允许丢失少量数据以换取性能 |
压测启示： 在 Kafka 分布式事务压测中，ACID 模型通常对应精确一次语义（EOS），而 BASE 模型对应至少一次语义。选择 BASE 可以显著提升吞吐量，但需要业务层容忍重复或延迟。
3.2 CAP 定理
CAP 定理是分布式系统的核心约束：一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）三者最多只能同时满足两个。在分布式事务场景中，网络分区是必然发生的，因此我们必须在 C 和 A 之间做出选择。
Kafka 中的 CAP 选择： Kafka 默认是 CP 系统（强一致性保证），通过 ISR 机制和 acks=all 实现。但在高吞吐压测场景中，可以调整为 AP 模式（acks=1 或 0），牺牲一致性换取更高的吞吐量。
3.3 两阶段提交（2PC）
2PC 是分布式事务的经典实现，分为准备阶段和提交阶段。它保证了 ACID 中的原子性，但存在同步阻塞和协调者单点问题，在高并发压测中容易成为性能瓶颈。
压测风险点： 2PC 在准备阶段会持有数据库锁或 Kafka 事务锁，压测时如果事务规模过大或协调者宕机，会导致大量连接超时和死锁。建议在压测场景中设置事务超时阈值，并监控协调者 CPU 和连接数。
3.4 三阶段提交（3PC）
3PC 是对 2PC 的改进，引入超时机制和预提交阶段，减少阻塞时间。但 3PC 仍然无法完全解决网络分区下的数据一致性问题，且实现复杂度更高。
| 阶段 | 动作 | 超时处理 | 与 2PC 区别 |
|---|---|---|---|
| CanCommit | 协调者询问参与者是否可以提交 | 参与者超时自动中止 | 新增阶段，提前发现不可用节点 |
| PreCommit | 参与者执行预操作，写入 undo/redo 日志 | 参与者超时自动提交（乐观策略） | 替代 2PC 的准备阶段，减少阻塞 |
| DoCommit | 协调者发送最终提交或中止指令 | 参与者超时自动提交 | 引入超时后自动提交，避免无限阻塞 |
压测对比： 3PC 在网络抖动场景下比 2PC 更稳定，但多一次网络交互（CanCommit）会增加延迟。在 Kafka 事务压测中，3PC 的吞吐量通常比 2PC 低 10%-20%，但事务成功率更高。
3.5 TCC 模式
TCC（Try-Confirm-Cancel）是分布式事务的补偿型实现，属于 BASE 理论的典型应用。它将事务拆分为三个阶段，通过业务补偿来达到最终一致性，避免了 2PC 的资源锁定问题。
3.6 四种模式对比与压测选型
| 模式 | 一致性模型 | 资源锁定 | 吞吐量影响 | 适用压测场景 |
|---|---|---|---|---|
| 2PC | 强一致性 | 是（行锁/表锁） | 高（阻塞严重） | 金融核心、对账系统 |
| 3PC | 强一致性（有超时） | 部分（预提交阶段） | 中高（多一次网络交互） | 跨机房、高可用场景 |
| TCC | 最终一致性 | 否（状态标记） | 低（无锁、异步） | 高并发、高吞吐压测 |
| BASE + 消息表 | 最终一致性 | 否 | 极低（异步消息） | 日志、通知、非实时场景 |
Kafka 压测推荐： 在 Kafka 分布式事务压测场景库中，TCC 模式是最佳选择。它避免了 2PC 的锁竞争，同时通过幂等设计保证了最终一致性。配合 Kafka 的事务 API（producer.initTransactions()），可以实现高吞吐的分布式事务处理。
3.7 本章小结
- ACID vs BASE：强一致性 vs 最终一致性，压测中根据业务容忍度选择。
- CAP 定理：网络分区下必须在 C 和 A 之间权衡，Kafka 默认 CP，可调整为 AP。
- 2PC：经典但阻塞严重，适合低并发、高一致性场景。
- 3PC：改进版，减少阻塞但增加延迟，适合跨网络场景。
- TCC：无锁、高并发友好，是 Kafka 事务压测的首选模式。