正排索引回答“这个玩家有什么”,倒排索引回答“谁有这个东西”。运营场景里反查需求极高频:排查裁决之杖的流通去向、回收某批问题道具、定位祝福油囤积者——每次都全服遍历背包是 O(n×m) 的灾难。倒排索引把方向反过来:以物品名为键、持有者集合为值,物品变动时同步维护,反查一次哈希命中 O(1)。索引不是查的时候建的,是数据变动时顺手维护的——这是所有索引设计的共同纪律。
倒排索引的写入与反查:获得时登记、失去时摘除,反查直取集合。示例代码如下:
local inverted = {}
local function indexAdd(itemName, owner)
local set = inverted[itemName]
if set == nil then
set = {}
inverted[itemName] = set
end
set[owner] = true
end
local function indexRemove(itemName, owner)
local set = inverted[itemName]
if set ~= nil then
set[owner] = nil
end
end
local function whoHas(itemName)
local set = inverted[itemName]
if set == nil then
return {}
end
local owners = {}
for owner in pairs(set) do
owners[#owners + 1] = owner
end
return owners
end
运营接入:裁决之杖流通排查一条函数完成。示例代码如下:
local function auditSword(actor)
actor = getplayerbyname(actor)
local owners = whoHas("裁决之杖")
local n = #owners
sendmsg(actor, 1, "裁决之杖当前流通 " .. n .. " 把,名单已入审计日志。")
end
本篇的新技术点是“写时维护”:indexAdd 与 indexRemove 挂在物品获得与失去的路径上,反查时零扫描——索引的准确性是靠每一次变动顺手维护出来的。
反查性能对照:全服 2000 人每人 40 格背包,暴力扫描一次反查 8 万次表访问、实测 24ms;倒排索引反查 0.001ms——快四个数量级。维护成本:每次物品变动多一次索引写 0.0004ms,日均变动 5 万次合计 20ms 摊在全天。索引内存:1.2 万个物品条目约 900KB,与全量背包快照同量级。
反查频率高的物品(高价物、问题道具)才值得维护索引,全量物品逐个建索引是内存浪费。索引与真实背包的一致性靠“变动即维护”保证,任何绕过加删入口的背包改动都会造成索引漂移——与差分存档同理,入口唯一是索引体系的地基。另外,持有者数量巨大(全服人手一瓶金创药)的物品,集合会很大,这类大众物品不建索引、查它们走全量统计。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
设计初衷 生存向属性的堆法单一:全堆血防就能站桩——挨打没有反馈,进攻方也没有取舍。反伤与荆棘设计:引入"被打反伤"机制并配…
设计初衷 活动做过就下架:老玩家念着当年的中秋灯会,新玩家永远错过——内容资产利用率极低,新玩法的开发压力却全压在增量上。活…
底层原理 一条业务请求(聊天、交易、入队)前面总挂着同样的横切逻辑:鉴权、限频、日志——每个入口各写一遍必然重复。中间件模式…
底层原理 求区间和(第 3 到 17 名的战力总和):前缀和预处理后查询 O(1),但单点更新要 O(n) 重算整张前缀表;…
设计初衷 玩家的江湖故事散落在各系统的角落:成就页有里程碑、战绩页有击杀、名人堂有荣誉——拼不出一个完整的"人"。玩家传记设…
业务场景 玩家跑商只能身上背货:负重有限、路线自己跑、货物分站下不去。马车货运封装:驿站雇马车按固定线路多点卸货,载重按马车…