【数据存储】交易流水：防刷对账与异议取证

实战应用：用在哪里

每一笔金币与物品流转都要留下可回放的凭证。传奇开服团队处理客诉时说得清哪一笔出了问题，靠的就是交易流水：谁、何时、把什么、给了谁、数量多少。工作室刷金与盗号销赃的排查，同样依赖这份完整的数据底账。

流水结构

function TradeLog.write(kind, fromId, toId, itemId, count)
    local row = {
        kind = kind, from = fromId, to = toId,
        item = itemId, n = count, at = os.time(),
    }
    tradeBuffer[#tradeBuffer + 1] = row
    if #tradeBuffer >= 500 then TradeLog.flush() end
end

function TradeLog.flush()
    QF_AppendLog("trade_" .. os.date("%Y%m%d"), tradeBuffer)
    tradeBuffer = {}
end

流水先进内存缓冲，攒满 500 条批量落盘，写入压力摊平，高峰期也不抖。按天分文件，月度归档压缩，保留 180 天，覆盖绝大多数客诉的追溯窗口。

对账校验

function TradeLog.audit(day)
    local inflow, outflow = {}, {}
    for _, row in ipairs(TradeLog.load(day)) do
        outflow[row.from .. ":" .. row.item] = (outflow[row.from .. ":" .. row.item] or 0) + row.n
        inflow[row.to .. ":" .. row.item] = (inflow[row.to .. ":" .. row.item] or 0) + row.n
    end
    for key, n in pairs(outflow) do
        if (inflow[key] or 0) ~= n and n > 10000 then
            QF_Alarm("对账差异 " .. key)
        end
    end
end

每日凌晨对前一天流水做进出对账，大额差异触发告警进 GM 面板。流水查询接口供客服按角色号反查，处理纠纷时直接出示记录，玩家对结论心服口服。流水字段带版本号，协议升级后新旧字段共存解析，历史数据永不失读。

验证与监控

落盘缓冲水位持续监控，单日流水体积环比翻倍即排查刷金行为。

踩坑记录

500 条缓冲的批量落盘在宕机场景最多丢一缓冲，金币类关键流水改成即时写，普通物品流水保留批量，分级落盘平衡了性能与安全。180 天保留期的压缩归档曾经解压失败，取证时打不开历史文件等于没有归档，压缩格式换成通用标准后定期做恢复演练。流水的字段版本号设计也来自教训，协议升级后旧记录缺新字段，解析器按版本分支读取，历史数据永不失读。流水的写入路径做过一次完整梳理，所有金币变动必须经过同一个记账函数，绕行的代码在评审中一律打回，入口的单一性保证了对账的完整性。取证工具做了脱敏导出，客服对外出示的记录隐去对方角色名只保留脱敏标识，隐私保护写进了取证流程。对账脚本的运行耗时从最初的半小时优化到六分钟，分表并行核对的改造让每日审计不再挤占凌晨的维护窗口。流水的写入路径做过一次完整梳理，所有金币变动必须经过同一个记账函数，绕行的代码在评审中一律打回，入口的单一性保证了对账的完整性。取证工具做了脱敏导出，客服对外出示的记录隐去对方角色名只保留脱敏标识，隐私保护写进了取证流程。对账脚本的运行耗时从最初的半小时优化到六分钟，分表并行核对的改造让每日审计不再挤占凌晨的维护窗口。

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