3. 事务边界定义：本地事务边界 vs 分布式事务边界、边界划分原则

事务边界是分布式系统设计中最容易被忽视却又最具破坏力的细节。边界划得过宽，锁与资源滞留时间过长，系统吞吐量骤降；边界划得过窄，数据一致性被打破，脏读、幻读、更新丢失接踵而至。本节从边界本质出发，对比本地事务与分布式事务的边界差异，并给出可落地的划分原则。

3.1 事务边界的本质

事务边界定义了一组操作被视为一个不可分割的逻辑单元的范围。边界内所有操作要么全部成功（Commit），要么全部回滚（Rollback）。边界外部的观察者永远看不到中间状态。

维度	本地事务边界	分布式事务边界
资源范围	单个数据库连接 / 单个资源管理器	跨多个数据库、消息队列、缓存、RPC 服务
协调机制	数据库自身事务日志 + 锁	协调器（Coordinator）+ 全局事务 ID + 两阶段/三阶段提交
隔离级别	由数据库提供（Read Committed / Repeatable Read / Serializable）	依赖各参与方本地隔离 + 补偿逻辑，全局隔离通常降级
回滚代价	极低，数据库自动回滚	高，需要反向补偿或 Saga 回滚
典型实现	Go 中 database/sql 的 Begin / Commit / Rollback	DTM、Seata、手动 Saga 编排

3.2 本地事务边界：小而精确

在 Go 中，本地事务边界通常对应一个 sql.Tx 对象的生命周期。边界划分的核心原则是：事务内只做与数据一致性直接相关的操作。

// 不推荐：事务内包含外部 RPC 调用
tx, _ := db.Begin(ctx)
updateOrderStatus(tx, orderID, "paid")
err := callPaymentGateway(orderID) // 外部 RPC，可能阻塞数秒
if err != nil {
    tx.Rollback()
    return err
}
tx.Commit()

// 推荐：事务只包裹数据库操作
err := callPaymentGateway(orderID)
if err != nil {
    return err
}
tx, _ := db.Begin(ctx)
updateOrderStatus(tx, orderID, "paid")
updateInventory(tx, productID, -1)
tx.Commit()

3.3 分布式事务边界：宽而有度

分布式事务边界必须跨越多个自治节点。边界划分不再是“要不要包含这个操作”，而是如何在不破坏一致性的前提下，让边界尽可能短。

常见的分布式事务边界模式：

• TCC（Try-Confirm-Cancel）边界：Try 阶段预留资源，Confirm/Cancel 阶段完成或释放。边界在 Try 入口开始，在 Confirm/Cancel 结束。
• Saga 边界：由一系列本地事务 + 补偿事务组成。边界跨越整个 Saga 编排流程，但每个本地子事务的边界是独立的。
• 消息事务边界：本地事务与消息发送绑定在同一边界内，确保“业务操作”与“消息投递”原子化。

3.4 边界划分五大原则

以下原则适用于本地事务和分布式事务，但分布式事务场景下需要更严格的遵守：

原则	说明	违反后果
1. 最小化原则	只将必须原子化的操作放入事务边界	锁竞争加剧，吞吐量下降
2. 无外部副作用原则	事务边界内不触发外部系统不可逆操作（如发邮件、扣款）	回滚后外部状态已改变，无法补偿
3. 幂等性原则	边界内的每个操作都支持重复执行	重试导致数据重复或状态错乱
4. 可补偿原则	每个正向操作都有对应的反向补偿操作	部分失败后无法回滚，数据永久不一致
5. 边界显式化原则	事务开始、提交、回滚必须在代码中显式声明，不依赖隐式行为	事务意外提交或泄漏，连接未归还

3.5 事务边界可视化：从本地到分布式

下图展示了本地事务边界与分布式事务边界的核心差异。左侧本地事务边界紧贴数据库连接，右侧分布式事务边界跨越多个服务节点，需要协调器维护全局一致性视图。

3.6 边界划分实战：Go 代码中的边界决策

在实际 Go 项目中，事务边界划分往往需要在一致性与性能之间做权衡。以下决策树可以帮助快速判断：

1. 操作是否只涉及一个数据库？ → 使用本地事务边界，Begin + Commit / Rollback。
2. 操作跨多个数据库但可以接受最终一致性？ → 使用 Saga 边界，每个子事务独立提交，失败时执行补偿。
3. 操作跨多个数据库且要求强一致性？ → 使用 TCC 或两阶段提交，但需接受性能损失和协调器单点风险。
4. 操作涉及消息队列？ → 使用消息事务边界，将业务操作与消息发送绑定在同一个本地事务中。
5. 操作涉及外部第三方（支付网关、短信平台）？ → 绝对不要放入事务边界内。采用“先本地持久化，再异步调用外部”的模式。