数据库事务的并发控制与冲突解决机制 题目描述 在高并发数据库系统中，多个事务可能同时访问相同的数据资源，如果不加以控制，会导致数据不一致问题。常见的并发冲突包括脏读、不可重复读、幻读等。本题目要求掌握如何通过并发控制机制（如锁、时间戳、多版本控制等）检测和解决这些冲突，确保事务的隔离性和数据一致性。 一、并发冲突的类型与成因 1.1 脏读（Dirty Read） 问题描述 ：事务A读取了事务B未提交的修改，事务B后来回滚，导致事务A读取到无效数据。 示例 ： 事务B将账户余额从100改为200（未提交）。 事务A读取余额为200。 事务B回滚，余额恢复为100，事务A的读取结果错误。 1.2 不可重复读（Non-Repeatable Read） 问题描述 ：事务A多次读取同一数据，期间事务B修改了该数据并提交，导致事务A多次读取结果不一致。 示例 ： 事务A第一次读取余额为100。 事务B将余额改为200并提交。 事务A再次读取余额为200，与第一次结果不一致。 1.3 幻读（Phantom Read） 问题描述 ：事务A多次查询符合某条件的记录集，期间事务B插入或删除了符合条件的记录并提交，导致事务A两次查询的记录数量不同。 示例 ： 事务A查询年龄小于30的用户，返回10条记录。 事务B插入一条年龄为25的新用户并提交。 事务A再次查询，返回11条记录。 二、并发控制的核心机制 2.1 锁机制（Locking） 基本思想 ：事务访问数据前先获取锁，其他事务必须等待锁释放。 锁的类型 ： 共享锁（S锁） ：用于读操作，允许多个事务同时读取同一数据。 排他锁（X锁） ：用于写操作，只允许一个事务独占数据。 锁的粒度 ：行锁、表锁、页锁等（参考已讲题目“数据库锁的粒度和类型”）。 2.2 两阶段锁协议（2PL） 阶段1：加锁期 事务在执行过程中逐步申请所需的所有锁，但不能释放任何锁。 阶段2：解锁期 事务释放锁，且不能再申请新锁。 作用 ：保证冲突事务的串行化调度，但可能引发死锁（需结合死锁检测机制）。 2.3 时间戳排序（Timestamp Ordering） 核心规则 ： 每个事务分配唯一时间戳（如启动时间）。 数据项记录最后读/写时间戳。 若事务的读/写操作时间戳小于数据项的最后写时间戳，则拒绝操作并回滚事务。 示例 ： 数据X的最后写时间戳为T2。 事务T1（时间戳T1 <T2）试图写X，会被拒绝。 2.4 多版本并发控制（MVCC） 原理 ：为数据项维护多个版本，读操作访问旧版本，写操作创建新版本（参考已讲题目“MVCC实现原理”）。 优势 ：读不阻塞写，写不阻塞读。 三、冲突解决的具体策略 3.1 锁机制下的冲突处理 场景 ：事务T1和T2同时请求对同一数据的X锁。 步骤 ： 先请求锁的事务获得锁，后请求者进入等待队列。 若等待超时或死锁发生，回滚其中一个事务（如基于时间戳或锁等待图检测）。 3.2 MVCC下的冲突处理 写-写冲突 ： 事务T1和T2同时修改同一数据行。 系统检查数据行的当前版本是否已被提交： 若未被提交，后提交的事务回滚（如 PostgreSQL 的 SSI 隔离级别）。 若已提交，后提交的事务需重新执行修改（乐观锁机制）。 读-写冲突 ： 读操作访问快照版本，写操作生成新版本，两者互不阻塞。 3.3 乐观并发控制（OCC） 三阶段 ： 读阶段 ：事务读取数据并缓存修改。 验证阶段 ：提交前检查数据是否被其他事务修改。 写阶段 ：若验证通过，提交修改；否则回滚。 适用场景 ：读多写少、冲突概率低的系统。 四、实战案例：银行转账场景的并发控制 4.1 问题描述 事务A（转账100元）和事务B（查询余额）并发执行，需避免脏读和不可重复读。 4.2 解决方案（基于锁+隔离级别） 设置隔离级别为 Repeatable Read ： 事务B的读操作需加S锁，事务A的写操作需加X锁。 执行流程 ： 事务B加S锁读取余额（例如100元）。 事务A请求X锁被阻塞（因为S锁未释放）。 事务B再次读取余额（仍为100元），保证可重复读。 事务B提交后释放S锁。 事务A获取X锁，完成转账（余额变为0），提交后释放锁。 4.3 异常处理 若事务A等待锁超时，自动回滚转账操作。 若死锁发生，系统选择回滚权重小的事务（如占用资源少的事务）。 五、总结 低级隔离级别（如 Read Uncommitted） 性能高但风险大，适合只读统计分析。 高级隔离级别（如 Serializable） 安全性高但并发度低，需结合索引优化减少锁竞争。 现代数据库（如 MySQL/PostgreSQL） 通常混合使用锁、MVCC和乐观控制，根据场景动态调整策略。 通过以上机制，数据库系统能在高并发环境下平衡性能与一致性，确保事务安全执行。