数据库OLTP怎么保证一致性

在数据库领域，OLTP（联机事务处理）系统要保证一致性（Consistency），通常不是靠单一机制，而是由事务的 ACID 特性共同保障，其中一致性是目标，其他机制是手段。

下面从概念 → 实现机制 → 常见手段系统说明。

一、什么是一致性（Consistency）

在 ACID 中：

一致性：事务执行前后，数据库都必须处于“合法状态”，满足所有约束、规则和业务逻辑。

注意：

• 一致性 ≠ 原子性
• 一致性是结果约束
• 原子性、隔离性、持久性是实现手段

例子：

• 转账：A 少 100，B 必须多 100
• 库存：不能超卖
• 账户余额不能为负（业务规则）

二、OLTP 如何保证一致性（核心机制）

1️⃣ 事务（Transaction）+ ACID

OLTP 依赖事务作为基本单位：

BEGIN;
UPDATE account SET balance = balance - 100 WHERE id = A;
UPDATE account SET balance = balance + 100 WHERE id = B;
COMMIT;

• Atomicity：要么全做，要么全不做
• Isolation：并发不互相破坏
• Durability：提交后不丢
• ✅ 最终 → Consistency

2️⃣ 约束层保证（数据库级）

数据库自身提供“硬约束”：

• 主键 / 唯一约束
• 外键约束
• NOT NULL / CHECK
• 默认值

CHECK (balance >= 0)

➡ 防止非法状态写入

3️⃣ 并发控制（隔离性 → 一致性）

高并发下，靠隔离机制防止不一致：

常见方案

• 锁（Lock）
  • 行锁、表锁
• MVCC（多版本并发控制）
  • 读不阻塞写，写不阻塞读
• 事务隔离级别
  • Read Committed
  • Repeatable Read
  • Serializable

示例问题防止：

• 脏读
• 不可重复读
• 幻读
• 丢失更新

4️⃣ 原子提交机制

确保“半成功”不可能存在：

• Undo Log：回滚用
• Redo Log：崩溃恢复用
• 两阶段提交（2PC）（分布式）

5️⃣ 应用层业务规则（逻辑一致性）

数据库只能保证“结构一致”，业务一致靠应用：

例如：

• 订单状态机
• 账户流水对账
• 幂等控制

下单 → 扣库存 → 创建订单 → 支付

任何一步失败 → 整体回滚或补偿

6️⃣ 分布式 OLTP 的一致性（进阶）

在分布式数据库中：

• CAP 权衡
• 通常选：CP（强一致）
• 技术：
  • Raft / Paxos
  • 分布式事务（2PC / TCC）
  • 一致性协议

三、一致性 ≠ 实时一致

需要区分：

OLTP 通常是强一致或近强一致

四、总结一句话

OLTP 通过事务 + 约束 + 并发控制 + 日志恢复 + 应用逻辑，共同保证数据库在任意时刻都处于业务合法状态，这就是一致性。

如果你愿意，我可以：

• 用转账例子画执行流程
• 对比 OLTP vs OLAP 一致性差异
• 讲 MySQL / Oracle / PostgreSQL 具体实现