1、事务边界基础：定义事务边界、ACID原则回顾、本地事务与分布式事务的区别
1.1 事务边界的定义
事务边界（Transaction Boundary）是分布式系统与数据库交互中最基础的概念之一。它定义了一组操作被视为一个逻辑工作单元的起始与结束范围。在 API 开发中，事务边界决定了哪些数据库操作要么全部成功提交，要么全部回滚撤销。
核心要点：事务边界是保证数据一致性的最小隔离单元。边界划分过粗会导致锁竞争激烈、性能下降；边界划分过细则可能破坏业务原子性，产生数据不一致。
事务边界通常由以下三个关键操作界定：
- Begin（开始）：标记事务的起点，系统记录当前数据快照或分配事务ID。
- Commit（提交）：确认事务内的所有操作成功，将变更持久化到存储。
- Rollback（回滚）：撤销事务内所有已执行的操作，恢复到事务开始前的状态。
1.2 ACID原则回顾
事务的可靠性建立在 ACID 四大原则之上。理解 ACID 是正确划分事务边界的前提。
| 原则 | 全称 | 含义 | 违反后果 |
|---|---|---|---|
| 原子性 | Atomicity | 事务中的所有操作要么全部成功，要么全部失败回滚 | 部分更新导致数据残缺 |
| 一致性 | Consistency | 事务执行前后，数据必须满足所有预定义的约束规则 | 数据违反业务规则（如余额为负） |
| 隔离性 | Isolation | 并发执行的事务之间互不干扰，每个事务都感觉自己是唯一运行的 | 脏读、不可重复读、幻读 |
| 持久性 | Durability | 一旦事务提交，其结果就是永久的，即使系统崩溃也不会丢失 | 提交后数据丢失 |
实践提示：在 API 开发中，原子性和一致性是事务边界划分最常被挑战的两个原则。微服务架构下，跨服务调用天然破坏原子性，需要引入补偿事务（Saga）等模式来弥补。
1.3 本地事务与分布式事务的区别
根据事务边界跨越的资源范围，事务分为本地事务和分布式事务。两者的核心差异在于是否涉及多个独立的数据资源或服务节点。
本地事务（Local Transaction）
本地事务作用于单一数据库或单一资源管理器内。它由数据库自身的事务管理器直接控制，通常通过 BEGIN TRANSACTION、COMMIT、ROLLBACK 语句实现。本地事务完全依赖数据库的 ACID 能力，性能高、实现简单。
-- 本地事务示例：银行转账（单库操作）
BEGIN TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE account_id = 'A';
UPDATE accounts SET balance = balance + 100 WHERE account_id = 'B';
COMMIT;
-- 如果任一 UPDATE 失败，执行 ROLLBACK分布式事务（Distributed Transaction）
分布式事务跨越多个独立的数据节点、数据库或服务。它需要协调多个资源管理器，保证全局的原子性和一致性。分布式事务的实现复杂度远高于本地事务，常见的实现方案包括两阶段提交（2PC）、三阶段提交（3PC）、TCC（Try-Confirm-Cancel）以及 Saga 模式。
常见误区：很多团队在微服务初期直接用 2PC 处理跨服务事务，导致性能瓶颈和锁冲突。实际上，大部分跨服务场景更适合用 Saga 或最终一致性方案，而非强一致性分布式事务。
核心对比
| 对比维度 | 本地事务 | 分布式事务 |
|---|---|---|
| 资源范围 | 单一数据库/单一资源 | 多个数据库/多个服务/多个资源 |
| ACID 支持 | 完全支持（强 ACID） | 通常弱化隔离性和一致性（BASE） |
| 性能 | 高（毫秒级） | 低（秒级，网络开销+协调开销） |
| 实现复杂度 | 低（数据库原生支持） | 高（需要协调器、补偿逻辑） |
| 典型协议 | 数据库事务日志 | 2PC、TCC、Saga、XA |
| 适用场景 | 单体应用、单库操作 | 微服务、跨库、跨团队协作 |
| 错误处理难度 | 低（自动回滚） | 高（需处理部分提交、超时、网络分区） |
1.4 事务边界划分的常见陷阱
- 边界过大：将多个不相关的业务操作放在同一个事务中，导致长事务锁住大量数据，引发死锁和性能瓶颈。
- 边界过小：将本应原子化的操作拆成多个独立事务，中间状态暴露给其他线程，破坏业务一致性。
- 混合资源类型：在同一事务中混合操作数据库、消息队列、缓存等异构资源，本地事务无法保证跨资源的一致性。
- 忽略网络超时：在分布式事务中未设置合理的超时阈值，导致事务悬挂，资源长期不释放。
最佳实践：事务边界的黄金法则是“一个事务只做一件事”。每个事务应该对应一个完整的业务原子操作，既不多也不少。在微服务架构中，优先考虑通过事件驱动和最终一致性来替代强一致性分布式事务。