数据库读写分离完全指南:从一次"用户改完资料刷新又变回去、刚下单订单列表却没有"看懂主从一致性

2022 年我负责一个用户量正在往上涨的系统。数据库单机越来越吃力,尤其是读压力——各种列表页、详情页的查询,把数据库 CPU 压得很高。我做了一个很标准的优化:读写分离。一个主库负责写,挂两个从库负责读,主库的数据通过主从复制同步到从库。我做得很直接:在代码里判断 SQL ——写操作走主库,读操作走从库。本地一测——顺极了:写进去的数据,转头就能从从库读出来,主库压力肉眼可见地降了下来。我心里很踏实:"读写分离嘛,不就是写走主、读走从。"可等它真正上线、面对真实的并发用户,一串诡异的 bug 冒了出来。第一种:有用户改完个人资料,点"保存",页面一刷新,改的内容又变回了旧的——再过几秒刷新,才又对了。第二种:有用户刚下了一单,跳到"我的订单"列表,列表里却没有这一单;他以为下单失败,又下了一次,结果重复下了两单。第三种最隐蔽:这些 bug 时有时无,我本地怎么都复现不出来。我盯着这些"薛定谔的 bug"想了很久才彻底想明白,第一版错在一个根本的认知上:我以为"读写分离,就是写操作走主库,读操作走从库"。这句话本身没错,它精确地描述了读写分离的动作。可它漏掉了一件最致命的事——主库的数据同步到从库,不是"瞬间完成"的。主从之间隔着一段复制延迟:你刚写进主库的数据,要过一会儿(几毫秒、几十毫秒,主库一忙甚至几秒)才会出现在从库上。在这段延迟里,你从从库读,读到的就是还没更新的旧数据。用户"改完又变回去""下完单看不到",根子全在这里。真正的读写分离,核心不是"把读和写分开",而是在分开之后,管好主从延迟带来的数据一致性问题。这篇文章就把读写分离梳理一遍:为什么"写主读从"上线就出诡异 bug、主从复制延迟到底从哪来、写后立即读怎么保证一致、不同业务场景该选什么一致性级别、从库故障了怎么办,以及事务路由、延迟监控、缓存叠加这些把读写分离真正做对要避开的坑。

问题背景

先把那串诡异 bug 的现象和我的误判讲清楚,后面所有的设计都是冲着纠正这个误判去的。

现象:一个"写走主库、读走从库"的读写分离系统,上线后冒出一串时有时无的 bug:用户改完资料一刷新又变回旧值;刚下的单在订单列表里查不到;这些 bug 在本地几乎无法复现。

我当时的错误认知:"读写分离就是写操作走主库、读操作走从库,分开就完事了。"

真相:主库到从库的数据同步存在复制延迟——刚写入主库的数据,要过一小段时间才同步到从库。在这段延迟窗口里读从库,会读到旧数据。读写分离真正的工程量,在于管理这段延迟:写后立即读要强制走主库、事务内的读必须走主库、按业务对一致性的不同要求分级路由、监控复制延迟、处理从库故障转移。把读写分开只是开头,把一致性管住才是关键。

要把读写分离做对,需要几块认知:

• 为什么"写主读从"会出诡异 bug——主从之间有复制延迟;
• 复制延迟——它从哪来,为什么无法彻底消除;
• 写后读一致性——写完立即要读的场景必须强制读主;
• 一致性分级——不同业务对"读到旧数据"的容忍度不同;
• 从库故障、事务路由、延迟监控这些工程坑怎么处理。

一、为什么"写主读从"上线就出诡异 bug

先把这件最根本的事钉死:读写分离把"写"和"读"指向了两个不同的物理库,而这两个库之间的数据同步是异步的、有时间差的;只要你在"写入主库"和"数据同步到从库"之间的这个时间差里去读从库,你读到的就是旧数据——这不是 bug,这是异步复制的固有特性。

