数据库并发如何保证一致性

在数据库系统中，并发（多事务同时访问） 如果缺乏控制，会导致数据不一致问题，如：

• 脏读（Dirty Read）
• 不可重复读（Non-repeatable Read）
• 幻读（Phantom Read）
• 丢失更新（Lost Update）

保证并发一致性的核心目标，是让多个事务并发执行时，结果等价于“某种串行执行”的结果（通常称为 可串行化）。

下面从理论 → 实现机制 → 实践方案系统说明。

一、理论基础：事务的 ACID

保证一致性依赖于事务特性：

• A（Atomicity）：事务要么全做，要么全不做
• C（Consistency）：数据库始终处于合法状态
• I（Isolation）：并发事务相互隔离
• D（Durability）：提交后数据永久保存

一致性是目标，隔离性是实现手段之一

二、并发控制的核心机制

1. 锁机制（Locking）

（1）共享锁（S Lock）

• 多个事务可同时读
• 阻止写

（2）排他锁（X Lock）

• 只允许一个事务写
• 阻止其他读和写

（3）两阶段锁协议（2PL）

• 加锁阶段：只能加锁，不能释放
• 解锁阶段：只能释放，不能加锁

✅ 2PL 可保证可串行化

2. 隔离级别（Isolation Levels）

级别越高，一致性越强，但并发性能越差

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

核心思想：

• 写操作不阻塞读
• 每个事务看到的是“快照版本”

典型实现：

• 每行数据带版本号 / 事务 ID
• 读历史版本，写新版本

✅ 提高并发性能
✅ 避免读写冲突

MySQL InnoDB、PostgreSQL 都使用 MVCC

4. 乐观并发控制（OCC）

适用于冲突少的场景：

1. 读数据（不加索）
2. 提交时检查是否被修改
3. 若冲突 → 回滚重试

常见方式：

• 版本号（version）
• 时间戳
• CAS（Compare And Swap）

5. 悲观并发控制

假设冲突频繁：

• 读就加锁
• 写必排他

适合：

• 强一致
• 高冲突业务（库存、账户）

三、典型问题与解决方案

1. 丢失更新

场景：

A 读 = 100
B 读 = 100
A 写 120
B 写 90  ← A 的更新丢失

解决：

• 加排他锁
• 使用 UPDATE ... SET balance = balance - 10
• 乐观锁（version）

2. 幻读

场景：

• 事务 A 查询“年龄 > 30”的记录
• 事务 B 插入一条符合的记录
• A 再次查询，结果变了

解决：

• Serializable 隔离级别
• 间隙锁（Gap Lock，InnoDB）

四、分布式 / 高并发场景

1. 数据库层

• 主从复制 + 读写分离
• 分库分表
• 分布式事务（2PC / TCC / Saga）

2. 应用层

• 幂等设计
• 分布式锁（Redis / ZooKeeper）
• 消息队列最终一致性

五、实践建议（总结）

✅ 优先使用 MVCC + 合理隔离级别
✅ 写冲突业务用 悲观锁或乐观锁
✅ 高并发读多写少 → 乐观 + 版本号
✅ 强一致金融场景 → Serializable / 分布式事务

如果你有具体场景（如：秒杀、库存、订单），我可以给针对性方案。