一、模式概述：什么是读写分离

读写分离是一种简单而被广泛采用的数据库架构模式。其核心理念是：将所有写操作（INSERT、UPDATE、DELETE）路由到唯一的主库（Primary）；将所有读操作（SELECT）分发到一个或多个只读副本（Read Replica）。

这种"一主多从"的部署形态，能在不显著增加复杂度的前提下，把数据库的读吞吐量提升数倍乃至数十倍，是应对"读多写少"业务（电商详情页、社交内容流、报表查询）最常用的扩展手段。

二、典型架构对照图

下图以"应用服务 → 数据库层"两侧视角，对比单库模式与读写分离模式的请求走向。

三、主从复制示意

主库以日志流（binlog / WAL / OpLog）方式将数据变更推送给所有只读副本，整个过程为异步或半同步。

四、典型业务流程示例

以电商下单场景为例，展示读写请求在读写分离架构中的完整流转路径。

五、核心痛点：复制延迟（Replication Lag）

读写分离最大的隐患在于复制延迟。由于主从间数据传播是异步的，在网络抖动、主库写入压力大、副本节点负载高、长事务阻塞等场景下，副本数据可能比主库落后数百毫秒到数十秒，极端情况下可达数分钟。

典型故障场景：用户刚提交一个订单，紧接着刷新页面查看订单状态。如果该读请求被路由到尚未同步到最新数据的副本，用户将看到"订单不存在"的诡异结果，造成用户困惑甚至投诉。这种场景对应的一致性要求被称为 「读己之写一致性」（Read-After-Write Consistency / Read-Your-Writes）。

常见的延迟成因

六、缓解复制延迟的三大方案

核心代码示例（伪代码）

# 路由决策器：根据上下文决定 SQL 走主库还是副本
def route_query(query, session):
    # 1) 写操作 → 主库
    if query.is_write():
        session.last_write_ts = now()
        return primary_db.execute(query)

    # 2) 写后短窗（5 秒内）的读 → 主库
    if session.last_write_ts and (now() - session.last_write_ts) < 5:
        return primary_db.execute(query)

    # 3) 标记为延迟敏感的关键查询 → 主库
    if query.has_hint("READ_FROM_PRIMARY"):
        return primary_db.execute(query)

    # 4) 通过复制位点判定副本是否追上目标位置
    replica = load_balancer.pick_replica()
    if replica.gtid >= session.last_seen_gtid:
        return replica.execute(query)

    # 5) 副本落后 → 回退主库
    return primary_db.execute(query)

七、读写分离的演进路径

读写分离并非"开箱即用"，往往随业务发展分阶段引入，演进顺序如下：

八、带来的核心收益

九、何时使用 · 何时慎用

十、关键要点回顾

📌 核心思想：让"读"水平扩展，"写"保持单点强一致。

📌 核心机制：主库 → binlog/WAL/OpLog → 副本异步回放。

📌 核心难点：复制延迟，会破坏「读己之写」一致性。

📌 核心方案：延迟敏感读走主库 / 写后短窗走主库 / 位点判定。

📌 核心边界：读多写少、能容忍最终一致才是它的舞台。