游戏服务器副本锁定与存档点架构设计

多人副本最怕的不是 Boss 难，而是进度说不清。队长打到第三个 Boss 掉线，成员换人补位，新人有没有奖励资格？服务器重启后副本实例恢复到哪里？有人故意卡在 Boss 死亡前退出，能不能规避锁定？这些问题如果只靠房间服内存状态处理，早晚会在团本、跨服副本或周常重置时爆雷。副本锁定与存档点架构的核心，是把“实例状态”和“玩家资格”拆成两个可持久化、可审计、可恢复的模型。

典型场景

一个 20 人团本有 6 个 Boss，每周重置。团队击杀前两个 Boss 后解散，第二天继续开组。老成员应该从第三个 Boss 开始，新成员如果加入，必须继承当前进度并失去前两个 Boss 奖励资格。若第三个 Boss 战斗中服务器崩溃，恢复后不能把 Boss 判定为已击杀，也不能让玩家重复领取前两个 Boss 奖励。这里需要实例存档点、Boss 事件日志、玩家 lockout、奖励 claim 四组数据一起工作。

架构示意

flowchart LR
  L["Lobby"] --> A["Lockout Service"]
  A --> I["Instance Allocator"]
  I --> R["Raid Runtime"]
  R --> E["Boss Event Log"]
  R --> S["Savepoint Store"]
  R --> Q["Reward Eligibility"]
  Q --> C["Claim Ledger"]
  A --> M["Weekly Reset Job"]

实例进度和玩家锁定必须解耦

实例进度描述这个副本打到了哪里，玩家锁定描述某个玩家与哪个进度绑定。两者不能混在一个房间状态里。玩家 A 可以属于团队进度 X，玩家 B 后加入也绑定到 X，但 B 的奖励资格从加入点开始。实例可以被销毁和重建，玩家锁定不能随房间内存消失。这个解耦也让客服工具能够解释：玩家为什么不能进入某个进度，为什么没有某个 Boss 奖励。

存档点只在稳定边界写入

不要在战斗过程中的每个小阶段都写存档点，否则恢复逻辑会极其复杂。常见稳定边界包括副本创建、Boss 开战前、Boss 击杀完成且奖励资格冻结后、机关阶段完成后、团队主动解散。Boss 死亡动画播放不等于存档点完成，必须等击杀事件、掉落资格、成就触发和进度推进形成一个事务性提交记录后，才能把存档点推进。

奖励资格要在战斗关键点冻结

奖励资格不能等玩家点击拾取时才算。进入 Boss 战、造成有效贡献、治疗或承伤达到阈值、战斗结束时在线或短暂断线保护，都可能影响资格。服务端应在 Boss 战开始建立候选名单，过程中记录贡献，击杀时冻结资格，然后由领取流水防重。这样可以处理玩家掉线、队长踢人、补位和延迟领奖等情况。

中途补位要有清晰的继承规则

补位玩家进入已有进度时，服务端需要展示将继承的 Boss 击杀状态和奖励损失，并在确认后写入 lockout。不要允许客户端只靠 UI 提示完成确认，确认记录要有版本号，防止团队在玩家确认期间又推进了进度。对于跨服团本，锁定服务应该部署在全局控制面，而不是某个房间服本地。

恢复流程要从事件日志重建，而不是相信最后一帧内存

实例崩溃后，恢复服务读取最近存档点，再重放存档点之后的 Boss 事件日志。只有完整提交的击杀事件才推进进度；半提交事件进入人工或自动修复队列。这样即便房间服在掉落发放前崩溃，也不会出现 Boss 已死但奖励流水缺失的状态。

关键设计取舍

落地检查清单

• 副本进度、玩家 lockout、奖励资格、领取流水四表分离
• 存档点只在稳定边界推进
• Boss 击杀提交需要事件日志和资格冻结
• 补位确认记录带进度版本号
• 周重置任务先冻结入口再清理旧锁定

一线排障与复盘建议

这个架构上线后，团队要提前准备几类排障入口。第一是按玩家、业务单号或场景 id 查询完整链路，能看到请求进入、状态变化、关键版本、外部依赖结果和最终响应。第二是按时间窗口查看异常分布，区分是全局配置错误、单分片容量问题，还是少量玩家边界条件触发。第三是保留人工修复入口，但修复入口必须写审计流水，记录修复前状态、修复后状态、操作人、审批单和影响范围。没有审计的手工修复，短期能救火，长期会破坏系统可信度。

容量评估也要贴近玩法节奏，而不是只看平均在线。运营开活动、赛季结算、跨服匹配、周常刷新和主播带队都会让请求集中到很短窗口。压测脚本应模拟重复点击、弱网重试、服务超时、实例重启和消息乱序，不要只跑顺滑路径。对于玩家资产、资格、奖励、处罚这类敏感链路，压测结果里要额外检查幂等流水和最终状态，不只是吞吐量。

