{"name":"事务","id":"中间件-数据库-数据库系统-事务管理-事务","content":"# 事务系统\n\n> **事务为什么存在？它解决了什么根本问题？人类为此发明了哪些稳定的架构模式？**\n\n---\n\n## 一、第一性原理层：事务的本质（Why）\n\n### 1. 事务要解决的根本问题\n\n任何数据库系统都会同时面对三个不可回避的现实约束：\n\n1. **并发性（Concurrency）**：多个操作同时发生\n2. **部分失败（Partial Failure）**：程序、进程、机器随时可能失败\n3. **状态必须长期正确（State Correctness Over Time）**\n\n> **事务的本质定义：**\n> 事务是一种**在并发与故障环境下，维持系统状态合法性的控制机制**。\n\n它不是 SQL 语法，也不是存储引擎特性，而是一种**系统级风险管理机制**。\n\n---\n\n### 2. 什么是“正确的状态”\n\n“正确”并不是绝对的，而是相对于系统定义的不变量（Invariant）：\n\n* 数据不能部分更新\n* 并发操作不能相互破坏\n* 系统崩溃后状态仍可解释\n\n事务存在的唯一目标是：\n\n> **确保系统状态的演进，只发生在“允许的状态空间”之内**。\n\n---\n\n### 3. 一致性的三层语义（必须区分）\n\n| 层次      | 含义           | 责任主体 |\n| ------- | ------------ | ---- |\n| 约束一致性   | 外键、唯一性、Check | 数据库  |\n| 事务语义一致性 | 等价于某种串行执行    | 数据库  |\n| 业务一致性   | 账户不为负、库存守恒   | 应用   |\n\n> **ACID 中的 C = 事务语义一致性，而不是业务正确性**。\n\n数据库只能保证“你定义的规则被一致地执行”，不能保证规则本身是对的。\n\n---\n\n## 二、抽象模型层：事务系统的核心模型（What）\n\n### 1. 事务是一个状态机\n\n一个事务不是一条语句，而是一个**状态演进过程**：\n\n* 活动（Active）\n* 部分提交（Partially Committed）\n* 提交（Committed）\n* 失败 / 中止（Failed / Aborted）\n\n> 所有事务机制，本质上都是在**约束状态跳转的合法性**。\n\n---\n\n### 2. 冲突模型：问题从哪里来\n\n并发问题的根源只有一个：\n\n> **不同事务对同一状态产生了不可交换的操作顺序**。\n\n由此衍生出三类基本冲突：\n\n* 读-写冲突\n* 写-读冲突\n* 写-写冲突\n\n所有“脏读、不可重复读、幻读”，只是这些冲突在不同可见性规则下的表现形式。\n\n---\n\n### 3. 正确性的形式化标准：可串行化\n\n> **一个并发执行是正确的，当且仅当它等价于某种串行执行。**\n\n这是事务系统中**最稳定、最根本的正确性标准**。\n\n但它的代价是：\n\n* 限制并发\n* 增加等待\n* 降低吞吐\n\n工程实践的全部努力，都是在**“偏离可串行化多少是可接受的”**这一问题上展开的。\n\n---\n\n## 三、机制设计层：人类的三种核心解法（How）\n\n### 总览：并发控制三大范式\n\n| 范式    | 核心思想    | 关键假设   |\n| ----- | ------- | ------ |\n| 悲观控制  | 冲突一定会发生 | 先加锁    |\n| 乐观控制  | 冲突很少发生  | 先执行后验证 |\n| 多版本控制 | 读写不必冲突  | 时间切片   |\n\n---\n\n### 1. 悲观控制：锁（Locking）\n\n**设计哲学：**\n\n> 与其事后修正错误，不如事前避免错误。\n\n核心特征：\n\n* 读锁 / 写锁\n* 两阶段封锁（2PL）\n* 严格 2PL → 保证可恢复性\n\n代价：\n\n* 阻塞\n* 死锁\n* 锁争用\n\n适用场景：\n\n* 写多\n* 冲突频繁\n* 强一致性优先\n\n---\n\n### 2. 乐观控制：验证（Validation）\n\n**设计哲学：**\n\n> 假设世界是和平的，冲突是例外。\n\n执行流程：\n\n1. 读阶段\n2. 验证阶段\n3. 写阶段\n\n优点：\n\n* 高并发\n* 无锁读\n\n代价：\n\n* 回滚成本\n* 饥饿风险\n\n适用场景：\n\n* 冲突稀少\n* 内存系统\n* 短事务\n\n---\n\n### 3. 多版本控制：MVCC\n\n**设计哲学：**\n\n> 与其让事务争抢一个现在，不如让它们各自活在不同的时间片里。\n\n核心思想：\n\n* 写产生新版本\n* 读访问旧版本\n\n关键能力：\n\n* 快照\n* 可见性规则\n* 版本回收\n\nMVCC 本质上是：\n\n> **用空间换并发，用历史换隔离**。\n\n---\n\n## 四、事务的四大性质：因果而非并列\n\n### 1. 原子性（A）\n\n> 状态跳转要么发生，要么完全不发生。\n\n本质需求：\n\n* 消除中间状态\n\n实现基础：\n\n* Undo Log\n\n---\n\n### 2. 隔离性（I）\n\n> 并发执行对外表现为“好像只有自己在执行”。\n\n本质需求：\n\n* 控制可见性\n\n实现手段：\n\n* 锁\n* 版本\n* 验证\n\n---\n\n### 3. 持久性（D）\n\n> 已确认的状态，不应因崩溃而消失。\n\n本质需求：\n\n* 状态可重建\n\n实现基础：\n\n* WAL（先日志，后数据）\n\n---\n\n### 4. 一致性（C）是结果，而不是手段\n\n> C 不是一个独立机制，而是 A + I + D 在正确约束下的自然结果。\n\n---\n\n## 五、恢复系统：时间维度上的一致性\n\n### 1. 为什么必须写日志\n\n磁盘写入不是原子的。\n\n> 日志是**时间顺序的真相来源（Source of Truth）**。\n\n---\n\n### 2. Undo / Redo 的角色分工\n\n| 日志   | 解决问题    |\n| ---- | ------- |\n| Undo | 回滚未完成事务 |\n| Redo | 重放已提交事务 |\n\n---\n\n### 3. 恢复算法的统一结构\n\n1. 分析（谁活着）\n2. 重做（恢复已提交）\n3. 撤销（清理未完成）\n\nARIES 只是这一结构的经典工程实现。\n\n---\n\n## 六、工程实现是选择，而不是本质\n\n不同系统在以下维度做权衡：\n\n* 并发 vs 简单\n* 延迟 vs 吞吐\n* 一致性 vs 可用性\n\nMySQL、PostgreSQL、Oracle 的差异，\n\n> **不是原理不同，而是取舍不同**。\n\n---\n\n## 七、总结：事务系统的稳定认知\n\n1. 事务不是 SQL，而是系统控制论\n2. ACID 是因果关系，不是功能清单\n3. 可串行化是北极星，而不是日常选择\n4. MVCC、锁、验证是同一问题的不同答案\n5. 所有实现细节，都是时代与场景的产物\n\n## 关联内容（自动生成）\n\n- [/中间件/数据库/数据库优化.md](/中间件/数据库/数据库优化.md) 数据库优化与事务管理密切相关，特别是在并发控制模型、事务隔离级别选择和MVCC成本模型方面\n- [/中间件/数据库/分布式数据库.md](/中间件/数据库/分布式数据库.md) 分布式数据库扩展了单机事务的概念，涉及分布式事务、跨节点一致性及多分区共识协议\n- [/软件工程/架构/系统设计/分布式/分布式事务.md](/软件工程/架构/系统设计/分布式/分布式事务.md) 分布式事务是单机事务在分布式环境下的延伸，涉及两阶段提交、事务协调等复杂问题\n- [/中间件/数据库/mysql/mysql.md](/中间件/数据库/mysql/mysql.md) MySQL作为具体数据库实现，展示了事务管理、锁机制、MVCC等理论的实际应用\n- [/中间件/数据库/PostgreSQL.md](/中间件/数据库/PostgreSQL.md) PostgreSQL的MVCC实现提供了另一个事务并发控制的具体实例，有助于理解不同实现方式\n- [/操作系统/死锁.md](/操作系统/死锁.md) 操作系统中的死锁概念与数据库事务中的锁机制和死锁处理有相似的理论基础和解决策略\n- [/中间件/数据库/redis/客户端.md](/中间件/数据库/redis/客户端.md) Redis事务虽然不同于传统ACID事务，但在并发控制和一致性保证方面提供了不同的设计思路\n- [/数据技术/数据存储.md](/数据技术/数据存储.md) 数据存储技术中的ACID事务保证是实现数据一致性的基础，与事务管理理论密切相关\n","metadata":"tags: ['数据库', '并发编程', '事务管理', '可串行化']\nbooks: [\n  {name: '数据密集型应用系统设计', chapters: ['第七章']},\n  {name: '数据库系统概念', chapters: ['第十四章', '第十五章', '第十六章']}\n]\nlinks: [\n  'http://www.cyc2018.xyz/%E6%95%B0%E6%8D%AE%E5%BA%93/%E6%95%B0%E6%8D%AE%E5%BA%93%E7%B3%BB%E7%BB%9F%E5%8E%9F%E7%90%86.html#%E5%B0%81%E9%94%81%E5%8D%8F%E8%AE%AE'\n]","hasMoreCommit":true,"totalCommits":35,"commitList":[{"date":"2026-02-28T15:03:54+08:00","author":"MY","message":"docs(java): 移除JDBC相关文档链接并优化ORM章节结构","hash":"ec18590f8db79888521ec0118110d5a50e935b87"},{"date":"2026-02-24T16:20:34+08:00","author":"MY","message":"docs(SUMMARY): 移除过时的框架文档链接","hash":"468d789997b9b5a69f7fe5ad9924e64e1890dd31"},{"date":"2026-02-12T14:07:03+08:00","author":"MY","message":"doc: 整理标签","hash":"290b3e8ad18f48832ac282290238d020fc030a88"},{"date":"2026-01-13T16:44:48+08:00","author":"MY","message":"docs(database): 更新事务管理文档并添加相关图片资源","hash":"9b9ea96f7982df7c463ad0e18ef8341c3e1640c8"},{"date":"2024-12-27T15:45:13+08:00","author":"MY","message":"📦事务","hash":"f8df2a18d12c9eff191001b7188954e8f3483587"},{"date":"2024-12-06T15:54:05+08:00","author":"MY","message":"📦MVCC","hash":"f7b4e45c325e43a662a33ff22b273bcbf0ed5337"},{"date":"2024-11-07T16:23:04+08:00","author":"MY","message":"📦MySQL","hash":"cc0b244f98955ea55043ef57b13e9fe490a110b1"},{"date":"2024-11-06T19:33:09+08:00","author":"MY","message":"📦MySQL","hash":"8c2a462ec10106b29a91c0b5e99e33ff2dd180b8"},{"date":"2023-04-27T16:40:00+08:00","author":"MY","message":"✏分布式数据库","hash":"a2497973746ecb1a976ed8cb40a615b47a09ff88"},{"date":"2023-04-25T21:20:26+08:00","author":"MY","message":"✏️事务","hash":"17488c68fa6e1a5e630cc03066b493fb6e53e980"}],"createTime":"2019-07-14T16:01:48+08:00"}