4、事务基础：ACID特性、Go中事务的开启与提交、事务的隔离级别、事务的常见问题（死锁、超时）

事务是数据库操作的基本逻辑单元，它将一组读写操作捆绑为一个不可分割的执行单元。在分布式系统与高并发场景下，正确理解并运用事务是保证数据一致性的基石。本章将深入剖析事务的四大核心特性、Go语言中事务的开启与提交流程、四种隔离级别的行为差异，以及开发中频繁遇到的死锁与超时问题。

4.1 ACID特性：事务的四大基石

ACID是数据库事务正确执行的四个基本要素，任何偏离ACID的事务实现都可能导致数据损坏或业务逻辑错误。

特性 全称 核心含义 违反后果
A 原子性 (Atomicity) 事务中的所有操作要么全部成功，要么全部回滚，不存在中间状态 部分写入导致数据残缺
C 一致性 (Consistency) 事务执行前后，数据库必须满足所有预定义的约束（主键、外键、唯一性、业务规则） 脏数据、业务逻辑失效
I 隔离性 (Isolation) 并发执行的事务之间互不干扰，每个事务都感觉自己是唯一运行的 脏读、不可重复读、幻读
D 持久性 (Durability) 一旦事务提交成功，其结果必须永久保存，即使系统崩溃也不会丢失 数据丢失、恢复困难
实战提示：在Go事务编程中，原子性由tx.Commit()与tx.Rollback()共同保障；一致性依赖业务代码中的约束检查；隔离性由数据库隔离级别控制；持久性由数据库的WAL（Write-Ahead Logging）机制保证，应用层无需额外处理。

4.2 Go中事务的开启与提交

Go标准库database/sql提供了简洁的事务接口。事务的开启、提交与回滚必须严格遵循“开启→执行→提交/回滚”的三段式生命周期。

4.2.1 事务开启与提交的标准模式

// 开启事务
tx, err := db.Begin()
if err != nil {
    log.Fatalf("开启事务失败: %v", err)
}

// 执行业务操作
_, err = tx.Exec("UPDATE accounts SET balance = balance - 100 WHERE id = ?", 1)
if err != nil {
    tx.Rollback() // 任何错误立即回滚
    log.Fatalf("扣款失败: %v", err)
}

_, err = tx.Exec("UPDATE accounts SET balance = balance + 100 WHERE id = ?", 2)
if err != nil {
    tx.Rollback()
    log.Fatalf("入账失败: %v", err)
}

// 提交事务
if err := tx.Commit(); err != nil {
    log.Fatalf("提交事务失败: %v", err)
}

4.2.2 使用 defer 确保回滚安全

为防止函数提前返回导致事务未回滚，推荐使用defer配合标记变量实现安全回滚：

tx, err := db.Begin()
if err != nil {
    return err
}
rollback := true
defer func() {
    if rollback {
        tx.Rollback()
    }
}()

// 执行操作...
if err := doWork(tx); err != nil {
    return err // defer 自动回滚
}

rollback = false
return tx.Commit() // 标记为 false，defer 不再回滚
常见陷阱：不要在一个事务中混合使用db.Exec()和tx.Exec()。db.Exec()使用的是连接池中的独立连接，不在当前事务范围内，会导致事务隔离失效。

4.3 事务的隔离级别

隔离级别决定了事务之间可见性的程度。SQL标准定义了四种隔离级别，从低到高依次为：读未提交、读已提交、可重复读、串行化。每种级别解决了特定的并发问题，但也带来了不同的性能开销。

并发问题速查：
  • 脏读：读到其他事务未提交的数据（可能被回滚）
  • 不可重复读：同一事务内两次读取同一行数据，结果不一致（其他事务已提交更新）
  • 幻读：同一事务内两次范围查询，结果集行数不一致（其他事务已插入新行）
隔离级别 脏读 不可重复读 幻读 性能 典型实现机制
读未提交 (READ UNCOMMITTED) 可能 可能 可能 最高 不加锁
读已提交 (READ COMMITTED) 不可能 可能 可能 高 行级锁（写锁）、MVCC
可重复读 (REPEATABLE READ) 不可能 不可能 可能（MySQL InnoDB通过间隙锁避免） 中 MVCC + 间隙锁
串行化 (SERIALIZABLE) 不可能 不可能 不可能 最低 范围锁、表锁