下面这段代码,就是我那个"上线出诡异 bug"的第一版路由——它只看 SQL 是读还是写:

def get_connection(sql: str):
    # 反面教材:只按"读/写"决定走主库还是从库
    sql_head = sql.strip().split()[0].upper()
    if sql_head in ("INSERT", "UPDATE", "DELETE"):
        return master_pool.get()          # 写:走主库
    else:
        return slave_pool.get()           # 读:走从库
    # 破绽:它默认"写完主库,从库就立刻有了"。可主从复制是
    # 异步的 —— 写完主库的下一刻去读从库,从库可能还没同步到,
    # 读回来的是旧数据。"写后立即读"这个场景,它彻底没考虑。

这段代码逻辑上挑不出错,在本地测试时也表现完美。它的问题不在代码本身,而在一个被忽略的前提:它默认"写操作在主库完成的那一刻,这条数据在从库上也立刻可见了"。可这个前提根本不成立。主从复制的真实过程是:主库执行完写操作、记进自己的 binlog;从库有一个线程把 binlog 拉过去;再有一个线程在从库上重放这些操作。这三步,每一步都要花时间——它是异步的。于是那串诡异 bug 就有了解释:用户改资料,UPDATE 走主库成功了;页面立刻刷新、发起查询,这个 SELECT 走了从库——可此时主库的这条更新还没同步过去,从库返回的是旧值。下单看不到订单,同理。而它在本地复现不出来,是因为本地主从几乎零延迟、没有并发——延迟问题只在真实负载下才暴露。问题的根子清楚了:读写分离不能只看"读还是写",必须看"这次读,能不能容忍读到一点点旧数据"。

二、主从复制延迟:它从哪来,为什么消不掉

要解决延迟带来的问题,得先正视延迟本身——它从哪来,以及一个反直觉的事实:它无法被彻底消除。延迟主要来自三个环节:主库写完 binlog、从库 IO 线程拉取 binlog、从库 SQL 线程重放。其中最容易成为瓶颈的是重放:主库可能是多个连接并发在写,而从库的重放历史上是单线程的——主库一上量,从库就追不上,延迟越积越大。所以,做读写分离的第一件事,是能随时看到这个延迟有多大:

-- 在从库上执行,查看这个从库落后主库多少
SHOW SLAVE STATUS;

-- 重点看这几个字段:
-- Slave_IO_Running:    Yes 表示拉 binlog 的线程正常
-- Slave_SQL_Running:   Yes 表示重放 binlog 的线程正常
-- Seconds_Behind_Master: 【核心】这个从库落后主库多少秒
--                        0 表示基本同步;持续 > 0 说明在堆积延迟

这条 SQL 是给人看的。要让程序随时知道延迟、并据此做路由决策,得把它包成一个函数——后面做从库健康检查、故障降级,靠的全是它:

import pymysql


def check_slave_status(slave_dsn: dict) -> dict:
    """连到一个从库,读它的复制状态,换算成程序能用的健康信息。"""
    conn = pymysql.connect(**slave_dsn)
    try:
        with conn.cursor(pymysql.cursors.DictCursor) as cur:
            cur.execute("SHOW SLAVE STATUS")
            row = cur.fetchone()
    finally:
        conn.close()

    if row is None:                       # 这台根本没配主从复制
        return {"alive": False, "delay": None}
    delay = row.get("Seconds_Behind_Master")
    return {
        # 两个复制线程都得是 Yes,这台从库才算在正常同步
        "alive": (row.get("Slave_IO_Running") == "Yes"
                  and row.get("Slave_SQL_Running") == "Yes"),
        # delay 为 None 说明复制已经断了,按"延迟无穷大"处理
        "delay": delay if delay is not None else 10 ** 9,
    }

有了 check_slave_status,就能定时巡检所有从库——延迟一旦异常飙升,你要第一时间收到告警:

ALERT_DELAY_THRESHOLD = 5          # 延迟超过 5 秒,就告警


