数据库OLTP如何做读写分离

在数据库 OLTP（在线事务处理） 场景中做 读写分离，核心目标是：
写请求走主库（Master），读请求走从库（Slave / Replica），从而提升系统吞吐和并发能力。

下面从 架构思路 → 常见方案 → 关键技术点 → 典型问题 系统说明。

一、读写分离的基本架构

        应用
         |
   ---------------
   |             |
 写请求        读请求
   |             |
 主库(Master)  从库(Slave)
   |             |
   复制(同步/异步)

• 主库：负责 INSERT / UPDATE / DELETE
• 从库：负责 SELECT
• 主从之间通过 binlog / redo log 进行数据复制

二、常见读写分离实现方式

1. 应用层读写分离（最常用）

做法

• 代码中明确区分：
  • 写操作 → 主库数据源
  • 读操作 → 从库数据源
• 使用多数据源配置（如 Spring 的 AbstractRoutingDataSource）

优点

• 控制精细
• 不依赖数据库中间件

缺点

• 对业务代码有侵入
• 需要自己处理从库延迟

✅ 适合：中小型系统、定制化强的业务

2. 中间件层读写分离（推荐）

通过数据库中间件自动路由：

示例（ShardingSphere）

rules:
  - !READWRITE_SPLITTING
    dataSources:
      master:
        writeDataSourceName: ds_master
        readDataSourceNames:
          - ds_slave1
          - ds_slave2

优点

• 业务无感知
• 支持负载均衡、故障转移

缺点

• 架构复杂度提升

✅ 适合：中大型 OLTP 系统

3. 数据库驱动层（有限使用）

• 如 MySQL Connector/J 的 readFromMasterWhenNoSlaves
• 能力较弱，一般不单独使用

三、OLTP 场景下的关键技术点

1. 主从复制延迟（最重要）

问题

• 写完后立即读，可能读不到最新数据

解决方案

• 强一致读：
  • 关键业务读主库（如余额、订单状态）
• 最终一致读：
  • 非关键读走从库（如列表、统计）
• 延迟监控 + 从库剔除

2. 事务内读写一致性

原则

同一事务内，读写必须走主库

否则会出现：

• 事务未提交
• 从库读不到
• 数据不一致

✅ 中间件通常会自动处理

3. 从库负载均衡

• 轮询
• 权重
• 延迟优先

4. 高可用与故障切换

• 主库宕机：
  • MHA / Orchestrator / MGR
• 从库宕机：
  • 自动剔除

四、OLTP 读写分离最佳实践

✅ 读写分离 不是所有读都走从库
✅ 按业务重要性分级
✅ 写后强一致读走主库
✅ 使用中间件降低复杂度
✅ 监控复制延迟（核心指标）

五、典型不适用场景

• 强一致性事务系统（金融核心账务）
• 写多读少系统
• 单库已能支撑的场景（避免过度设计）

如果你愿意，我可以：

• 给你一个 Spring Boot + ShardingSphere 读写分离示例
• 或针对 MySQL / PostgreSQL / Oracle 具体方案讲细节