数据库事务与ACID特性的原理与实现

题目描述
数据库事务是后端系统中保证数据一致性的核心机制。ACID（原子性、一致性、隔离性、持久性）是事务的四个关键特性。面试官会考察：1）ACID每个特性的具体含义；2）数据库如何通过日志、锁等机制实现这些特性；3）在分布式场景下的挑战。

一、事务的基本概念与ACID定义

1. 事务的本质
   事务是一组不可分割的数据库操作序列（例如转账：扣款A账户、存款B账户）。这些操作要么全部成功（提交），要么全部失败（回滚）。

2. ACID特性详解

   • 原子性（Atomicity）：事务是最小执行单位，操作要么全部完成，要么全部不执行。
   • 一致性（Consistency）：事务执行后，数据库必须从一个一致状态转换到另一个一致状态（如转账前后总金额不变）。
   • 隔离性（Isolation）：并发事务互相隔离，不会看到中间状态。
   • 持久性（Durability）：事务提交后，修改永久保存，即使系统故障也不丢失。

二、原子性的实现：日志机制

1. 核心问题
   若事务执行到一半系统崩溃，如何回滚已部分执行的操作？

2. Undo日志流程

   • 步骤1：事务开始前，将修改前的数据旧值（例如A账户原余额）写入Undo日志。
   • 步骤2：执行数据修改（A账户扣款）。
   • 步骤3：若事务失败，从Undo日志读取旧值恢复数据；若成功，最终清理日志。
   • 关键点：日志写入必须在数据修改前完成（Write-Ahead Logging原则）。

三、持久性的实现：Redo日志与刷盘策略

1. 核心问题
   事务提交后，数据可能还在内存缓冲区未写入磁盘，此时断电如何保证不丢失？

2. Redo日志流程

   • 步骤1：事务提交前，将所有修改操作（例如“A账户余额改为100”）按顺序写入Redo日志文件。
   • 步骤2：强制将Redo日志刷到磁盘（fsync操作），确保日志持久化。
   • 步骤3：内存中的数据页可以延迟刷盘。崩溃恢复时，重放Redo日志中的操作。
   • 优势：顺序写日志比随机写数据页更快，且日志体积小。

四、隔离性的实现：并发控制技术

1. 问题场景
   并发事务可能导致脏读（读到未提交数据）、不可重复读（同一查询结果不同）、幻读（新增记录被看到）。

2. 锁机制

   • 共享锁（S锁）：读操作时加锁，其他事务可读不可写。
   • 排他锁（X锁）：写操作时加锁，其他事务不可读写。
   • 两阶段锁协议（2PL）：事务中先申请所有需要的锁，提交后统一释放。避免死锁需配合超时或等待图检测。

3. 多版本并发控制（MVCC）

   • 原理：为每条数据维护多个版本（通过时间戳或事务ID标记）。
   • 读操作：只能看到已提交且早于当前事务开始的版本（快照读）。
   • 写操作：创建新版本，不影响旧版本读取。
   • 优势：读不阻塞写，提高并发性能（InnoDB、PostgreSQL采用）。

五、一致性的实现：约束与业务逻辑

1. 数据库层保障

   • 通过唯一索引、外键约束、数据类型检查等，在提交时验证数据规则。
   • 示例：转账时检查余额非负约束，若违反则回滚事务。

2. 应用层责任

   • 业务逻辑需保证一致性（如“总额校验”），需与事务边界结合。
   • 例如：在事务内先查询余额再执行转账，避免并发问题。

六、分布式事务的挑战

1. CAP定理限制
   分布式系统无法同时保证一致性、可用性、分区容错性。需根据场景权衡（如CP系统ZooKeeper vs AP系统Cassandra）。

2. 两阶段提交（2PC）

   • 阶段1（准备）：协调者询问所有参与者能否提交，参与者预写日志并锁定资源。
   • 阶段2（提交/回滚）：若所有参与者同意，协调者发送提交命令；否则回滚。
   • 缺陷：同步阻塞、单点故障（协调者崩溃可能导致资源长期锁定）。

3. 柔性事务方案

   • TCC模式：业务层实现Try（预留资源）、Confirm（确认）、Cancel（取消）接口，通过重试和补偿保证最终一致性。
   • Saga模式：将长事务拆分为多个本地子事务，每个子事务有对应的补偿操作，失败时逆向执行补偿。

总结
事务ACID特性通过日志（Undo/Redo）、锁、MVCC等技术协同实现。分布式场景下需结合业务特点选择刚性事务（如2PC）或柔性事务（如TCC）方案，权衡一致性与性能。