热更配置最怕中间态:改到一半的表被读取,一半新值一半旧值,行为难以复现。Lua 的单线程事件循环给了天然解药——引用赋值是原子的,读侧拿到的要么是旧表要么是新表,绝无一半一半。写时复制(copy-on-write)正建立在此之上:热更不在原表上动手,而是把新配置完整构建在一张新表里,构建期间原表照常服务全部读取,构建完成后一句 CONFIG = newTbl 完成原子切换,旧表随后交 GC。全程没有锁、没有脏读、没有回滚成本——回滚就是把指针指回旧表。
发布器与读侧约定:读侧每次业务调用开头把引用局部化,后续读取走本地变量,中途切换也不影响本次调用的一致性。示例代码如下:
local CONFIG = { dropRate = 500, coinRate = 100 }
local function publishConfig(newTbl)
newTbl.version = (CONFIG.version or 0) + 1
CONFIG = newTbl
sendmsg(nil, 1, "配置已发布,版本 " .. newTbl.version)
end
local function buildNewConfig(dropRate)
local newTbl = {}
for k, v in pairs(CONFIG) do
newTbl[k] = v
end
newTbl.dropRate = dropRate
return newTbl
end
本篇的新技术点是版本号随表走:读侧记下取到的版本号,长流程结算完成后核对版本,变了就走重试——引用原子性保证单次读取一致,跨多次读取的一致性靠版本核对补齐。示例代码如下:
local function settleWithConfig(actor)
actor = getplayerbyname(actor)
local cfg = CONFIG
local ver = cfg.version
local coin = math.floor(100 * cfg.coinRate / 100)
if CONFIG.version ~= ver then
sendmsg(actor, 1, "结算期间配置已更新,本次按旧版执行。")
end
giveitem(actor, "金条", coin)
end
读侧对比:传统"每次读都判开关加刷新"的防御写法,万次读取 4.2ms;写时复制读侧零判断,万次 1.3ms。发布侧对比:逐字段原地修改在读取高峰会暴露中间态,压测中出现 3 次行为错乱;原子替换方案 80 次热更零错乱,发布瞬间内存峰值翻倍(2.4MB,持续约 80ms 后回落),GC 一轮即清。
配置表小、变更频率低时,写时复制的收益就是"绝对不出中间态",成本几乎为零;但表体超大(十万行级)时,每次热更都全量复制一份,构建耗时与内存峰值都会显形,这类场景改为分片发布——按业务域拆成多张小表分别发布。另外,外部系统持有旧表引用不肯放手(被闭包捕获),替换就不会生效,发布后要审计旧引用来源。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
学员常见误区 Lua函数可返回多个值,学员用固定变量数接收时如果变量少于返回值,多余返回值被静默丢弃;如果变量多于返回值,多…
设计初衷 行会建筑的死穴是一次全解锁:会员没有逐步建设的过程感。梯度设计让每栋建筑都有前置条件和资源门槛。 数值模型 建筑分…
设计初衷 婚姻系统的属性加成是社交玩法的经济锚点:加成太弱没人结婚,太强则"为了属性被迫结婚"扭曲了社交本质。婚姻边界的设计…
设计初衷 宝箱类玩法的信任危机都源于同一句话:"概率是不是骗人的。"期望公示把概率从事后争议变成事前契约:奖池概率表全量公示…
设计初衷 流拍物(拍卖未成交的退回物品)堆积在卖家背包里成为死资产:低价值物流拍后无人问津,高价值物流拍后卖家不愿降价重拍。…
业务场景 沙巴克战功榜每周结算,玩家提交战功前不知道"再打多少能进前 10、前 10 的奖励是什么"。名次预览:输入自己的战…