《MMO 服务器开发》10.1 跨服务事务与补偿
跨服发奖发到一半崩了怎么办:点券扣了奖励没到、奖励到了流水没记。本节把跨服务事务的三种方案摆开——2PC 为什么不适合游戏服、TCC 的冻结确认撤销、Saga 的编排式与编舞式——并用 aegis 的 saga 包实现一套可跑的 Saga 状态机与补偿动作,断言正向全成功状态一致、中途失败逐个补偿回到一致态、补偿自身失败时重试并打上人工介入标记。
category
跨服发奖发到一半崩了怎么办:点券扣了奖励没到、奖励到了流水没记。本节把跨服务事务的三种方案摆开——2PC 为什么不适合游戏服、TCC 的冻结确认撤销、Saga 的编排式与编舞式——并用 aegis 的 saga 包实现一套可跑的 Saga 状态机与补偿动作,断言正向全成功状态一致、中途失败逐个补偿回到一致态、补偿自身失败时重试并打上人工介入标记。
站内已经有一大批游戏服务器架构文章,卷一写了网络内核、卷二写了单服玩法,那这一卷《分布式与跨服》到底写什么、不写什么?本节把三份内容的分工摊开讲清楚:站内架构文负责「应该怎么设计」,卷一与卷二负责「底座与单服怎么写」,本卷负责「集群与跨服从零实现并跑出数字」,并把这条边界编码成一张可查询、可测试的表。
上一节定下了集群拓扑,但拆不拆是另一回事——拆分从来不是免费的。这一节先列出一份拆分成本清单:一次 RPC 换来多少容量、又付出多少延迟与运维面,再把「单服能扛到多少 CCU 才值得拆」拆成三道可判定的闸门,最后用一个能跑的容量-拆分决策函数把这三道闸门编码成代码。
卷一造出了单机的网络内核,卷二装上了单服的玩法系统,可一旦在线人数上来,一台机器就扛不住了。这一节先把集群的三条路线——分区、分服、全球同服——摊开对比,再把网关、场景、战斗、世界、目录五类节点的职责边界定清楚,最后用一份能跑的 Go 代码把「哪个节点持有什么状态」钉成断言。
玩法系统接进来之后,单服到底能带多少同屏玩家?本节用 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 测试钉死窗口边界、权限与冻结。