【数据存储】会话缓存：在线数据的生命周期管理

实战应用：用在哪里

玩家在线期间的数据分两层：要持久的（背包、等级）与临时的（当前目标、BUFF 剩余、会话的临时标记）。会话缓存承载临时层，玩家的下线即是缓存的清算点——生命周期管理错了，脏数据与内存泄漏一起找上门。

会话的结构

---会话缓存：玩家的临时数据域
local Sessions = {}

function Session.open(uid)
    Sessions[uid] = {
        at = os.time(),
        buff = {},      -- 临时状态
        temp = {},      -- 会话标记
    }
end

function Session.close(uid)
    local s = Sessions[uid]
    if not s then return end
    -- 下线的清算：需要持久的写回，其余丢弃
    for _, key in ipairs(s.persistKeys or {}) do
        DB.save(uid, key, s.temp[key])
    end
    Sessions[uid] = nil
end

会话的开与关是缓存的生与死：登录时开域，下线时清算——需要留存的临时数据在清算点写回数据库，其余的一次性清空。清算清单的显式维护（persistKeys）让「哪些要留」是决定而非巧合，临时数据的去向有账可查。会话域的读写接口统一：业务不直接摸 Sessions 表，get 与 set 走门面，清理的钩子在门面里统一挂。

泄漏的防线

---泄漏的防线：孤儿会话的定时清扫
setontimerex(96, 300)
function Session.sweep()
    local now = os.time()
    for uid, s in pairs(Sessions) do
        -- 超过 10 分钟无心跳的会话视为孤儿
        if now - s.at > 600 then
            Ops.log("清理孤儿会话: " .. uid)
            Session.close(uid)
        end
    end
end

function Session.touch(uid)
    local s = Sessions[uid]
    if s then s.at = os.time() end
end

孤儿会话是泄漏的主源：掉线事件丢失的会话没人清理，内存的占用只进不出。心跳的触碰（touch）让活跃会话刷新时间戳，定时的清扫把 10 分钟无心跳的会话判为孤儿强制清算——清扫的兜底让下线事件的可靠性不再是内存安全的前提。会话域的容量监控：在线数与会话数的比值应当恒等于一，比值漂移即是泄漏的信号。缓存的分层规则：读多写少的引用型数据（配置快照）进进程级缓存，玩家维度的临时状态进会话域，跨玩家的共享状态进全局的受控表——三层各管各的生命周期。

验证与监控

会话数与在线数的比值监控，比值恒一的健康线；清扫的量与下线事件的量的差值统计，差值即掉线事件的丢失率。

踩坑记录

清算的写回曾经在数据库抖动时失败，临时数据静默丢失，写回的重试队列补上。会话的键曾经用玩家名字，改名的玩家会话错位，键统一为不可变的 userId。业务直接摸 Sessions 的写法让清理的钩子被绕过，门面的强制收口靠代码评审。

上线要点

会话域的容量预估随在线峰值走，清扫的周期按内存的水位自适应。需要写回的清单由业务登记，清单外的数据默认不持久——宁丢临时的不算持久的账。下线的清算与顶号的移交复用同一份逻辑，两条路径一套清算。

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