def monitor_all_slaves(slaves: list):
    """定时巡检:逐个检查从库的复制延迟,超阈值立即告警。"""
    for dsn in slaves:
        status = check_slave_status(dsn)
        if not status["alive"]:
            send_alert(f"从库 {dsn['host']} 复制已中断")
            continue
        if status["delay"] > ALERT_DELAY_THRESHOLD:
            # 延迟飙升 = 所有走这台从库的读都在返回旧数据,
            # 这是一个【正在发生的故障】,不是一个慢
            send_alert(f"从库 {dsn['host']} 延迟 {status['delay']}s 超阈值")

Seconds_Behind_Master 这个数字,就是你整个读写分离系统的健康脉搏。它正常时应该贴近 0;一旦它持续 > 0 并往上涨,说明从库正在被主库甩开——这时候所有走从库的读,读到的数据都可能是几秒前的。要缓解延迟,可以做一些事:比如开启从库的并行重放(让重放不再单线程)、给从库更好的硬件、避免主库上的大事务(一个大事务在从库上要完整重放完,期间延迟飙升)。但你必须接受一个事实:这些手段能把延迟压小,压不到 0。只要复制是异步的,延迟就客观存在。所以正确的思路不是"消灭延迟",而是"承认延迟存在,然后让那些受不了延迟的读,根本不去碰从库"。这就引出了下一个最关键的设计。

三、写后读一致性:写完立即要读,就强制读主

那串 bug 的共同模式非常清晰:都是"写完一个数据,紧接着就要把它读出来"——改完资料要刷新看、下完单要看列表。这个场景有个专门的名字,叫写后读一致性(read-your-writes)。它的解法朴素而有效:既然写后立即读受不了延迟,那就让这种读,根本别走从库,直接走主库。怎么识别"写后立即读"?一个实用的办法:一个用户做了写操作后的一小段时间内,他自己的读,全部强制走主库。

import time

# 记录每个用户最近一次写操作的时间戳
_last_write = {}
FORCE_MASTER_WINDOW = 3.0          # 写后 3 秒内,该用户的读强制走主库


def mark_write(user_id: str):
    """用户发生写操作时,打一个时间戳。"""
    _last_write[user_id] = time.time()


def should_read_master(user_id: str) -> bool:
    """判断这个用户当前的读,该不该强制走主库。"""
    last = _last_write.get(user_id)
    if last is None:
        return False
    # 关键:用户刚写过(在延迟窗口内),他的读必须走主库 ——
    # 因为从库此刻很可能还没同步到他刚写的数据。
    return (time.time() - last) < FORCE_MASTER_WINDOW

有了这个判断,路由就不再只看读写,而是多了一层"这个用户最近写过没有"的考量:

def route_connection(sql: str, user_id: str):
    """改进的路由:读操作也要看用户是否在写后延迟窗口内。"""
    sql_head = sql.strip().split()[0].upper()
    if sql_head in ("INSERT", "UPDATE", "DELETE"):
        mark_write(user_id)               # 写:走主库,并打时间戳
        return master_pool.get()
    # 读:默认走从库,但写后窗口内的用户强制走主库
    if should_read_master(user_id):
        return master_pool.get()          # 强制读主,避开延迟
    return slave_pool.get()

这个设计的精髓,是它不再天真地认为"读就该走从库",而是区分了"能容忍旧数据的读"和"不能容忍旧数据的读"。一个刚刚改过资料的用户,在接下来的几秒里,他的读大概率就是要看自己刚改的东西——这种读必须走主库。而一个很久没做过任何写操作的用户,他在浏览列表、看详情,读到的数据哪怕旧一点点也无伤大雅——这种读放心走从库。这里的 FORCE_MASTER_WINDOW(强制读主的时间窗口)要略大于你实际观测到的主从延迟:延迟通常几十毫秒,窗口设个 2-3 秒,就足够覆盖。当然,生产环境里这个"最近写过"的状态不该放在进程内存里,而该放进 Redis 这种共享存储——否则多个服务实例之间看不到彼此。写后读的问题解决了,但"强制读主"不能滥用——否则从库就白挂了。

