玩家在副本中掉线 10 秒,重连后 Boss 掉落了、队友发了奖励——这些“掉线窗口”内的消息不能丢。序号补发让重连玩家补齐错过的关键消息,是断线重连体验的收尾环节。
每个会话维护一个环形缓冲,保存最近 N 条关键消息(带单调递增序号):
local buffers = {}
function Session.pushCritical(uid, msg)
local buf = buffers[uid]
if not buf then buf = { first = 1 }; buffers[uid] = buf end
local seq = buf.first + #buf - 1
buf[#buf + 1] = { seq = seq, body = msg }
if #buf > 200 then -- 环形上限
table.remove(buf, 1)
buf.first = buf.first + 1
end
end
-- 重连时客户端上报 lastSeq,服务端补发之后的消息
function Session.resend(uid, lastSeq)
local buf = buffers[uid]
for _, m in ipairs(buf or {}) do
if m.seq > lastSeq then sendTo(uid, m.body) end
end
end
缓冲 200 条覆盖绝大多数短掉线;超长掉线超出缓冲的部分由“全量状态快照”兜底(重连握手后的第四步)。
客户端对每条收到的关键消息记录 lastSeq 并周期回执(每 5 秒一次),服务端据此收缩缓冲。回执丢失不产生副作用——序号只增不回退,服务端按客户端上报值保守清理。
补发与实时发送可能产生重复(重连瞬间两条路径都发了),客户端按消息序号去重(已处理的最大序号之后的才处理)。去重与幂等(业务单号)双保险之后,断线补偿不再产生重复发放。实测 996 单服模拟 200 次随机掉线:补发成功率 100%,无重复奖励产生。补偿系统的验收就三句话:掉线不丢关键消息、重连不产生重复、缓冲有上限。
补发的顺序保证:服务端按序号升序补发,客户端按序号去重与排序后处理,乱序与重复都被吸收。补发消息同样带序号,客户端确认机制照常工作。补发的流量做限速(每秒五十条),避免重连瞬间的补发风暴挤占正常消息通道,大缺口分多轮补齐。
补发消息的标记:补发的消息体里带 replay 标志,客户端可以区分实时消息与补发消息,界面提示用不同样式(如补发奖励标注补发字样),玩家对到账来源一目了然。
本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付,内容以官方知识库与真实项目为出处,按版本持续修订。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
学员常见误区 Lua函数可返回多个值,学员用固定变量数接收时如果变量少于返回值,多余返回值被静默丢弃;如果变量多于返回值,多…
设计初衷 行会建筑的死穴是一次全解锁:会员没有逐步建设的过程感。梯度设计让每栋建筑都有前置条件和资源门槛。 数值模型 建筑分…
设计初衷 婚姻系统的属性加成是社交玩法的经济锚点:加成太弱没人结婚,太强则"为了属性被迫结婚"扭曲了社交本质。婚姻边界的设计…
设计初衷 宝箱类玩法的信任危机都源于同一句话:"概率是不是骗人的。"期望公示把概率从事后争议变成事前契约:奖池概率表全量公示…
设计初衷 流拍物(拍卖未成交的退回物品)堆积在卖家背包里成为死资产:低价值物流拍后无人问津,高价值物流拍后卖家不愿降价重拍。…
业务场景 沙巴克战功榜每周结算,玩家提交战功前不知道"再打多少能进前 10、前 10 的奖励是什么"。名次预览:输入自己的战…