【数据存储】主从延迟：读写分离的秒级延迟应对

实战应用：用在哪里

读写分离上线后，玩家刚领完奖励刷新面板却查不到，主库写入还没同步到从库，延迟高峰有两秒。应对方案分两层：写后读走会话粘性，60 秒内的查询强制回主库；旁路延迟哨兵每分钟探测一次，延迟超 3 秒直接告警值班。读写分离的收益是查询吞吐翻倍，代价是多了一份需要治理的延迟，方案的目标是把延迟关进业务无感的笼子。

写后读的会话粘性

发放奖励等写操作顺带盖一个时间戳，读取入口判断时间戳：60 秒内有过写入的账号强制走主库，超时自动回落从库。

local function afterGrant(actor)
    setplayvar(actor, "HUMAN", "STICKY_TS", os.time())
end
local function readSource(actor)
    local ts = tonumber(getplayvar(actor, "HUMAN", "STICKY_TS") or "0")
    if os.time() - ts < 60 then
        return "master"
    end
    return "slave"
end

延迟哨兵与告警阈值

外部对账脚本把探测到的主从延迟写回系统变量，引擎侧定时器每 60 秒读一次，延迟超过 3 秒给值班发邮件，连续毛刺合并为一条告警。

setontimerex(183, 60)
function ontimer183()
    local lag = tonumber(getsysvar("REPL_LAG") or "0")
    if lag > 3 then
        sendmail("#运维老张", 913, "主从延迟告警", "当前主从延迟 " .. lag .. " 秒，写后读已粘性覆盖", "")
    end
end

验证与监控

粘性验证：写入后 59 秒内查询全部走主库，61 秒后回落从库；延迟注入 5 秒核对告警邮件触发；毛刺场景连续两次 3.5 秒抖动不触发告警。粘性标记以账号为粒度，账号切换设备后仍然生效，不受连接重建影响。写后读粘性只覆盖发放与充值两条关键链路，聊天与排行等弱一致场景照常走从库，分寸感是这套方案的关键。监控主从延迟的分钟级曲线与粘性命中率，命中率长期高于三成说明从库同步能力要扩。

踩坑记录

STICKY_TS 最初用落盘变量，写放大明显，活跃账号每次发放都多一次磁盘写，改成内存键后重启窗口期的粘性短暂失效，可接受。粘性时长 60 秒是从延迟 P95 反推的，从库扩容后延迟降到百毫秒级，粘性时长同步缩短到 20 秒，不能一劳永逸。毛刺告警没做合并，延迟抖动一小时响了九次，值班开始无视这条告警，连续三次超限才合并发送。玩家充值到账但面板没显示的投诉，根因一半都出在写后读走错了库，粘性覆盖后这类投诉清零。