《MMO 服务器开发》18.3 单服承载数字
玩法系统接进来之后,单服到底能带多少同屏玩家?本节用 B 层基准本机实跑:每个玩家每 tick 做移动、施法、掷掉落三件事,由小到大扫 50 到 1000 同屏玩家,落 JSON 并给出每 tick 成本表,再与卷一的端到端承载数字对照,说明为什么玩法不是瓶颈、网络路径才是。
tag
玩法系统接进来之后,单服到底能带多少同屏玩家?本节用 B 层基准本机实跑:每个玩家每 tick 做移动、施法、掷掉落三件事,由小到大扫 50 到 1000 同屏玩家,落 JSON 并给出每 tick 成本表,再与卷一的端到端承载数字对照,说明为什么玩法不是瓶颈、网络路径才是。
装配完成不等于能玩。本节给出一条可复现的验收链路:登录 → 移动 → AOI 广播 → 打怪掉落 → 拾取入包 → 交任务 → 组队进副本,每一步都带断言。给出验收脚本 cmd/dawnrealm 与端到端测试两个真跑块,以及本机跑通的完整输出,最后交代验收失败时该往哪一层排查。
前十七节把十四个玩法域各自写成了能跑的包,但它们还是散落的零件。本节讲怎么把玩法系统接进卷一造好的 aegis:每个域往同一张 cmd→handler 路由表登记命令,复用卷一的 11 字节帧协议与分发模型,再用一个进程、一个世界的 Server 把世界、战斗、掉落、背包、任务、队伍装起来,并给出装配后的实测结果。
房间建好了,还得有地方装。本节实现单服内的实例池:预热一批容量不同的实例、按 best-fit 挑刚好够用的那个、用完置为 draining 并冷却一段时间再复用。测试覆盖分配、容量不足、池耗尽、冷却期不可复用与复用后状态复位,并说明跨服调度为何留到卷三。
幽灵房间是匹配系统最典型的线上事故:房间早就没人了,却还占着实例槽位,把新玩家挡在门外。本节用「租约 + 单入口 Tick」把房间生命周期钉死:成员不续约就掉线、空房立刻回收、卡在 Starting 等 ack 超时回滚,并用测试把四种幽灵逐一复现。
匹配的难点不是「把两个人放进一个房间」,而是在评分准确度与等待时长之间找平衡。本节从零实现 internal/match:Elo 期望胜率与 rating 更新、随等待时长放宽的窗口、确定性的 PairScore 评分函数,并用 128 人 400 轮的仿真证明 rating 真能排出真实实力的次序。
价格索引是经济风控的眼睛:它把散落的成交记录压成中位价与成交量加权均价,再用偏离度和对手方频次给每笔拟成交打分。本节用 internal/trade 的 PriceIndex 从零实现滑动窗口中位价、VWAP、对敲计数与三级风控打分,并用测试验证单笔异常价不污染中位价、滑出窗口的对敲计数会衰减、自买自卖与严重偏离会被拦下。
竞价并发要同时守住三条不变量:同一拍品任意时刻只有一个有效最高价、被顶掉的出价人金币分文不损、出价失败时拍卖状态一个字节都不变。本节用 internal/trade 的 Auctioneer 从零实现出价与回滚,把「先冻新、再退旧」这个固定顺序讲透,并用 60 个 goroutine 并发出价配合 go test -race 验收唯一赢家与金币守恒。
资产冻结与托管是拍卖行与玩家交易的地基:上架时物品必须离开卖家背包,出价时金币必须从可用栏搬进冻结栏,成交或流拍再按结果分流。本节用 internal/trade 的 Escrow 从零实现这套托管,硬约束是任何一步失败都不留下半冻结状态,并用 go test 把重复冻结、金币守恒、成交过户与已结算退回逐一钉死。
红点不是「数一数未读邮件」那么简单,它是整棵 UI 树的聚合;离线玩家上线后也不能整包重拉。本节给 aegis 写一棵可聚合的红点树和一个增量同步日志:计数怎么沿父链传播、重复上报为什么要夹在零、掉线太久为什么必须退化成全量,附真跑的 L1 测试。
邮件带上附件之后,「领取」就不再是读一下就完事,而是一次必须恰好一次的资产发放。本节给 aegis 补上附件领取、过期扫描与流拍结算:为什么领取要按槽位记账、过期的未领附件为什么不能凭空消失,以及流拍返还的物品最终怎么折算成绑定货币,附真跑通过的 L1 测试。
邮件是 MMO 的万能投递通道,活动奖励、GM 补偿、拍卖结果、系统公告全走它。本节从零给 aegis 写一个可跑的邮箱内核:容量上界怎么定、全服邮件为什么不能扇出成 N 条存储、以及投递去重为什么不能只在邮箱里查 ID,并把它和卷一的幂等窗口接上,附 12 条真跑通过的 L1 测试。
赛季结算真正的难点不在发奖,而在边界:最后一秒还在涨分怎么办、崩溃重试会不会重复发奖、结算读的是活榜单还是快照。本节给 aegis 的 rank 包写一套可测的结算流程——冻结快照、按名次分档、发奖幂等,并给出赛季窗口的半开区间判据,把「哪一 tick 属于哪个赛季」钉死。
朴素榜单每次查询都重排,读路径太贵;真要把排名做到 O(log n),得让写入时就维持有序。本节给 aegis 的 rank 包加两样东西:把同一玩家的连续涨分压成一次改动的写缓冲,以及带 width 的跳表——它每一层记着跨过的节点数,于是「我第几名」不用数一遍就能直接算出来。
排行榜看着只是「按分数排个序」,可一旦塞进一张表用 ORDER BY 去查,读放大、写入热点、并列名次和「我的排名」四件事会同时把它压垮。本节先讲清排行榜真正要回答的问题、为什么一张表不够,再在 internal/rank 包里写出一个正确但注定会崩的朴素榜单,作为后两节优化版的对照基线。
公会战的第一步是报名与锁定:报名只能在开窗时段内、由持有报名权限的成员发起;名单必须在截止时刻一次性冻结,之后入会或退会都不再改变参战名单。本节用 aegis 从零实现报名窗口、权限校验与名单快照,讲清锁定为什么必须幂等,并说明卷二只做单服内的报名与锁定,真正的跨服对战留给卷三,最后用真跑的 L1 测试钉死窗口边界、权限与冻结。
公会仓库是多人共享的资产容器,捐献则是一份只增不改的流水账。本节用 aegis 从零实现:仓库按物品种类限槽但允许无限堆叠,捐献用请求号幂等去重避免重试翻倍,提现按职位控权并按日限额。重点讲清「先判幂等再写库存」的顺序为什么是正确性的关键,并用真跑的 L1 测试验证重试不翻倍、超额提现被拦、跨日重置生效。
公会系统是 MMO 里第一个跨玩家的持久组织:入会有自由与审批两种策略,职位有会长到成员五级,权限是一张职位到动作的位掩码表。本节用 aegis 从零实现单服公会模型——把权限收敛成一张可审计的表、让入会与审批幂等、把职位变更约束在层级之内,并用真跑的 L1 测试钉死满员竞态、重复申请与越级任免三条边界。
队长掉线了,谁带队进副本?本节把「掉线」与「退队」拆成两件事:掉线只灭在线标志、保留座位等重连,超时未回才回收;队长一掉线立刻按加入顺序把队长位交给下一位在线成员,且重连后不归还。全部用 go test -race 真跑,并讲清它与卷一顶号、重连的衔接。
上一节把入口控制收成了一处判断,但「先 Count 再 Add」这个写法本身在并发下就是错的:两个邀请可能都看到空位,把队伍撑到 5 人。本节把满员判断与写入压进同一个临界区,再把「满员校验 + 匹配锁定」也做成原子操作,用 go test -race 复现并证明修复。