四、一致性分级:不是所有读都需要最新数据

"强制读主"虽然解决一致性,但它有代价:每多一个读走主库,主库就多一分压力——而给主库减压恰恰是你做读写分离的初衷。如果什么读都往主库塞,那读写分离就形同虚设了。所以正确的做法是分级:根据每个业务场景对"数据新鲜度"的真实要求,把读分成几档,匹配不同的路由策略。

from enum import Enum


class Consistency(Enum):
    STRONG = "strong"        # 强一致:必须最新,走主库
    SESSION = "session"      # 会话一致:看得到自己的写,写后窗口内走主
    EVENTUAL = "eventual"    # 最终一致:容忍旧数据,放心走从库


def route_by_consistency(level: Consistency, user_id: str):
    """按业务声明的一致性级别路由 —— 把选择权交给调用方。"""
    if level == Consistency.STRONG:
        return master_pool.get()                  # 永远走主库
    if level == Consistency.SESSION:
        # 会话一致:只保证用户看得到【自己】刚写的数据
        return (master_pool.get() if should_read_master(user_id)
                else slave_pool.get())
    return slave_pool.get()                        # 最终一致:走从库

这三档,对应了三类截然不同的业务场景。强一致(STRONG):用在绝对不能错的地方——比如下单时扣库存、支付时查余额,这种读必须是最新的,哪怕牺牲性能也要走主库。会话一致(SESSION):用在"用户要看到自己刚做的操作"的地方——改资料、发评论、下单后看列表,只要保证他看得到自己的写就行,别人晚一两秒看到无所谓。最终一致(EVENTUAL):用在绝大多数的浏览型场景——看文章列表、看商品详情、看排行榜,这些数据晚几秒更新用户根本察觉不到,放心走从库。这套分级的意义在于:它把"这次读能不能容忍旧数据"这个只有业务方才清楚的判断,显式地交给了业务方去声明——而不是由路由层一刀切。绝大部分读落在最终一致,从库的价值就发挥出来了。一致性的事理顺了,但还有一个现实问题:从库本身也会坏。

五、从库故障与负载均衡:别让一台从库拖垮全局

你挂了两个从库,这意味着要面对两个新问题:其一,读请求怎么在两个从库之间分配;其二,万一一个从库挂了(宕机,或者延迟大到不可用),怎么办。如果路由代码还傻乎乎地把读往一个已经挂了的从库送,那这部分用户的读就全报错了。所以,选从库这件事,必须带上健康检查:

import random

SLAVES = ["slave-1", "slave-2"]
MAX_ACCEPTABLE_DELAY = 5           # 延迟超过 5 秒的从库,视为不可用


def healthy_slaves() -> list:
    """筛掉宕机的、以及延迟过大的从库。"""
    result = []
    for s in SLAVES:
        status = check_slave_status(s)        # 探测从库状态
        if not status["alive"]:
            continue                          # 宕机的,直接排除
        if status["delay"] > MAX_ACCEPTABLE_DELAY:
            continue                          # 延迟过大的,也排除 ——
            # 一个延迟几十秒的从库,数据太旧,读它还不如不读
        result.append(s)
    return result


def pick_slave():
    """从健康的从库里挑一个;一个都没有,降级回主库。"""
    healthy = healthy_slaves()
    if not healthy:
        # 关键:所有从库都不可用时,读降级到主库 —— 宁可
        # 给主库加压,也不能让读直接失败。这是最后的兜底。
        return master_pool.get()
    return slave_pool.get(random.choice(healthy))

