金币、功勋这类关键数值,单账本一旦被静默改坏(bug 写错、内存篡改),没有任何报警——账本自己不会喊冤。双写校验给关键值配一本影子账:主账正常读写,影子账在每次主账变更时同步写入同一新值;读取时比对两本账,不一致即触发告警并封存操作。双写的成本是每次变更多一次写入,换来的是"账本被改必然暴露"——篡改者很难记得还有一本影子账,即便记得,双账同时改出同样的错值,概率上也远低于单点篡改。
双写读写封装:setCoin 双账同写,getCoin 比对校验,不一致即告警。示例代码如下:
local function setCoin(actor, value)
actor = getplayerbyname(actor)
if value < 0 or value > 2100000000 then
sendmsg(actor, 1, "金币数值越界,写入被拒。")
return
end
setplayvar(actor, "HUMAN", "CoinMain", value, 1)
setplayvar(actor, "HUMAN", "CoinShadow", value, 1)
end
local function getCoin(actor)
actor = getplayerbyname(actor)
local main = getplayvar(actor, "HUMAN", "CoinMain")
local shadow = getplayvar(actor, "HUMAN", "CoinShadow")
if main ~= shadow then
sendmsg(actor, 1, "金币账目异常,已封存待审。")
setplayvar(actor, "HUMAN", "CoinLock", 1, 1)
return tonumber(shadow) or 0
end
return tonumber(main) or 0
end
消费入口走双写封装,直写主账的路径在审计里无所遁形。示例代码如下:
local function payCoin(actor, amount)
actor = getplayerbyname(actor)
local coin = getCoin(actor)
if coin < amount then
sendmsg(actor, 1, "金币不足。")
return
end
setCoin(actor, coin - amount)
sendmsg(actor, 1, "支付 " .. amount .. " 金币完成。")
end
本篇的新技术点是"读取即审计":比对发生在每次读取时,账目异常在最短路径上暴露,而不是等月底对账。
写路径成本:单账写 0.0018ms,双账写 0.0031ms(多一次落库写入),金币类操作日均 8 万次合计多 0.1 秒,无感。泄露检测实测:人为用后台直改主账(绕过封装),下一次 getCoin 立刻发现不一致并封存——暴露延迟从"直到对账日"缩短到"下一次读取"。双账内存翻倍:每玩家金币两份共 16 字节,千人 16KB。
双写只给关键数值(金币、功勋、点券),普通变量(称号、成就进度)不值得翻倍写入。影子账的局限要说透:它能发现不一致,不能自动判定哪一本是对的——恢复以影子账为准只是策略选择,前提是影子账的写入路径与主账全然隔离。另外所有写路径必须强制走封装,任何一处绕过封装的直写都会让双写体系形同虚设,代码评审时把"直写 CoinMain"列入红线。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
设计初衷 活动排期凭感觉:周末连开三个重头活动,玩家疲于奔命参与率反跌;工作日大空窗,在线曲线断崖。玩法日历设计:以周为单位…
设计初衷 网络波动掉线让玩家损失战斗进度:世界BOSS打到一半掉线,回来残局已清;副本中掉线,门票作废。掉线补偿设计把掉线当…
底层原理 祭坛围一圈火把、世界BOSS周身一圈水晶,这类环绕阵列需要等角度分布坐标:圆心 (cx, cy)、半径 r、数量 …
设计初衷 排行榜只有顶端可见:进不了前一百的玩家在榜上查无此人,名次没有参照,追赶没有对象。影子榜设计:为每名玩家生成以自己…
业务场景 打错路线或主力减员后想重来,队长单方面重置常引发队内矛盾,误触重置的投诉也不少。投票重置封装:重置需全队表决、同意…
底层原理 存档在写入与传输中可能因意外损坏,读档前需要一道完整性判定。校验和的思路:把数据逐字节累加压缩成一个整数指纹,读档…