4. 两阶段提交协议（2PC）：工作原理与画布边界标记
两阶段提交协议（Two-Phase Commit, 2PC）是分布式事务中最经典的原子提交协议。在事件风暴画布中，2PC 通常用于标记那些需要强一致性、不允许部分失败的聚合边界。本节将深入剖析 2PC 的工作原理、角色划分，并展示如何在画布上精确标记 2PC 边界。
4.1 2PC 的核心角色与职责
2PC 协议涉及两类核心角色：协调者（Coordinator）和参与者（Participant）。在事件风暴画布中，协调者通常对应一个聚合（Aggregate）或领域服务（Domain Service），而参与者对应多个需要保持事务一致性的聚合或外部系统。
| 角色 | 职责 | 画布中的典型映射 | 关键行为 |
|---|---|---|---|
| 协调者 | 主导整个事务流程，收集参与者投票，决定最终提交或中止 | 流程管理器、Saga 编排器、订单聚合 | 发送准备请求、收集响应、广播提交/回滚 |
| 参与者 | 执行本地事务，向协调者报告准备结果，并等待最终指令 | 库存聚合、账户聚合、支付网关 | 执行本地操作、锁定资源、响应准备、执行提交/回滚 |
画布实践提示：在事件风暴画布中，建议使用紫色（#9b59b6）的便利贴标记协调者角色，使用蓝色（#3498db）标记参与者角色。这种颜色编码有助于在复杂画布中快速识别事务边界。
4.2 两阶段提交的工作流程
2PC 将一次分布式事务拆分为两个阶段：准备阶段（Voting Phase）和提交阶段（Commit Phase）。每个阶段都有明确的状态转换和消息交互。
4.2.1 准备阶段（Phase 1: 投票）
- 协调者向所有参与者发送
PREPARE请求，询问它们是否可以提交事务。 - 每个参与者执行本地事务（但不提交），并将事务日志写入磁盘（确保可恢复性）。
- 参与者根据执行结果返回
YES（准备成功）或NO（准备失败）。 - 协调者等待所有参与者的响应，或等待超时。
4.2.2 提交阶段（Phase 2: 决策与执行）
- 协调者根据准备阶段的投票结果做出决策：
- 如果所有参与者都返回
YES，则决定提交（COMMIT）。 - 如果任何参与者返回
NO或超时，则决定中止（ABORT）。
- 如果所有参与者都返回
- 协调者将决策写入本地日志，然后向所有参与者广播最终指令。
- 每个参与者收到指令后，执行
COMMIT或ROLLBACK操作，并释放资源锁。 - 参与者向协调者发送确认（ACK），完成事务。
关键指标：2PC 的阻塞时间主要发生在准备阶段——参与者在投票后必须持有资源锁，直到收到协调者的最终指令。这个窗口期越长，系统并发能力下降越明显。
4.3 2PC 状态机与消息序列
下面的 SVG 图展示了 2PC 协议在正常提交场景下的完整消息序列与状态转换。图中清晰区分了协调者与参与者的角色边界，以及两个阶段之间的决策点。
4.4 在事件风暴画布中标记 2PC 边界
在事件风暴画布上，2PC 边界通常表现为一个封闭的虚线框，将协调者和所有参与者聚合在一起。这个边界框代表了事务的原子性范围——框内的所有操作要么全部成功，要么全部回滚。
4.4.1 边界标记规则
- 使用红色虚线框（#e74c3c）绘制 2PC 事务边界，与普通聚合边界（蓝色实线）形成视觉对比。
- 在边界框的左上角标注
「2PC 事务边界」标签，并注明事务 ID 或名称。 - 在边界框的右下角标注
「协调者：XXX」，明确事务的主导角色。 - 边界框必须完整包含所有参与者的聚合节点，不能有节点悬在框外。
4.4.2 画布标记示例
下面的 SVG 图展示了一个典型的电商下单场景中，如何在事件风暴画布上标记 2PC 事务边界。该事务包含订单聚合（协调者）、库存聚合和账户聚合（参与者）。
4.5 2PC 的局限性与画布中的避坑指南
| 局限性 | 问题描述 | 画布标记建议 |
|---|---|---|
| 同步阻塞 | 参与者在准备阶段锁定资源，直到提交阶段结束才释放。长事务会严重降低并发。 | 在边界框内标注 「锁定资源列表」，提醒团队评估锁粒度。 |
| 单点故障 | 协调者宕机会导致参与者长时间阻塞，无法自行决定提交或回滚。 | 在协调者节点旁添加 「HA/故障转移」 标签，提示需要高可用设计。 |
| 数据不一致窗口 | 在提交阶段，部分参与者收到 COMMIT 后宕机，会导致数据不一致。 | 在边界框底部添加 「补偿机制」 提示块，建议设计回滚预案。 |
| 网络分区 | 协调者与参与者之间的网络中断，可能导致事务长时间悬而未决。 | 在画布上使用 「超时阈值：X 秒」 标注，明确超时后的处理策略。 |
架构决策警告：2PC 并不适合所有分布式场景。在事件风暴画布中，如果发现 2PC 边界框内包含超过 5 个参与者，或者事务执行时间超过 2 秒，强烈建议重新评估是否应该改用 Saga 或 TCC（Try-Confirm/Cancel）模式。2PC 的强一致性是以牺牲可用性和性能为代价的。
4.6 2PC 与事件风暴的融合实践
在事件风暴工作坊中，标记 2PC 边界的最佳时机是在「设计风暴（Design Storm）」阶段。此时，团队已经通过「流程风暴」识别出关键的业务流程和聚合，接下来需要确定哪些流程需要强一致性保障。
推荐步骤：
- 在画布上用红色虚线框圈出需要强一致性的聚合组。
- 在框内用紫色便利贴标记协调者，用蓝色便利贴标记参与者。
- 在协调者与参与者之间绘制箭头，标注消息类型（PREPARE / COMMIT / ROLLBACK）。
- 在边界框外部，用黄色便利贴记录可能出现的异常场景（如协调者宕机、参与者超时）。
- 为每个 2PC 边界框分配一个唯一的事务 ID，便于后续的代码生成和测试用例编写。
通过这种可视化的边界标记，整个团队可以直观地看到系统的一致性保障范围，并在架构评审时快速识别出潜在的性能瓶颈和风险点。