这段代码的关键,在 healthy_slaves 对"健康"的双重定义:一个从库算健康,不仅要活着,还要延迟在可接受范围内。一个延迟了几十秒的从库,虽然没宕机,但它返回的数据太旧了——读它意义不大,该果断踢掉。还有一个关键兜底:当所有从库都不可用时,pick_slave 会降级回主库。这是一个重要的取舍——主库被读压力打满,虽然难受,但系统还能转;而读直接失败,是用户立刻就能感知的事故。两害相权,降级读主。从库的负载和故障也兜住了,最后是几个绕不开的工程坑。

六、工程坑:事务路由、延迟监控与缓存叠加

五块设计之外,还有几个工程坑,不处理就会在生产上出事。坑 1:一个事务里的所有 SQL,必须全部走主库。这是一条铁律。一个事务里常常既有写又有读(比如"查一下库存够不够,够就扣减")。如果路由按单条 SQL 判断,把事务里的 SELECT 派去了从库,就彻底乱套——从库看不到这个未提交事务里刚写的数据,事务的隔离性被打破。所以路由的判断单位,不能只是单条 SQL,还要看"当前是否在一个事务中"。

def route_in_transaction(sql: str, in_transaction: bool, user_id: str):
    """事务内的所有 SQL —— 无论读写 —— 一律走主库。"""
    if in_transaction:
        # 关键:事务里的 SELECT 也必须走主库。否则从库看不到
        # 这个事务里未提交的写,事务的一致性就被破坏了。
        return master_pool.get()
    return route_connection(sql, user_id)      # 非事务,才按读写分流

坑 2:复制延迟必须做监控和告警。Seconds_Behind_Master 要持续采集、设告警阈值。延迟一旦异常飙升,你要第一时间知道——因为这意味着所有走从库的读都在返回旧数据,是个正在发生的故障。坑 3:小心"缓存 + 从库"的双重延迟叠加。如果你的读先查缓存、缓存没有再查从库,那么一份数据的"旧",可能是缓存的过期时间和主从延迟叠加起来的——用户看到的数据,比你以为的还要旧。写操作后,不仅要考虑主从延迟,还要主动让相关缓存失效。坑 4:从库不只用来扛在线读,还能分流"重活"。那些又慢又重的查询——报表统计、数据导出、给大数据平台抽数——放到从库上跑,可以彻底避免它们拖累主库上的在线交易。甚至可以专门挂一个从库只干这些重活。坑 5:主库本身仍是单点。读写分离分摊的是读压力,写仍然全压在主库一台机器上。读写分离不解决写的扩展性——那是分库分表要解决的另一个问题。下面这张图,把一次读请求如何被路由串起来:

关键概念速查

避坑清单

1. 读写分离不能只按读写分流,异步复制有延迟,写后立即读从库会读到旧数据。
2. 主从复制延迟来自 binlog 拉取和重放,只能压小消不掉,要正视它的存在。
3. 持续监控 Seconds_Behind_Master,它持续大于 0 说明从库正在堆积延迟。
4. 写后读一致性场景,用户写后一段时间内他自己的读要强制走主库。
5. 强制读主的时间窗口要略大于实际主从延迟,通常设两三秒。
6. 别什么读都强制走主库,否则读写分离形同虚设,要按一致性级别分级路由。
7. 选从库前要做健康检查,剔除宕机的和延迟过大的从库。
8. 所有从库不可用时读要降级回主库,宁可主库加压也不能让读直接失败。
9. 一个事务内的所有 SQL 包括 SELECT 必须全走主库,否则破坏事务一致性。
10. 读写分离只分摊读压力,写仍单点压在主库,写的扩展要靠分库分表解决。

总结

回头看那串"用户改完资料刷新又变回去、刚下单订单列表却没有"的诡异 bug,以及我后来在读写分离上接连踩的坑,最该记住的不是某一段路由代码,而是我动手前那个想当然的判断——"读写分离,就是写走主库、读走从库"。这句话错在它把"分离"这个动作,当成了事情的全部。我以为读写分离是一个纯粹的"分流"问题:把读和写这两股流量,引到两个库就完事了。可它根本不是一个分流问题,而是一个一致性问题。你一旦把数据放到两个物理库上,你就不得不面对一个新冒出来的、原本不存在的东西——这两份数据之间的不一致。读写分离这件事想清楚的,正是这个:它表面上是在给数据库做减负(让从库分担读),本质上却是在用"一致性"换"性能"——你得到了读的扩展能力,付出的代价是"从库的数据可能是旧的"。真正的工程,就是管理这笔交易:哪些读付得起这个代价(走从库),哪些读付不起(走主库)。

