如何保障OLTP一致性

保障 OLTP（在线事务处理）系统的一致性，核心目标是：在并发、故障、网络异常等情况下，事务依然满足“正确性约束”（包括数据库约束、业务规则、跨系统状态一致等）。下面从理论模型 → 工程实践 → 常见陷阱三个层次说明。

一、理论基础：ACID 中的一致性靠什么保障

OLTP 的一致性（Consistency）不是数据库单独保证的，而是：

A（原子性）+ I（隔离性）+ D（持久性）共同支撑 C

• 原子性：要么全做，要么全不做
• 隔离性：并发事务互不干扰
• 持久性：提交后不丢
• 一致性：业务规则不被破坏（如余额不能为负）

✅ 一致性是“结果约束”，其他三者是“机制保障”

二、工程层面的关键保障手段

1. 事务边界设计（最重要）

原则：

• 一个业务操作 = 一个事务
• 事务内只做必要写入
• 不在事务中做：
  • 远程调用
  • 消息发送
  • 文件 IO
  • 人工交互

❌ 反例：

begin tx
  update account
  call payment service
  send kafka
commit

✅ 正例：

begin tx
  update account
commit
→ 再发消息 / 调用

2. 隔离级别选择（并发一致性）

常见 OLTP 实践：

• 金融：Serializable / 强锁
• 电商：RC + 应用层防并发
• 高并发：RC + 版本号 / 乐观锁

3. 并发控制机制

（1）悲观锁

select * from account where id=1 for update;

适合：

• 强一致性
• 低并发

（2）乐观锁（推荐）

update account set balance=?
where id=? and version=?

适合：

• 高并发
• 冲突少

4. 约束与规则下沉到数据库

✅ 用数据库“最后一道防线”：

• 主键 / 唯一索引
• 外键（视性能权衡）
• CHECK 约束
• 触发器（谨慎）

示例：

balance DECIMAL(18,2) NOT NULL CHECK (balance >= 0)

5. 分布式场景下的一致性（难点）

（1）单库 → 多库 / 微服务

问题：

• 跨服务事务
• 网络分区
• 部分失败

解决方案：

✅ 本地事务表 + 可靠消息

本地事务
→ 写消息表
→ 定时任务投递
→ 消费方幂等

✅ Saga（长事务）

• 正向操作
• 补偿操作
• 不保证“同时成功”，但保证“最终一致”

✅ TCC（强一致但复杂）

• Try
• Confirm
• Cancel

6. 幂等性（防重复破坏一致性）

任何写接口必须支持幂等：

• 唯一请求号
• 状态机
• 去重表

7. 故障与恢复保障

• WAL / Redo Log
• 主从同步（半同步）
• 崩溃恢复
• 定期校验（对账）

三、常见一致性破坏场景

四、一句话总结

OLTP 一致性 = 正确事务边界 + 合适隔离级别 + 并发控制 + 数据库约束 + 分布式补偿机制

如果你愿意，我可以：

• 用「银行转账」完整例子讲
• 对比 MySQL / Oracle / PostgreSQL
• 针对你当前系统给一致性方案建议