【入门夯实】开服挤爆：预约转化的容量预估教训

学员常见误区

新区开服前收了 3000 个预约，按"预约的人一半会来"的经验值备了 1200 人承载——开服当天实际涌入 2550 人（转化率 85%），排队四小时，世界频道全是骂声。经验值拍脑袋是容量预估的大忌：预约来源不同转化率天差地别，官网预约的转化可能只有三成，送开局礼包的活动预约转化却接近满额。错误场景：

local capacity = bookings * 0.4

0.4 这个系数没有来源、没有分层，赌错了就是首日事故。

正确姿势

转化系数表：预约按来源分层（官网、礼包活动、主播口播），每层用历史实测的转化系数计算预估人数，取系数上限留安全余量。规范写法。示例代码如下：

local CONV = { site = 0.5, gift = 0.9, live = 0.8 }
local bookings = { site = 1000, gift = 1500, live = 500 }
local function estimate()
    local total = 0
    for k, n in pairs(bookings) do
        total = total + n * CONV[k]
    end
    return math.ceil(total)
end

分层计算：官网 500 加礼包 1350 加口播 400，预估 2250 人；再按系数上限复核一次（全部按 0.9 算是 2700），承载按两次估算的较大值准备——2550 人的实际涌入落在预估区间内，不会再被打个措手不及。示例代码如下：

local cap = math.max(estimate(), math.ceil(#bookings and 2700))
sendmsg(nil, 1, "按 " .. cap .. " 人配置开服承载。")

引擎验证

三步验证：分层估算法回代入上次事故数据（3000 预约、礼包占大头），预估 2500 上下与实际 2550 吻合；把礼包层系数误设 0.3，估算掉到 1400 与实际严重偏离——系数的准确性就是预估的准确性；水位联动验证：在线数达预估八成时自动触发扩容告警。

举一反三

预约分段的进一步用法：按预约时间分层（早鸟与临开服预约的转化率不同），临门预约的转化往往更高，系数表分得越细预估越准。示例代码如下：

local function estimateByTime(earlyN, lateN)
    return earlyN * 0.45 + lateN * 0.85
end