📚 课程目录第3章事务边界定义

3、事务边界定义

事务边界是分布式系统中划分原子操作范围的核心概念。在单体应用中，事务边界通常由数据库连接或框架（如 Spring @Transactional）隐式管理；但在微服务与 Kubernetes 环境下，事务边界必须显式定义，且需要跨越进程、网络与容器生命周期。

3.1 什么是事务边界

事务边界指一组操作被保证“要么全部成功，要么全部失败”的起始与终止范围。在分布式系统中，事务边界通常由以下三个要素构成：

起始点（Begin）：标记事务开始，记录当前系统状态快照或生成全局事务 ID。
操作集（Operations）：在边界内执行的一组读写、调用或状态变更操作。
终止点（Commit / Rollback）：根据操作结果决定持久化变更或回滚到起始点状态。

关键认知：事务边界不是数据库专有概念。在微服务中，任何需要跨服务保持数据一致性的操作序列，都必须显式定义事务边界，即使底层存储不支持分布式事务。

3.2 微服务与 K8s 环境下的事务边界特殊性

相比单体应用，微服务与 Kubernetes 环境给事务边界带来了四个显著挑战：

挑战维度	单体环境	微服务 + K8s 环境
网络边界	事务在单一进程内完成，网络延迟可忽略	事务跨越多个 Pod/Service，网络延迟、超时、分区成为常态
状态持久性	数据库连接是长连接，事务上下文由连接持有	Pod 可能被调度、重启、缩容，事务上下文必须外部化（如 etcd、Redis）
并发粒度	数据库行锁或表锁控制并发	多个 Pod 实例可能同时操作同一资源，需要分布式锁或乐观并发控制
回滚范围	回滚仅涉及单库 undo log	回滚需要调用补偿接口（Saga）、发送死信消息或触发 K8s Job 清理

以下 SVG 展示了 K8s 环境下事务边界的典型范围：

3.3 ACID 与 BASE 的权衡

在分布式事务边界设计中，ACID 与 BASE 是两种核心权衡模型。ACID 追求强一致性，BASE 追求最终一致性。以下表格对比了二者在事务边界定义中的关键差异：

属性	ACID（强一致性）	BASE（最终一致性）
Atomicity（原子性）	事务边界内所有操作要么全成功，要么全回滚	允许部分成功，通过补偿操作逐步回滚
Consistency（一致性）	事务完成后数据必须满足所有约束	数据在某个时间窗口内可能不一致，但最终收敛
Isolation（隔离性）	事务之间完全隔离，未提交变更不可见	允许读未提交或脏读，依赖业务层处理
Durability（持久性）	提交后数据永久保存	提交后数据可能因补偿操作被撤销
适用场景	支付、库存扣减、账户转账	社交动态、日志聚合、推荐系统
K8s 实现模式	2PC（两阶段提交）、XA 事务	Saga、TCC（Try-Confirm-Cancel）、事件驱动

实践警告：在 K8s 环境下，2PC 的协调器会成为单点瓶颈，且 Pod 重启可能导致事务悬挂。BASE 模式虽然牺牲了强一致性，但能更好地适应 Pod 弹性伸缩和网络分区。建议优先评估业务对一致性的真实需求，不要盲目追求 ACID。

以下 SVG 展示了 ACID 与 BASE 在事务边界上的决策流程：

3.4 事务边界的代码级定义示例

在 Go 微服务中，事务边界通常通过中间件或拦截器显式定义。以下示例展示了如何在 K8s 环境下使用 Saga 模式定义事务边界：

// 事务边界定义：Saga 协调器
type SagaTransaction struct {
    ID        string
    Steps     []SagaStep
    Compensations []SagaStep
    State     string // "pending" | "committing" | "compensating"
}

type SagaStep struct {
    Service   string
    Action    func(ctx context.Context) error
    Compensate func(ctx context.Context) error
}

// 定义事务边界：创建订单 + 扣减库存 + 支付
func CreateOrderSaga(ctx context.Context, order Order) error {
    tx := &SagaTransaction{
        ID:    generateTxID(),
        State: "pending",
        Steps: []SagaStep{
            {Service: "order-svc", Action: createOrder, Compensate: cancelOrder},
            {Service: "inventory-svc", Action: deductStock, Compensate: restoreStock},
            {Service: "payment-svc", Action: processPayment, Compensate: refundPayment},
        },
    }

    // 持久化事务边界到 etcd（K8s 环境）
    if err := persistTxBoundary(ctx, tx); err != nil {
        return fmt.Errorf("persist tx boundary failed: %w", err)
    }

    // 执行事务步骤
    for _, step := range tx.Steps {
        if err := step.Action(ctx); err != nil {
            tx.State = "compensating"
            // 触发补偿
            go compensate(ctx, tx)
            return fmt.Errorf("step %s failed: %w", step.Service, err)
        }
    }

    tx.State = "committing"
    return nil
}

  关键点：事务边界在代码中表现为一个显式的 SagaTransaction 结构体，包含正向步骤和补偿步骤。在 K8s 环境下，事务边界必须持久化到外部存储（如 etcd），以便在 Pod 重启后能够恢复或终止悬挂事务。

3.5 事务边界设计原则

最小化边界范围：事务边界应只包含真正需要原子性的操作，避免将无关服务纳入同一事务。
显式定义补偿：每个事务步骤都必须有对应的补偿操作，且补偿必须是幂等的。
边界超时机制：为每个事务边界设置 TTL（生存时间），超时后自动触发补偿或告警。
边界可观测性：事务边界的开始、提交、补偿事件必须记录到日志和指标系统，便于排障。
避免跨 Namespace 事务：尽量将事务边界限制在同一个 K8s Namespace 内，减少网络策略和 DNS 解析的干扰。