所以做读写分离,真正的工程量不在"判断 SQL 是读还是写"那几行分流代码上。那几行,任何教程的第一页就教完了。真正的工程量,在于你要为"主从之间一定有延迟"这个事实,处理掉它引发的所有连锁后果:用户写完要立即看到,你就得用写后读一致性,让他这几秒的读强制走主;不同业务对旧数据的容忍度天差地别,你就得做一致性分级,把判断权交给业务方;从库会宕机、会延迟飙升,你就得做健康检查和故障降级;事务里读写混在一起,你就得让整个事务锁定主库。这篇文章的几节,其实就是顺着这条思路展开的:先想清楚"写主读从"为什么会出诡异 bug,再正视复制延迟这个消不掉的事实,然后用写后读一致性接住"写完立即读"的场景,用一致性分级避免无脑读主,用健康检查兜住从库故障,最后是事务路由、延迟监控、缓存叠加这几个把读写分离做扎实的工程细节。

你会发现,读写分离的思路,和现实里一家公司怎么管理"总部档案"和"分部副本"完全相通。公司的权威档案都在总部(这是主库),所有的修改、登记都必须回总部办(写走主库)。可总部人手有限,每天来查档案的人太多,于是公司在各地设了分部,定期把总部的档案复印一份送到分部,大家就近去分部查(读走从库)。这套办法大大缓解了总部的压力——但它带来一个新麻烦:分部的副本,永远比总部慢一拍。一个员工今早刚在总部改了档案,下午跑到分部去查,分部的副本还没更新,他查到的还是旧的(写后读不一致)。一家管理混乱的公司,会对此不闻不问;而一家管理得好的公司会怎么做?他们会立个规矩:"凡是你今天刚改过的档案,这几天要查,请直接回总部查"(写后读强制走主);他们会区分档案的紧要程度——"涉及钱、涉及法律的,一律以总部为准;一般的参考资料,查分部的副本就行"(一致性分级);他们还会盯着各分部副本的更新进度,发现某个分部已经落后总部好几天,就暂时不让大家去那个分部查了(从库延迟检查)。分部副本制度的成败,从来不在于你复印了多少份,而在于你有没有想清楚:哪些事查副本无妨,哪些事必须回总部。

最后想说,读写分离做没做扎实,差距永远不会在测试环境暴露——本地的主从几乎零延迟、又没有并发,你写完立刻能从从库读到,你会觉得"写主读从"这四个字已经是全部。它只在真实的、有并发、有负载、主从延迟实实在在地存在的生产环境里才显形。那时候它会用最难堪的方式给你结账:做不好,你会像我一样,被一串本地死活复现不出的"薛定谔 bug"折磨——用户的修改诡异地回滚,刚下的订单凭空消失,你查遍代码却找不到错在哪;而做对了,无论主从延迟是几十毫秒还是偶尔抖到几秒,你的系统都稳稳地运转:该看到最新数据的读精准地走了主库,能容忍旧数据的读安心地走了从库,主库的压力降了下来,而用户从头到尾感觉不到背后藏着两个库。所以别等诡异 bug 找上门,在你决定"把读分出去"的那一刻就该想清楚:我的每一种读,到底能不能容忍读到一点点旧数据?容忍不了的,我怎么让它走主?这几个问题都有了答案,你的读写分离才不只是一个"看起来分流了"的架构图,而是一套既扛住了读压力、又守住了一致性的可靠系统。

—— 别看了 · 2026