【数据存储】排行榜持久化：榜单内存与落盘双写

实战应用：用在哪里

等级榜、战力榜、财富榜，排行榜是玩家攀比心的放大器。榜单读多写少，全部放内存响应查询，定时落盘防丢失，重启后从磁盘恢复，玩家看到的榜单无缝衔接。

榜单更新

local BOARDS = {}
function Board.update(name, id, score)
    local b = BOARDS[name]
    local rec = b.index[id]
    if rec then
        rec.score = score
    else
        rec = { id = id, score = score }
        b.index[id] = rec
        b.list[#b.list + 1] = rec
    end
    b.dirty = true
end

index 哈希查重，list 数组排序，更新只标脏不重排，排名变化攒到结算时一次算清。同分按达标时间先到先得，比较器里带时间戳。

落盘与恢复

function Board.flush()
    for name, b in pairs(BOARDS) do
        if b.dirty then
            table.sort(b.list, b.cmp)
            QF_PersistJson("board_" .. name, b.list)
            b.dirty = false
        end
    end
end

function Board.restore(name)
    local list = QF_LoadJson("board_" .. name) or {}
    local b = { list = list, index = {}, cmp = BOARD_CMP[name] }
    for _, rec in ipairs(list) do b.index[rec.id] = rec end
    BOARDS[name] = b
end

每 10 分钟落一次脏榜，启动时逐榜恢复并重建索引。榜单前 100 名有奖励资格，结算时只处理头部区间。名次变化推送进客户端红点，上榜提示用 SL 全屏横幅播报，玩家攀比心直接拉满。

验证与监控

落盘字节数与榜单成员数每天核对，重启后抽样比对榜单前 10 名与落盘数据一致。

踩坑记录

榜单奖励资格只看前 100 名的设计让第 101 名成为最伤心的位置，结算快照曾经在边界上出过一次并发误差，两份榜单差一个名次，奖励发放以落盘版为准的规则写进了公告。恢复流程的兼容性测试覆盖了三个历史版本的数据，老版本缺字段的缺省值策略让三年前的存档也能平滑载入。榜单的查询全部走缓存，数据库只承担落盘与恢复两个动作，读写分离干净利落。榜单的并发更新曾出现过同帧同分的排序抖动，同分比较器里补了角色 ID 这个稳定因子，排序结果在任何一台机器上都一致。榜单数据的展示层做了分页缓存，前十名实时刷新，百名开外的页面走五分钟缓存，热点数据的处理力度按关注度分配。榜单接口的限流阈值单独设置，开榜瞬间的查询洪峰被令牌桶削平，核心的落盘与结算链路不受查询流量影响。榜单的并发更新曾出现过同帧同分的排序抖动，同分比较器里补了角色 ID 这个稳定因子，排序结果在任何一台机器上都一致。榜单数据的展示层做了分页缓存，前十名实时刷新，百名开外的页面走五分钟缓存，热点数据的处理力度按关注度分配。榜单接口的限流阈值单独设置，开榜瞬间的查询洪峰被令牌桶削平，核心的落盘与结算链路不受查询流量影响。

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