读写分离方案如何设计

读写分离（Read/Write Splitting）是提升数据库系统性能、扩展性和可用性的常用架构方案。下面从设计目标、总体架构、关键设计点、常见方案、注意事项、典型示例几个方面系统说明。

一、设计目标

读写分离的核心目的是：

1. 提升性能
   • 读多写少场景下，通过多个只读副本分担查询压力
2. 提升扩展性
   • 读能力可水平扩展（增加从库）
3. 提高可用性
   • 主库故障可切换，从库可继续提供读服务
4. 解耦业务
   • 读写职责清晰，便于优化和维护

二、总体架构

基本结构

        应用层
          |
    读写分离中间件 / 客户端逻辑
          |
   -------------------
   |                 |
主库（写）        从库（读）
（Master）        （Slave / Replica）

• 主库（Master）
  • 负责写操作（INSERT / UPDATE / DELETE）
  • 通常也支持少量读
• 从库（Slave / Replica）
  • 负责读操作（SELECT）
  • 通过主从复制同步数据

三、关键设计点

1. 数据同步机制

常见方式：

同步模式：

• 异步复制（常用）
  • 性能好，但存在延迟
• 半同步复制
  • 数据安全性更高
• 同步复制
  • 强一致，性能差

✅ 大多数互联网系统选择 异步复制 + 容忍短暂延迟

2. 读写路由策略

（1）基于 SQL 类型

• SELECT → 从库
• INSERT / UPDATE / DELETE → 主库

⚠️ 注意：

• 事务中的读是否走主库？
• 刚写入的数据是否立即可读？

（2）基于事务

• 事务内所有操作走主库
  • 防止读不到刚写入的数据（读写一致性）

（3）基于 Hint / 注解

例如：

/* FORCE_MASTER */ SELECT * FROM orders;

用于：

• 强一致读
• 管理后台等特殊场景

3. 数据一致性问题

主从延迟问题

• 写主库 → 从库可能延迟几十毫秒到几秒
• 可能导致：
  • 刚下单查不到订单
  • 刚改状态查还是旧状态

✅ 解决方案：

1. 写后读走主库
2. 关键业务强制主库读
3. 缓存兜底（如 Redis）
4. 延迟敏感业务避免强依赖从库

4. 中间件 vs 客户端实现

方案一：中间件层（推荐）

如：

• MySQL：ProxySQL、MaxScale、ShardingSphere-Proxy
• PostgreSQL：Pgpool-II

✅ 优点：

• 对应用透明
• 统一管理
• 易监控、易切换

❌ 缺点：

• 增加一层架构
• 中间件本身需高可用

方案二：客户端实现

• 应用层根据数据源路由
• Spring + MyBatis + 注解

✅ 优点：

• 架构简单
• 无额外组件

❌ 缺点：

• 侵入业务
• 规则分散，难维护

5. 高可用设计

主库高可用

• 主库故障自动切换（Failover）
• 常见方案：
  • MHA
  • Orchestrator
  • Kubernetes + Operator
  • 云数据库自带 HA

从库高可用

• 多从库
• 从库下线自动摘除
• 读流量自动迁移

6. 连接池与负载均衡

• 从库之间：
  • 轮询
  • 权重
  • 最少连接数
• 防止：
  • 某从库被打爆
  • 长事务占用连接

四、典型实现示例

Spring + MyBatis + 读写分离（简化）

application.yml
dataSources:
  master:
  slave1:
  slave2:

• 通过 AOP 拦截 DAO
• 根据方法名或注解选择数据源

@Transactional
public void createOrder() {
    // 主库
}

@ReadOnly
public Order getOrder() {
    // 从库
}

五、适用场景与不适用场景

✅ 适合

• 读多写少
• 查询 QPS 高
• 对一致性要求不是强实时

❌ 不适合

• 强一致事务系统（金融核心）
• 写多读少
• 主从延迟无法接受

六、常见坑

1. 事务中读从库导致数据不一致
2. 忽略主从延迟
3. 从库数量过多导致复制压力
4. 中间件单点故障
5. 没有监控复制延迟

七、总结

一个成熟的读写分离设计应包含：

• 明确的主从复制机制
• 合理的读写路由策略
• 对一致性的清晰定义
• 高可用和故障切换
• 监控与告警（复制延迟、连接数）

如果你愿意，我可以：

• 给你画一张架构图
• 针对 MySQL / PostgreSQL / 云数据库 给具体方案
• 结合实际业务（如电商、支付）设计 读写分离 + 缓存 方案