关系数据库怎么实现读写分离

关系数据库实现**读写分离（Read/Write Splitting）**的核心思想是：
写操作走主库（Master），读操作走从库（Slave / Replica），从而提升系统的读性能和可用性。

下面从原理 → 常见架构 → 实现方式 → 注意事项系统说明。

一、基本原理

1. 主库（Master）

   • 负责：INSERT / UPDATE / DELETE
   • 数据变更通过复制机制同步到从库

2. 从库（Slave）

   • 负责：SELECT
   • 数据通常只读（可配置）

3. 复制方式

   • 异步复制（最常见，如 MySQL）
   • 半同步复制
   • 同步复制（性能低，强一致）

二、常见实现架构

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

在代码或 ORM 中区分数据源

示例（伪代码）：

if (sql.startsWith("SELECT")) {
    useSlaveDataSource();
} else {
    useMasterDataSource();
}

✅ 优点

• 灵活、可控
• 不依赖中间件

❌ 缺点

• 代码侵入性强
• 容易写错（如事务中读主库）

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

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

常见中间件：

• MySQL：MyCat、ShardingSphere、ProxySQL
• PostgreSQL：Pgpool-II、pgbouncer + 规则

示例（ShardingSphere）：

rules:
  readwrite-splitting:
    dataSources:
      master: ds_master
      slaves: ds_slave_1, ds_slave_2

✅ 优点

• 对应用透明
• 支持负载均衡、故障切换

❌ 缺点

• 架构复杂
• 有运维成本

3. 数据库驱动层实现

部分数据库驱动支持读写分离：

• MySQL Connector/J（配合 Proxy）
• PostgreSQL JDBC + 扩展

三、事务与一致性问题（重点）

1. 事务内必须走主库

BEGIN;
UPDATE account SET balance=100;
SELECT * FROM account;  -- 必须读主库
COMMIT;

否则可能读到旧数据。

✅ 解决方案：

• 事务中强制使用 Master
• 中间件自动识别事务

2. 主从延迟问题

写完后立刻读，可能读不到：

INSERT INTO order(...);
SELECT * FROM order WHERE id=1; -- 从库可能还没同步

✅ 解决方案：

• 写后强制读主库（Hint）
• 接受最终一致性
• 使用半同步复制

四、典型部署示例（MySQL）

        应用
         |
     ShardingSphere
     /      |      \
 Master   Slave1  Slave2

• 写：Master
• 读：Slave1 / Slave2（轮询）
• 复制：binlog → relay log

五、适用场景

✅ 适合：

• 读多写少
• 报表、查询类业务
• 高并发 Web 系统

❌ 不适合：

• 强一致金融交易
• 写后立即依赖读的场景（需特殊处理）

六、总结一句话

关系数据库读写分离 = 主库写 + 从库读 + 复制同步 + 路由控制

如果你愿意，我可以：

• 给你一个 Spring + MyBatis 读写分离示例
• 或针对 MySQL / PostgreSQL 具体配置
• 或讲 主从延迟如何彻底解决

你更想看哪一种？