开服的流量是可以预测的:预约数乘转化率给出峰值在线的估计,容量规划把估计换算成机器的台数与配置。拍脑袋给的容量要么浪费要么崩,规划的核心是一组实测的配比系数。
---按预约数推算开服容量
function Capacity.plan(reserved)
-- 峰值在线 = 预约数 × 首日转化率
local peak = math.ceil(reserved * 0.35)
-- 单进程承载 3000 在线(实测基准)
local procs = math.ceil(peak / 3000)
return {
peakOnline = peak,
gameProcs = procs,
dbMemGB = math.ceil(peak * 0.008), -- 每在线 8MB 数据库内存
bandwidthMbps = math.ceil(peak * 0.15),
}
end
Capacity.show(Capacity.plan(200000))
-- 峰值 70000 在线:24 游戏进程、560GB 库存、10.5Gbps 带宽
推算链的三级系数全部来自实测:预约到首日在线的转化率 35%、单进程承载 3000 人、每在线的内存与带宽系数。系数的时效性靠每次开服的复盘校准,转化率随买量质量漂移,系数是活的不是刻在石头上的。峰值估计再乘 1.5 的安全系数,开服首日的爆量洪峰不击穿服务。
---在线水位与资源的实时配比监控
setontimerex(59, 30)
function Capacity.watch()
local online = grobalinfo(6)
local cpu = Capacity.nodeCpu()
-- 单进程超 2600 人即预警(承载的 87%)
if online / Capacity.procCount() > 2600 then
Ops.alert("在线密度逼近承载上限,准备扩容预案")
end
Capacity.record(online, cpu)
end
运行期的水位监控每 30 秒采样:在线密度逼近单进程承载的 87% 即预警,扩容预案从抽屉里拿出来演练而不是临场抓瞎。压测的校准每季度一次:压测机器人把单进程推到极限,承载系数从实测来而不是从文档来。大版本的容量复评进发布清单:新玩法改变了单玩家的消息量,系数要跟着重测。
开服复盘的预测偏差报表:预测峰值与实际峰值的偏差超 20% 回查系数;资源水位与在线数的联动曲线周报,异常的斜率变化提示系数漂移。
转化率曾经照抄别家 50%,自家买量质量更差,实际 32%,首日服务器挤爆三小时,系数自校准后不再外借。带宽的估计漏了攻城战的消息放大,千人攻城的瞬时带宽是日常的五倍,攻城场景单独配比。数据库的内存系数曾经按行数估算没算索引,索引吃掉四成内存,配比含索引项。
容量规划文档随每次开服归档,系数的演化史是团队的资产。扩容的自动化预案与水位告警联动,预警后的扩容动作有清单可循。容量评审进版本发布流程,玩法的消息量评估是评审的必答题。
本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付,内容以官方知识库与真实项目为出处,按版本持续修订。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
实战应用:用在哪里 盟重矿洞挖出的黑曜石除了堆仓库没有去向,矿工玩法缺一条消耗链。黑市商人每 4 小时换一批限时货架,6 个…
实战应用:用在哪里 盟重码头到沙巴克水路要 20 分钟,商船运货收益高但会被半兽海盗打劫,单人押船九死一生。码头护航做成对抗…
实战应用:用在哪里 拍卖行竞拍高峰,一件屠龙刀 1 秒能产生 60 条竞价事件,逐条 sendluamsg 下发,竞拍面板每…
实战应用:用在哪里 金盒转盘 8 格奖池,普通奖越来越疲,大奖既要概率递增又不能失控。动态权重轮盘:每抽一次普通奖权重缩减 …
实战应用:用在哪里 周年庆礼包开领 30 分钟,3000 名玩家多领了一份礼盒,回收与舆情处理耗掉两天。事故根因简单得刺眼:…
实战应用:用在哪里 一次回档让玩家的裁决之杖从强化 7 退回 5,口头承诺补偿却没有账可查。强化流水把每次强化的时间、道具、…