3、事务边界定义：本地事务、分布式事务、Saga模式、TCC模式的基本概念与适用场景
在API设计治理中，事务边界是决定数据一致性与系统可用性的核心决策点。不同的事务模型对应不同的错误处理策略与回滚能力。本章从本地事务出发，逐步深入到分布式事务的四种主流模式，明确每种模式的基本概念、适用场景及其在API治理中的事务边界定义。
3.1 本地事务
本地事务（Local Transaction）指在单个数据库实例内完成的事务操作，遵循ACID原则。它是事务边界最窄、性能最高、错误处理最简单的模型。
| 特性 | 说明 |
|---|---|
| 原子性 | 事务内的所有操作要么全部成功，要么全部回滚 |
| 一致性 | 事务前后数据状态保持一致 |
| 隔离性 | 事务之间互不干扰，通过锁机制实现 |
| 持久性 | 提交后数据永久保存 |
适用场景：
- 单体应用中的单库操作
- API网关内部的状态变更（如用户注册、密码修改）
- 微服务内部不涉及跨服务调用的数据更新
API治理要点： 本地事务的边界与API端点一一对应。当API请求进入服务端时，事务在服务层开启，在响应返回前提交或回滚。错误处理只需捕获数据库异常并返回HTTP 500或409状态码。
3.2 分布式事务
分布式事务（Distributed Transaction）涉及多个独立数据库或服务节点，需要协调所有参与者达成最终一致。经典的分布式事务协议包括两阶段提交（2PC）和三阶段提交（3PC）。
两阶段提交（2PC）流程：
- 准备阶段（Vote Phase）： 协调者向所有参与者发送准备请求，参与者执行事务但不提交，返回同意或中止。
- 提交阶段（Commit Phase）： 若所有参与者都同意，协调者发送提交指令；否则发送回滚指令。
关键缺陷： 2PC存在同步阻塞问题，协调者单点故障会导致参与者长时间锁定资源。在微服务API架构中，2PC会显著降低系统吞吐量，因此较少直接用于高并发API场景。
适用场景：
- 对强一致性要求极高的金融核心交易（如跨行转账）
- 数据库资源在同一网络域内且延迟可控
- 参与者数量少（通常不超过5个）
3.3 Saga模式
Saga模式是一种长事务解决方案，将一个分布式事务拆分为多个本地事务，每个本地事务都有对应的补偿操作（Compensating Action）。Saga不要求所有参与者同时提交，而是通过异步编排实现最终一致性。
适用场景：
- 跨多个微服务的业务流程（如电商下单、旅行预订）
- 允许短暂数据不一致但最终一致的业务
- 参与者数量多且每个参与者都有明确的补偿逻辑
API治理建议： Saga模式中每个本地事务对应一个API端点。补偿操作应设计为幂等接口，确保重试不会产生副作用。建议在API响应中增加事务ID（SagaId），便于追踪整个流程。
3.4 TCC模式
TCC（Try-Confirm-Cancel）模式是一种补偿型分布式事务方案，将每个服务操作拆分为三个阶段：预留资源（Try）、确认执行（Confirm）、取消回滚（Cancel）。TCC要求业务逻辑本身支持资源预留，而非依赖数据库锁。
| 阶段 | 操作 | 错误处理 |
|---|---|---|
| Try | 预留业务资源（如冻结库存、锁定账户金额） | Try失败则整体回滚，不执行Confirm |
| Confirm | 确认执行，将预留资源转为实际占用 | Confirm失败需重试，直到成功 |
| Cancel | 释放预留资源，回滚Try阶段的操作 | Cancel失败需重试，直到成功 |
适用场景：
- 对一致性要求较高且业务支持资源预留的场景（如库存预占、账户冻结）
- 短事务场景，Try阶段耗时可控
- 需要避免数据库锁竞争的高并发系统
API治理陷阱： TCC模式对业务侵入性强，需要为每个资源操作设计Try/Confirm/Cancel三个接口。Cancel接口必须能够处理Try阶段的各种边界情况，包括Try成功但Confirm超时、Try部分成功等。建议在API规范中强制要求所有TCC接口返回幂等键（Idempotency-Key）。
3.5 四种事务模式对比
| 维度 | 本地事务 | 分布式事务（2PC） | Saga模式 | TCC模式 |
|---|---|---|---|---|
| 一致性模型 | 强一致性 | 强一致性 | 最终一致性 | 最终一致性 |
| 资源锁定 | 数据库锁 | 全局锁 | 无锁 | 业务预留 |
| 性能影响 | 低 | 高（阻塞） | 中 | 中 |
| 业务侵入性 | 低 | 低 | 中（需补偿逻辑） | 高（三阶段接口） |
| 错误恢复 | 自动回滚 | 自动回滚 | 手动/自动补偿 | 自动Cancel |
| API治理复杂度 | 低 | 高 | 中 | 高 |
3.6 事务边界选择决策树
在API设计治理中，选择事务边界模型可参考以下决策路径：
- 是否只涉及一个数据库？ → 是：使用本地事务；否：进入下一步。
- 是否要求强一致性？ → 是：考虑2PC（参与者少且网络可靠）；否：进入下一步。
- 业务是否支持资源预留？ → 是：优先选择TCC模式；否：选择Saga模式。
- 补偿逻辑是否容易定义？ → 是：Saga模式；否：重新评估业务拆分或考虑异步最终一致性方案。
核心原则： 事务边界越窄，错误处理越简单。在API治理中，应优先尝试将分布式事务拆解为多个本地事务，通过异步消息和补偿机制实现最终一致性。仅在无法拆解且对一致性有硬性要求时，才引入2PC或TCC模式。