【数据存储】读写分离：查询走从库的延迟应对

实战应用：用在哪里

主库一扛写一扛读迟早撑不住：读写分离把查询分流到从库，主库专注写入。分离的代价是从库复制延迟——刚充值的元宝在从库查不到，玩家秒变"数据丢失"。延迟的应对策略是读写分离方案能否成事的分水岭。

分流的路由规则

---查询路由：写后读回源主库
local route = { master = DB.master(), slave = DB.slave() }

function DB.route(sql, userId)
    local recentWrite = WriteTrack.lastWriteAt(userId)
    -- 写后 5 秒内的读走主库，规避复制延迟
    if recentWrite and os.time() - recentWrite < 5 then
        return route.master
    end
    if sql:sub(1, 6) == "SELECT" then
        return route.slave
    end
    return route.master
end

路由的三条规则：写操作永远走主库、纯读走从库、写后 5 秒内该玩家的读强制回主库。第三条是关键——支付到账、元宝变动后的即时查询走主库，玩家看不到自己刚买的东西的客诉源头即被掐断。WriteTrack 记录每个玩家的写时间戳，内存里的一个小表，开销可忽略。

延迟的监控与降级

---从库延迟探测：超过阈值降级单库
setontimerex(44, 10)
function DB.checkLag()
    local lag = DB.slaveLagSeconds()
    if lag > 3 and not DB.degraded then
        DB.degraded = true
        Ops.alert("从库延迟 " .. lag .. " 秒，读流量降级回主库")
    elseif lag <= 1 and DB.degraded then
        DB.degraded = false
        Ops.alert("从库延迟恢复，读流量回归从库")
    end
end

每 10 秒探测一次从库的复制延迟，超过 3 秒把读流量整体降级回主库——主库多扛一阵读好过玩家看到旧数据。降级与恢复都有告警，从库的健康状态在运维群里可见。排行榜与战报这类容忍秒级延迟的查询即使降级也走从库：沙巴克战报晚 10 秒无人在意，元宝余额晚 1 秒就是客诉，路由按数据的敏感度分级。

验证与监控

主从延迟的分位监控与降级次数周报，降级频繁说明从库规格不足；写后读回主库的命中率统计，策略有效性的直接证据。

踩坑记录

写后 5 秒的窗口曾经没覆盖异步发货，支付回调写主库后 6 秒玩家查订单走从库仍旧看不到，写标记的时效改为跟随业务事务提交。降级的恢复曾经没有迟滞，延迟在阈值附近抖动导致读流量来回横跳，恢复阈值加 1 秒的缓冲带。从库曾经承接了报表任务的大查询，磁盘 IO 打满拖高复制延迟，报表查询隔离到独立的统计库。

上线要点

敏感度分级清单由业务评审确认：余额、订单、背包为敏感级，排行、战报、公告为容忍级。路由层对业务透明，SQL 不感知去向，切库只动配置。从库的规格与主库对齐，延迟的根因多数是从库硬件缩水。

本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付，内容以官方知识库与真实项目为出处，按版本持续修订。