4.3.1 Go中设置隔离级别

// MySQL 示例：设置事务隔离级别为可重复读
tx, err := db.Begin()
if err != nil {
    return err
}

// 执行隔离级别设置语句（必须在事务内第一条语句执行）
_, err = tx.Exec("SET TRANSACTION ISOLATION LEVEL REPEATABLE READ")
if err != nil {
    tx.Rollback()
    return err
}

// 后续业务操作...
生产建议：大多数业务系统使用读已提交（PostgreSQL默认）或可重复读（MySQL InnoDB默认）。串行化虽然最安全，但并发吞吐量极低，仅在金融对账等极端一致性场景使用。

4.4 事务的常见问题：死锁与超时

死锁和超时是事务并发中最棘手的两个问题。理解它们的成因和解决策略，是Go事务编程进阶的必修课。

4.4.1 死锁

死锁是指两个或多个事务互相持有对方需要的资源，导致所有事务都无法继续执行。数据库会自动检测死锁并强制回滚其中一个事务（通常选择回滚代价较小的一方）。

死锁形成示意图 事务 A 持有：资源 1 事务 B 持有：资源 2 资源 1 被事务 A 持有 资源 2 被事务 B 持有 请求资源 2 请求资源 1 死锁循环：A 等 B 释放资源2，B 等 A 释放资源1 数据库检测到死锁后，强制回滚其中一个事务

4.4.2 死锁的预防与处理

  • 固定访问顺序：所有事务按照相同的顺序访问资源（例如：先更新账户A，再更新账户B），避免循环等待。
  • 缩短事务时间：事务内只做必要的数据库操作，避免在事务中执行RPC调用、文件读写等耗时操作。
  • 设置锁超时：通过innodb_lock_wait_timeout（MySQL）或lock_timeout（PostgreSQL）限制等待时间。
  • 重试机制：捕获死锁错误（MySQL错误码1213），在应用层实现指数退避重试。

4.4.3 超时

事务超时分为两种：锁等待超时和事务执行超时。锁等待超时是指事务在等待获取锁时超过了数据库配置的最大等待时间；事务执行超时是指事务从开启到提交的总耗时超过了应用层或数据库的限制。

// Go 中设置事务超时（使用 context）
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()

tx, err := db.BeginTx(ctx, nil)
if err != nil {
    return err
}

// 如果事务执行超过5秒，ctx.Done() 会触发，tx.Exec() 会返回 context deadline exceeded 错误
_, err = tx.ExecContext(ctx, "UPDATE heavy_table SET ...")
if err != nil {
    tx.Rollback()
    return err
}

return tx.Commit()
超时处理要点：
  • 数据库层面的锁超时（如MySQL的innodb_lock_wait_timeout默认50秒）通常较长，应用层应设置更短的超时时间。
  • 使用context.WithTimeout时，超时后tx.ExecContext会立即返回错误，但数据库连接上的事务可能仍在运行，需要显式调用tx.Rollback()清理。
  • 长事务（超过10秒）应视为反模式，它们会持有锁、阻塞其他事务、增加死锁概率。

4.5 事务隔离级别与并发问题对照

下面的SVG图展示了不同隔离级别下，三个典型并发问题的解决情况，帮助你在选择隔离级别时做出权衡。

隔离级别 vs 并发问题解决矩阵 隔离级别 脏读 不可重复读 幻读 读未提交 ✗ 可能 ✗ 可能 ✗ 可能 读已提交 ✓ 不可能 ✗ 可能 ✗ 可能 可重复读 ✓ 不可能 ✓ 不可能 △ InnoDB可避免 串行化 ✓ 不可能 ✓ 不可能 ✓ 不可能

4.6 本章小结

  • ACID是事务正确性的底线，原子性和持久性由数据库与Go事务接口共同保障，一致性和隔离性需要开发者根据业务场景主动设计。
  • Go事务编程的核心模式是db.Begin() → 业务操作 → Commit()或Rollback()，务必使用defer确保异常路径下的回滚。
  • 隔离级别的选择是性能与一致性的权衡：读已提交适合大多数OLTP场景，可重复读适合需要报表一致性读的场景，串行化仅用于极端安全要求。
  • 死锁通过固定资源访问顺序和缩短事务时间预防，超时通过context.WithTimeout和数据库参数双重控制。
← 上一章 📖 返回目录 下一章 →