引擎的 setontimer 是一条注册一条调度:千人在线每人挂两条个人定时器,就是两千条管理记录,每秒两千次回调分派。时间轮(timing wheel)把海量延迟任务收敛进一个驱动器:60 槽环形数组、指针每秒推进一格;注册任务时按剩余秒数对 60 取余定位槽位、除 60 得圈数,指针扫到该槽时圈数为零就执行、否则减一圈再放回。注册 O(1)、每秒推进 O(1)——任务数量再大,驱动成本恒定,多出来的只是数组条目。这就是操作系统内核定时器同款思想的 Lua 版。
60 槽时间轮:注册与每秒推进两件套。示例代码如下:
local wheel = {}
local pointer = 0
local function wheelAdd(delaySec, taskName)
local slot = (pointer + delaySec) % 60
local ring = math.floor(delaySec / 60)
wheel[slot] = wheel[slot] or {}
local bucket = wheel[slot]
bucket[#bucket + 1] = { ring = ring, task = taskName }
end
local function wheelTick()
pointer = (pointer + 1) % 60
local bucket = wheel[pointer]
if bucket == nil then
return
end
local alive = {}
for _, job in ipairs(bucket) do
if job.ring <= 0 then
sendmsg(nil, 1, "时间轮触发任务:" .. job.task)
else
job.ring = job.ring - 1
alive[#alive + 1] = job
end
end
wheel[pointer] = alive
end
驱动挂全局定时器:setontimerex(88, 1) 每秒一跳,QF 侧按 ontimerex88() 响应。示例代码如下:
local function ontimerex88()
wheelTick()
end
本篇的新技术点是圈数抵扣:延迟 130 秒的任务落在 (指针+10)%60 槽、圈数 2,指针扫它两圈才执行——60 个槽装下任意长的延迟。
同一负载(千人各 2 条秒级任务)两种方案对比:个人定时器 2000 条注册,每秒分派 2000 次回调,实测调度耗时 1.8ms/秒;时间轮 1 条驱动定时器加每秒扫一个槽(平均 33 条),总耗时 0.06ms/秒,调度成本降 97%。注册侧:setontimer 单次约 0.02ms,wheelAdd 约 0.001ms,批量注册快一个数量级。内存:60 个槽桶的空表底座约 6KB,任务条目每条 60 字节。
时间轮的精度等于槽粒度:60 槽秒级驱动只能承诺秒级误差,毫秒级定时需求不适用。任务总量小的服务端(几十条定时器)直接 setontimer 更省心,引入时间轮纯属过度设计。任务要跟随玩家会话自动取消的场景(下线即失效),个人定时器天然具备,时间轮得自己实现注销——按 taskName 加挂主键再扫除即可,但那是另一层复杂度。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
学员常见误区 Lua函数可返回多个值,学员用固定变量数接收时如果变量少于返回值,多余返回值被静默丢弃;如果变量多于返回值,多…
设计初衷 行会建筑的死穴是一次全解锁:会员没有逐步建设的过程感。梯度设计让每栋建筑都有前置条件和资源门槛。 数值模型 建筑分…
设计初衷 婚姻系统的属性加成是社交玩法的经济锚点:加成太弱没人结婚,太强则"为了属性被迫结婚"扭曲了社交本质。婚姻边界的设计…
设计初衷 宝箱类玩法的信任危机都源于同一句话:"概率是不是骗人的。"期望公示把概率从事后争议变成事前契约:奖池概率表全量公示…
设计初衷 流拍物(拍卖未成交的退回物品)堆积在卖家背包里成为死资产:低价值物流拍后无人问津,高价值物流拍后卖家不愿降价重拍。…
业务场景 沙巴克战功榜每周结算,玩家提交战功前不知道"再打多少能进前 10、前 10 的奖励是什么"。名次预览:输入自己的战…