1. 分布式事务概述
在微服务与事件驱动架构中，跨服务的数据一致性是核心挑战。本章从理论基石出发，逐步收敛到 Outbox 模式在压测场景中的定位。
1.1 CAP 理论：分布式系统的“不可能三角”
CAP 理论由 Eric Brewer 于 2000 年提出，指出分布式系统在 一致性（Consistency）、可用性（Availability） 和 分区容错性（Partition Tolerance） 三者中最多同时满足两项。
| 属性 | 说明 | 典型取舍场景 |
|---|---|---|
| C — 一致性 | 所有节点在同一时刻看到相同数据 | 银行转账：必须强一致 |
| A — 可用性 | 每个请求都能获得非错误的响应 | 电商首页：不可用即流失用户 |
| P — 分区容错性 | 系统在网络分区时仍能正常运行 | 跨机房部署：分区是常态 |
压测启示： 在 Outbox + Kafka 方案中，我们优先保证 AP（可用性 + 分区容错性），通过异步重试与幂等消费实现最终一致性。压测时需重点观察分区恢复后的数据追赶行为。
1.2 BASE 理论与最终一致性
BASE 是对 CAP 中 AP 路线的实践总结，包含三个要素：
- Basically Available（基本可用） — 允许部分功能降级，核心链路保持响应。
- Soft State（软状态） — 允许数据中间状态存在，不要求实时一致。
- Eventually Consistent（最终一致性） — 经过一定时间窗口后，所有副本数据达成一致。
最终一致性是 Outbox 模式的理论依据：业务操作先写入本地数据库（Outbox 表），再由异步进程可靠投递到 Kafka，下游消费者最终看到完整事件流。
1.3 常见分布式事务方案对比
以下从一致性强度、性能、代码侵入性、压测关注点四个维度对比主流方案：
| 方案 | 一致性模型 | 性能 | 代码侵入性 | 压测关注点 |
|---|---|---|---|---|
| 2PC（两阶段提交） | 强一致 | 低（同步阻塞） | 高（需 XA 接口） | 协调者单点、锁超时 |
| TCC（Try-Confirm/Cancel） | 强一致 | 中 | 高（需实现三阶段接口） | 空回滚、幂等、悬挂 |
| Saga | 最终一致 | 高（异步补偿） | 中（需定义补偿逻辑） | 补偿链路耗时、逆向流程 |
| Outbox | 最终一致 | 高（本地事务 + 异步投递） | 低（仅需写 Outbox 表） | 轮询延迟、Kafka 积压、幂等消费 |
选型建议： 对于高吞吐、低延迟的压测场景，Outbox 模式在一致性与性能之间取得了最佳平衡。本课程后续所有压测用例均基于 Outbox + Kafka 构建。
1.4 Outbox 模式核心流程
下图展示了 Outbox 模式在分布式事务中的完整数据流：
1.5 从理论到压测：一致性模型的选择
在压测场景库设计中，不同一致性模型对应不同的故障注入策略：
- 强一致场景（2PC/TCC）：压测重点在协调者崩溃恢复、锁超时、全局回滚耗时。
- 最终一致场景（Saga/Outbox）：压测重点在异步补偿正确性、消息可靠性、数据对账。
常见误区： 很多团队在压测 Outbox 时只关注 Kafka 吞吐，忽略了 Outbox 表本身的轮询压力。当业务写入 TPS 超过轮询进程的处理能力时，Outbox 表会持续膨胀，导致数据库 IO 飙升和投递延迟剧增。这是本课程压测场景库第一个要覆盖的边界条件。