📚 课程目录第1章事务边界基础

1、事务边界基础：事务的ACID特性、本地事务与分布式事务、事务边界在代码中的显式与隐式定义

1.1 事务的核心：ACID 特性

事务（Transaction）是数据库系统执行过程中的一个逻辑单元，它由一组操作序列组成，这些操作要么全部成功，要么全部失败。ACID 是事务必须满足的四个基本特性，也是判断一个系统是否支持可靠事务的黄金标准。

特性	全称	含义	违反后果
A	原子性 (Atomicity)	事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个状态。	部分写入导致数据不一致
C	一致性 (Consistency)	事务执行前后，数据库的完整性约束没有被破坏（如主键唯一、外键约束、业务规则）。	脏数据、违反业务规则
I	隔离性 (Isolation)	并发执行的事务之间互不干扰，一个事务的中间状态对其他事务不可见。	脏读、不可重复读、幻读
D	持久性 (Durability)	事务一旦提交，其结果就是永久性的，即使系统崩溃也不会丢失。	数据丢失、回滚后数据不完整

调试视角： 在可观测性中，ACID 的 原子性 和 隔离性 是最容易出问题的边界。原子性失败通常表现为“部分提交”，而隔离性失败则表现为“并发冲突”。日志和追踪系统需要能够清晰标记事务的开始、提交/回滚点，以及锁等待时间。

1.2 本地事务与分布式事务

根据事务涉及的数据源数量和部署架构，事务分为本地事务和分布式事务两大类。理解它们的区别是定义事务边界的前提。

维度	本地事务	分布式事务
数据源	单个数据库实例	多个数据库实例、消息队列、缓存、微服务
协议	数据库原生支持（如 MySQL InnoDB）	XA 协议、TCC、Saga、Seata
回滚机制	数据库自动回滚（Undo Log）	需要协调者（Coordinator）或补偿事务
性能	高（无网络开销）	低（网络通信 + 锁竞争）
典型场景	单体应用、单库操作	微服务调用链、跨库转账、订单与库存分离

常见误区： 很多开发者在微服务架构中仍然试图用“本地事务”来保证跨服务的数据一致性，这必然导致事务边界模糊。正确的做法是：本地事务管本地，分布式事务管跨服务。在可观测性中，分布式事务的边界通常需要借助全局事务 ID（Global Transaction ID）来串联。

1.3 事务边界在代码中的显式与隐式定义

事务边界是事务开始、提交或回滚的代码位置。在开发中，事务边界有两种定义方式：显式定义 和 隐式定义。理解这两种方式，是进行事务边界调试的基础。

1.3.1 显式事务边界

开发者通过代码手动控制事务的 begin、commit 和 rollback。这种方式边界清晰，但容易因遗漏提交或异常处理不当导致事务悬挂。

// 显式事务边界示例（Java + JDBC）
Connection conn = dataSource.getConnection();
try {
    conn.setAutoCommit(false);  // 事务开始

    // 业务操作 1
    PreparedStatement ps1 = conn.prepareStatement("UPDATE account SET balance = balance - 100 WHERE id = 1");
    ps1.executeUpdate();

    // 业务操作 2
    PreparedStatement ps2 = conn.prepareStatement("UPDATE account SET balance = balance + 100 WHERE id = 2");
    ps2.executeUpdate();

    conn.commit();  // 事务提交
} catch (Exception e) {
    conn.rollback();  // 事务回滚
    throw e;
} finally {
    conn.setAutoCommit(true);
    conn.close();
}

1.3.2 隐式事务边界

通过框架（如 Spring @Transactional）或数据库自动提交模式来管理事务。开发者只需声明事务属性，框架在方法调用前后自动注入边界。这种方式代码简洁，但边界容易被“方法嵌套”或“传播行为”模糊化。

// 隐式事务边界示例（Spring Boot + @Transactional）
@Service
public class TransferService {

    @Transactional(propagation = Propagation.REQUIRED)
    public void transfer(Long fromId, Long toId, BigDecimal amount) {
        // 方法开始时自动开启事务
        accountDao.debit(fromId, amount);
        accountDao.credit(toId, amount);
        // 方法正常结束时自动提交，异常时自动回滚
    }
}

  调试关键点：
  显式边界： 检查 commit 和 rollback 是否成对出现，是否覆盖所有异常路径。
隐式边界： 检查 @Transactional 的 propagation 和 rollbackFor 属性，避免因异常类型不匹配导致事务未回滚。
嵌套事务： 当方法 A（有事务）调用方法 B（也有事务）时，事务边界会合并或新建，取决于传播行为。这是最常见的边界模糊场景。

1.4 事务边界调试的核心原则

原则一：边界即观测点。 事务的 begin、commit、rollback 是必须打日志的关键点。在分布式事务中，还需要记录全局事务 ID 和分支事务 ID。
原则二：隔离级别决定可见性。 不同的隔离级别（Read Uncommitted / Read Committed / Repeatable Read / Serializable）直接影响事务边界内数据的可见范围，调试时需确认当前会话的隔离级别。
原则三：传播行为决定嵌套边界。 在 Spring 等框架中，REQUIRED、REQUIRES_NEW、NESTED 等传播行为决定了多个事务方法调用时边界是合并还是独立。这是隐式事务边界调试中最容易踩坑的地方。

可观测性落地建议： 在开发环境中，建议为每个事务生成一个唯一的 事务追踪 ID（Transaction Trace ID），并将其注入到日志、数据库连接和下游调用中。这样，当出现“部分提交”或“死锁”时，可以通过追踪 ID 快速定位事务边界断裂的位置。