上线前可以采用影子模式：生产请求仍走旧逻辑，新架构旁路计算结果并记录差异。差异样本要由服务端、策划和客服一起看，因为有些差异来自旧逻辑 bug，有些来自新规则理解错误。等差异收敛后，再按小区服、低风险玩法或内部账号灰度。灰度期间观察错误码、超时、回滚次数、人工工单和玩家反馈，确认系统在真实噪声下仍然可解释。

表结构与状态边界

实践中可以把团本数据拆成 raid_progress、player_lockout、boss_eligibility、reward_claim 四类记录。raid_progress 保存 raidId、seasonId、difficulty、savepointVersion、defeatedBosses、currentPhase 和 ownerRegion。player_lockout 保存 playerId、raidId、lockCycle、joinedAtBoss、acceptedVersion。boss_eligibility 保存 bossId、candidatePlayers、frozenPlayers、contributionSummary。reward_claim 保存 playerId、bossId、claimKey、rewardVersion 和发放结果。

这些表不一定都在同一个数据库里，但状态边界必须一致。Boss 击杀提交时，先冻结资格，再推进 raid_progress，最后开放领取或自动发奖。若自动发奖失败，raid_progress 不应回退，因为击杀事实已经成立；失败奖励进入补偿队列。反过来，如果击杀事件尚未完整提交，不能先把 Boss 标记为 defeated，否则玩家会失去挑战机会。

故障案例：半提交击杀导致奖励争议

一个项目曾在 Boss 死亡瞬间先推进进度，再异步计算掉落。某次奖励服务短暂超时，Boss 已被标记击杀，但资格名单没有冻结成功。玩家第二天继续副本时发现 Boss 不在了，也没有邮件奖励。客服只能根据战斗日志人工补偿，且无法准确判断哪些中途掉线玩家有资格。

修复方案是引入击杀提交事务：BossRuntime 先写 kill_event_pending，资格服务冻结名单并返回 eligibilityVersion，奖励服务生成 rewardPlan，最后 progress 服务把 Boss 状态从 alive 改为 defeated。任何一步失败，Boss 仍处于 pending 状态，副本入口会临时禁止继续推进，并触发修复任务。这个流程比原来慢几十毫秒，但换来了可解释性。

运营工具与客服视角

团本系统一定要给客服工具留查询能力。客服需要按玩家查看本周期绑定了哪些进度、哪些 Boss 有资格、哪些奖励已领取、哪些补偿在队列中。运营需要按 raidId 查看团队成员变化、补位确认、Boss 击杀时间线和存档点版本。没有这些工具，所有争议都会要求研发查日志。

人工修复也要限制权限。允许补发奖励，不应随意改 defeatedBosses；允许解除错误 lockout，但必须记录原因和审批；允许重开副本实例，但要生成新的 raidId 或 savepointVersion，避免旧实例和新实例同时存在。团本奖励价值通常较高，修复入口越随意，经济系统越容易被内部误操作影响。

压测重点

副本锁定压测不能只测 20 人同时打 Boss。更重要的是测边界：Boss 死亡瞬间玩家掉线，队长解散队伍，补位玩家确认期间进度变化，房间服在击杀提交中重启，周重置任务与领取奖励并发。每个场景都要检查最终状态是否唯一：Boss 到底是否击杀，玩家到底是否有资格，奖励到底是否发放。只要最终状态能解释，短暂排队或稍后补偿都可以接受。

上线验收指标

副本锁定的验收要围绕最终事实一致性。每次压测结束后，抽样检查 raid_progress、player_lockout、boss_eligibility、reward_claim 是否能互相解释。任何一条 Boss defeated 记录，都必须能找到对应击杀事件和资格冻结版本；任何一条奖励领取，都必须能找到资格来源；任何一个玩家被拒绝进入，都必须能看到 lockout 原因。

压测场景要故意制造混乱：Boss 1% 血时房间服重启，击杀后奖励服务超时，补位玩家确认时队长开怪，周重置与副本内玩家并发，玩家领取奖励时断线重连。验收标准不是所有请求都成功，而是失败后状态不互相矛盾。回滚条件包括 Boss 进度不可恢复、资格冻结缺失、奖励重复领取和周重置误清活跃进度。

团队协作边界

副本锁定规则必须由策划、服务器和客服共同确认。策划定义补位、掉线、死亡、贡献和周重置规则；服务器把规则落到状态机和数据表；客服工具展示玩家能理解的原因。不要让客服只看到一串 lockoutId，也不要让策划只在文档里写“按正常团本规则处理”。

每次团本规则调整都要附带迁移说明：旧进度是否继承，新 Boss 是否影响已有 lockout，奖励资格是否重算。没有迁移说明的规则更新，很容易在赛季中制造无法解释的历史数据。

总结

副本锁定系统做得好，玩家不一定会夸；做得差，客服和运营会被各种边界案例淹没。把进度、资格和奖励流水拆清楚，是团本长期运营的底座。