事务系统

事务为什么存在？它解决了什么根本问题？人类为此发明了哪些稳定的架构模式？

一、第一性原理层：事务的本质（Why）

1. 事务要解决的根本问题

任何数据库系统都会同时面对三个不可回避的现实约束：

  1. **并发性（Concurrency）**：多个操作同时发生
  2. **部分失败（Partial Failure）**：程序、进程、机器随时可能失败
  3. **状态必须长期正确（State Correctness Over Time）**

事务的本质定义：事务是一种在并发与故障环境下，维持系统状态合法性的控制机制。

它不是 SQL 语法，也不是存储引擎特性，而是一种系统级风险管理机制。

2. 什么是“正确的状态”

“正确”并不是绝对的，而是相对于系统定义的不变量（Invariant）：

事务存在的唯一目标是：

确保系统状态的演进，只发生在“允许的状态空间”之内。

3. 一致性的三层语义（必须区分）

层次含义责任主体
约束一致性外键、唯一性、Check数据库
事务语义一致性等价于某种串行执行数据库
业务一致性账户不为负、库存守恒应用

ACID 中的 C = 事务语义一致性，而不是业务正确性。

数据库只能保证“你定义的规则被一致地执行”，不能保证规则本身是对的。

二、抽象模型层：事务系统的核心模型（What）

1. 事务是一个状态机

一个事务不是一条语句，而是一个状态演进过程：

所有事务机制，本质上都是在约束状态跳转的合法性。

2. 冲突模型：问题从哪里来

并发问题的根源只有一个：

不同事务对同一状态产生了不可交换的操作顺序。

由此衍生出三类基本冲突：

所有“脏读、不可重复读、幻读”，只是这些冲突在不同可见性规则下的表现形式。

3. 正确性的形式化标准：可串行化

一个并发执行是正确的，当且仅当它等价于某种串行执行。

这是事务系统中最稳定、最根本的正确性标准。

但它的代价是：

工程实践的全部努力，都是在**“偏离可串行化多少是可接受的”**这一问题上展开的。

三、机制设计层：人类的三种核心解法（How）

总览：并发控制三大范式

范式核心思想关键假设
悲观控制冲突一定会发生先加锁
乐观控制冲突很少发生先执行后验证
多版本控制读写不必冲突时间切片

1. 悲观控制：锁（Locking）

设计哲学：

与其事后修正错误，不如事前避免错误。

核心特征：

代价：

适用场景：

2. 乐观控制：验证（Validation）

设计哲学：

假设世界是和平的，冲突是例外。

执行流程：

  1. 读阶段
  2. 验证阶段
  3. 写阶段

优点：

代价：

适用场景：

3. 多版本控制：MVCC

设计哲学：

与其让事务争抢一个现在，不如让它们各自活在不同的时间片里。

核心思想：

关键能力：

MVCC 本质上是：

用空间换并发，用历史换隔离。

四、事务的四大性质：因果而非并列

1. 原子性（A）

状态跳转要么发生，要么完全不发生。

本质需求：

实现基础：

2. 隔离性（I）

并发执行对外表现为“好像只有自己在执行”。

本质需求：

实现手段：

3. 持久性（D）

已确认的状态，不应因崩溃而消失。

本质需求：

实现基础：

4. 一致性（C）是结果，而不是手段

C 不是一个独立机制，而是 A + I + D 在正确约束下的自然结果。

五、恢复系统：时间维度上的一致性

1. 为什么必须写日志

磁盘写入不是原子的。

日志是时间顺序的真相来源（Source of Truth）。

2. Undo / Redo 的角色分工

日志解决问题
Undo回滚未完成事务
Redo重放已提交事务

3. 恢复算法的统一结构

  1. 分析（谁活着）
  2. 重做（恢复已提交）
  3. 撤销（清理未完成）

ARIES 只是这一结构的经典工程实现。

六、工程实现是选择，而不是本质

不同系统在以下维度做权衡：

MySQL、PostgreSQL、Oracle 的差异，

不是原理不同，而是取舍不同。

七、总结：事务系统的稳定认知

  1. 事务不是 SQL，而是系统控制论
  2. ACID 是因果关系，不是功能清单
  3. 可串行化是北极星，而不是日常选择
  4. MVCC、锁、验证是同一问题的不同答案
  5. 所有实现细节，都是时代与场景的产物

关联内容（自动生成）