【实战案例】沙巴克攻城战的一次掉线潮应对

实战应用：用在哪里

某周五晚八点的沙巴克攻城战，开战 10 分钟内在线人数从 1800 掉到 1400——不是玩家流失，是网关的发送队列打满引发批量掉线。这场掉线潮的应对过程，是高并发场景下运维响应的实战样本。

定位过程

-- 网关的发送队列水位监控
function Gateway.queueDepth()
    local maxDepth = 0
    for _, conn in pairs(connections) do
        maxDepth = math.max(maxDepth, conn.sendQueueLen or 0)
    end
    return maxDepth
end

掉线潮的表象是玩家批量断线，根因排查从监控入手：网关发送队列的水位在攻城爆发期冲到上限，队列满的连接被网关主动断开。攻城战的战斗广播量是平时的二十倍，逐包下发的旧策略在千人同屏前撑不住了。

应急与根治

-- 应急：广播降级为合并包
function Siege.broadcastMerged(actions)
    local pack = table.concat(actions, "|")
    for _, viewer in ipairs(viewers) do
        sendmsg(viewer, 2, pack)
    end
end

应急动作三步：战斗广播切换合并包模式（20 条动作并 1 包）、非战斗消息（聊天表情）延迟 500 毫秒下发、观战人数限流。10 分钟后队列水位回落，掉线停止。根治方案在赛后实施：AOI 视野过滤 + 合帧下发 + 广播优先级三层改造，压测验证千人战场的广播量下降八成。

验证与监控

网关队列水位进入常驻监控，水位 70% 即预警，攻城战的容量预案按新的广播基线重算。

踩坑记录

应急的合并包分隔符与玩家名冲突，有个叫"a|b"的角色让合并包解析错乱，分隔符的转义处理随后补上。限流观战的策略被玩家误解为区别对待，公告里对限流的解释文案比技术方案本身更重要。

上线要点

高并发活动的容量评估必须含广播带宽的测算，人数乘以动作数的理论峰值与实测对齐。应急预案的开关要提前配置并演练，事故现场才没有时间写代码。复盘的改进项要有负责人与期限，掉线潮的三个改进项在两周内全部完成。