【案例复盘】沙巴克之夜卡顿排查：从出包量定位广播风暴

实战应用：用在哪里

某周六沙巴克攻城战打到一半，全服延迟跳到两秒，宫门口成片瞬移。复盘完整还原定位过程：从在线数确认规模没变，从出包量锁定广播风暴，2400秒内止血。这套排查路径值得每个服务端团队演练。

现象与数据采样

第一反应不是改代码，而是先取数：在线数没涨，排除玩家涌入；消息出口采样发现每秒出包从平峰的六百条涨到八千二百条，来源高度集中在行会击杀播报。

local snap = 0
setontimerex(61, 10)
function ontimer61()
    local online = grobalinfo(6)
    setsysvar("MONITOR_ONLINE", online)
    snap = snap + 1
end

击杀播报的原始代码每次行会战死亡都sendcentermsg，宫门口每秒十几人阵亡，几百人同屏，包量指数放大。

local function onGuildKill(dead, guild)
    sendcentermsg("【" .. guild .. "】" .. dead .. " 在沙巴克宫前阵亡")
end

止血动作与修复

先上紧急开关把击杀播报从全服降级为本行会可见，包量三分钟内回落到九百条，延迟恢复正常。修复版改成十秒合并窗口：同一场次只汇总阵亡数与阵地变化，全服只看战局，不看每个名字。

验证与监控

复盘后加了两道保险：出包速率超过每秒三千条自动告警；攻城脚本上线前必须在千假人环境压测600秒的合并窗口。这次之后同类的公告风暴再没发生过。

踩坑记录

排查时最大的干扰项是有人在宫门口放火墙，AOI同步量确实涨了，但只占增量的一成五，先入为主去优化AOI会白干两小时，数据要按消息类型分桶再看。紧急开关用setsysvar实现，改完立即生效，但当时没人记得开关位置，翻文档用了六分钟，开关清单要贴在值班手册。sendcentermsg的降级方案降的是可见范围，不是不发，行会内部士气信息仍然保留，这是玩家体验与性能的折中点。