2. 分布式事务概述：定义、理论与典型场景
在事件风暴画布中，当我们将一个业务流拆解为多个聚合、多个限界上下文时，原本在单体数据库内由本地事务保证的原子性、一致性、隔离性和持久性，就变成了跨库、跨服务、跨消息的分布式一致性问题。理解分布式事务的定义、核心理论以及典型场景，是后续在画布上定位故障和优化性能的前提。
2.1 分布式事务的定义
分布式事务是指参与事务的多个资源（数据库、消息队列、服务实例）分布在不同的网络节点上，但仍需保证这些操作要么全部成功提交，要么全部失败回滚的一种处理机制。与本地事务（ACID）不同，分布式事务面临网络延迟、节点宕机、数据分区等不确定性挑战。
| 对比维度 | 本地事务（单体） | 分布式事务（微服务/跨库） |
|---|---|---|
| 资源范围 | 单个数据库实例 | 多个数据库、服务、消息中间件 |
| 一致性模型 | 强一致性（ACID） | 最终一致性（BASE）或强一致性（2PC） |
| 回滚代价 | 低，数据库自动回滚 | 高，需补偿事务或Saga编排 |
| 故障类型 | SQL错误、死锁 | 网络分区、节点宕机、超时、幂等问题 |
2.2 CAP定理与BASE理论
CAP定理是分布式系统的基石，它指出一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）中的两项。BASE理论则是对CAP的实践妥协，强调基本可用（Basically Available）、软状态（Soft State）和最终一致性（Eventually Consistent）。
核心权衡： 在分布式事务设计中，网络分区（P）是必然发生的，因此我们必须在C（强一致性）和A（高可用）之间做出选择。选择CP（如ZooKeeper）还是AP（如Eureka），直接决定了事务协议的选择（2PC vs TCC vs Saga）。
2.3 分布式事务的典型场景
在事件风暴画布中，以下三种场景是分布式事务故障的高发区，也是性能瓶颈的常见来源。
2.3.1 跨库事务
当同一个微服务内的多个聚合需要操作不同的物理数据库（如订单库与库存库），且要求强一致性时，就会产生跨库分布式事务。典型方案包括：
- XA协议（2PC）： 通过全局事务协调器（TM）协调多个资源管理器（RM），实现两阶段提交。性能较差，锁持有时间长。
- AT模式（Seata）： 通过代理数据源自动生成反向SQL（UNDO_LOG），实现最终一致性，对业务代码侵入小。
故障排查提示： 跨库事务最常见的故障是“全局锁等待超时”和“二阶段回滚失败导致脏数据”。在事件风暴画布中，应明确标注每个聚合的数据库归属，避免画布上出现“隐式跨库”操作。
2.3.2 跨服务事务
跨服务事务发生在多个微服务之间，通常通过RPC（gRPC/Dubbo）或HTTP REST进行调用。典型模式包括：
- TCC（Try-Confirm-Cancel）： 业务层面实现两阶段，Try阶段预留资源，Confirm阶段执行，Cancel阶段回滚。对业务侵入大，但性能优于XA。
- Saga（编排/协同）： 将长事务拆分为多个本地事务，每个本地事务完成后发布事件或调用下一个服务；失败时执行补偿事务。适合长时间、高吞吐的场景。
| 模式 | 一致性强度 | 性能 | 业务侵入 | 典型故障 |
|---|---|---|---|---|
| TCC | 强一致性（准） | 中等 | 高（需实现Try/Confirm/Cancel） | 空回滚、幂等、悬挂 |
| Saga | 最终一致性 | 高（异步） | 低（只需实现正向/补偿） | 补偿丢失、事件乱序 |
| 2PC（XA） | 强一致性 | 低（锁资源） | 低（中间件支持） | 协调器单点、阻塞 |
2.3.3 跨消息事务
跨消息事务通常指“本地消息表”或“事务消息”模式，用于保证数据库操作与消息发送的原子性。典型场景是：订单服务写入订单表后，必须可靠地发送一条“订单已创建”消息到MQ，供库存/物流服务消费。
- 本地消息表： 在业务数据库中创建消息表，业务操作与消息插入在同一个本地事务中；后台定时任务扫描消息表并发送MQ，消费方确认后删除消息。
- 事务消息（RocketMQ）： 半消息机制：先发送半消息（对消费者不可见），执行本地事务，根据本地事务结果commit或rollback半消息。
性能优化提示： 跨消息事务的瓶颈通常在于“本地消息表轮询”的延迟和“事务消息”的回查次数。在事件风暴画布中，建议将消息发送与业务操作放在同一个聚合边界内，减少跨聚合的最终一致等待。