MMO 战斗服架构工程 2026：actor 模型、房间分线与跨服玩法的统一取舍

战斗服是分布式系统里最难的子问题 —— 它要在 16ms 到 50ms 的 tick budget 内, 同时满足强实时、强一致、强可用三个相互拉扯的目标。本文以 actor 模型为骨架, 串起房间分线、跨服玩法、可分形递归的统一视角, 给游戏后端架构师一份可落地的取舍框架。

一、问题域与边界：MMO 战斗服为何是分布式系统里最难的子问题

MMORPG 的战斗服 (battle server / combat server) 承担着游戏世界里所有"会改变实体状态的事件"——技能释放、伤害结算、buff 触发、移动同步、位置校正、死亡与复活、掉落与拾取。在一万人同时在线、三十人同屏战斗的场景下, 单次战斗 tick 需要在 16ms (60Hz) 到 50ms (20Hz) 之间完成"接收输入 → 校验 → 推进世界状态 → 广播差异 → 落盘快照"的全链路。这个时窗比支付回调 (百毫秒级) 严苛十倍, 比推荐系统 (秒级) 严苛一百倍。

战斗服之所以难, 根本原因是它被三对相互矛盾的约束夹击:

• 强实时 vs 强一致：玩家按下技能键到看见特效的端到端延迟, 业界公认 P99 应在 100ms 以内, 但技能结果的"可复算" (deterministic) 又要求同一份输入在任何节点重放都得到同一份结果——这意味着序列化逻辑必须确定, 不能依赖浮点随机性, 不能依赖哈希集合遍历顺序。
• 强一致 vs 强可用：副本内所有玩家看到的怪物血量、技能效果、buff 倒计时必须完全一致, 但副本间又必须允许「跨服战」「跨服拍卖」「跨服聊天」这类最终一致事件——同一份世界状态既要在局部强一致, 又要在全局最终一致。
• 高吞吐 vs 强表达力：一个满员 30 人的副本在峰值团战时, 消息量可达每秒 5000-20000 条, 但这些消息的协议字段又必须支持扩展 (新技能 / 新 buff / 新状态) 而不破坏向后兼容——这要求 IDL (Interface Description Language) 设计既紧凑又能向前演进。

为把这三对矛盾框在可控范围, 必须先划清战斗服的边界。战斗服上游是网关服 (login + long-connection gateway) 与同步层 (rollback netcode / state sync / lockstep), 下游是持久层 (玩家数据 + 战斗日志) 与跨服事件总线 (跨服玩法消息流)。战斗服本身只吃"已通过鉴权 + 已落地同步层"之后的"世界状态变更请求", 输出"对客户端的世界状态差异包 (delta)"与"对下游的事件流"。同步层关心"网络抖动下的客户端预测与回滚", 战斗服关心"世界状态在服务端如何被并发推进"——本文不重复 id=696 关于确定性回滚网络码的讨论, 也不重复 id=700 关于长连接网关协议的讨论。

战斗服与 AOI (Area of Interest) 的关系也常被混淆。AOI 的职责是"把世界里的实体按视野裁剪成可见子集, 减少同步带宽", 是战斗服的输入裁剪层; 战斗服自身仍要维护"全量实体状态 + 全部待推进的事件", 因为战斗公式、buff 链路、伤害判定都需要全局上下文。所以 AOI 优化的是"战斗服输出带宽", 战斗服本身的吞吐瓶颈在"消息序列化 + 状态机推进 + 快照落盘"三处。

二、形式化：把战斗服抽象为 actor 系统 + 状态机 + 消息流

为给后续工程讨论一个共同语言, 把战斗服抽象为三元组 (A, S, M):

• A = actor 集合。每个 actor 是"一个有私有状态 + 单线程消息循环的并发单元"。在战斗服语境下, 一个 actor 通常对应"一个战斗副本 (zone / room / instance)", 也可以对应"一个实体 (player / monster / npc)"或"一个系统 (buff 系统 / 移动系统 / 技能系统)", 取决于粒度选择。
• S = 每个 actor 的私有状态。在战斗服语境下, 状态是"该副本或该实体在 t 时刻的完整世界描述", 序列化后是 protobuf message。
• M = 消息协议。actor 间通信靠消息, 不是共享内存; 消息是不可变 (immutable) 的 protobuf message, 投递按 FIFO 顺序 (单 actor 内)。

战斗帧 (round / frame) 抽象为: 在时刻 t, 战斗服从外部接收一组有序消息 (m1, m2, ..., mn), 把这组消息依次投递到对应 actor 的邮箱, 每个 actor 在自己的消息循环里按序处理并推进自身状态。一个 tick (调度周期) 就是"系统推进一帧 + 广播差异 + 落盘快照"的完整周期。tick rate 决定游戏体验的"丝滑度": 60Hz 给 FPS / MOBA 类, 20Hz 给 MMO 副本, 10Hz 给 SLG / 回合制。

在这个形式化下, 战斗服的一致性约束可以精确表达为:

• 局部一致: 同一 actor 内的状态变更严格按消息到达顺序串行推进, 不存在"两个线程同时改同一副本"的竞态。
• 全局最终一致: 不同 actor 之间的状态变更不保证强一致, 只保证"通过消息队列传递后, 在有限时间内一致"。
• 确定性: 同一份消息序列, 在任何节点上重放, 都得到同一份状态变更——这是 §3 消息序列化要解决的核心问题。

这个三元组足够抽象掉具体语言 (Erlang / Skynet / Orleans / Akka), 也足够贴近工程实现。后文 §3-§5 都在这个框架里讨论 actor 模型选型、房间分线、跨服玩法, §6 在这个形式化上做"统一视角"。

三、actor 模型：单线程 vs 多线程、消息序列化与背压

actor 模型的工程实现分两条路: 单线程 actor (Erlang/OTP 模式) 与多线程 actor (Skynet / Orleans / 一些自研框架)。两条路在战斗服语境下的取舍如下。

单线程 actor 是 actor 理论的"教科书实现": 一个 actor = 一个线程 + 一个邮箱 + 一个状态机。优点是简洁、确定、易回放 (单线程意味着消息处理是原子的, 不需要锁) ; 缺点是单核吞吐受限, 一个 actor 撑满 1 个 CPU 核心后, 横向扩展只能"多 actor 分摊"。Erlang 在电信领域跑了 30 年, 证明这条路的稳定性, 但游戏行业用 Erlang 的不多 (网易早期有过, 暴雪在部分工具链里用过)。单线程 actor 在战斗服里最常见的形态是"一个战斗副本独占一个逻辑线程", 即使该线程跑在 N 核机器上, 一个副本也只用一个核的算力。

多线程 actor 把"一个 actor 一个线程"的约束松绑成"一个 actor 在一个线程池里调度", 多个 actor 共享一个线程池, 调度器决定哪个 actor 在哪个线程上跑。Skynet (云风) 是典型代表, 用 C + Lua 组合, 多个 service (actor) 跑在 N 个 worker 线程上, 通过消息队列通信。Orleans (微软) 是另一个典型, .NET 生态, 用 virtual actor 抽象进一步隐藏线程细节。多线程 actor 的优点是吞吐高 (一份机器可以跑几千个 actor), 缺点是顺序保证弱化——同一 actor 跨线程调度时, 消息投递顺序可能被打乱, 需要在协议层加 sequence number 保证因果序。

实战中, 战斗服最稳的形态是混合模式: 一个战斗副本 = 一个逻辑 actor, 副本内强制单线程 (用 scheduler 把该副本的所有消息路由到固定一个 worker 线程), 副本间可并行 (不同副本在不同线程上跑)。这等价于"在跨副本维度上自由并行, 在副本内维度上严格串行", 既享受了 actor 模型的简洁, 又拿到了多核吞吐。Skynet 的 "actor = service" 抽象在多核扩展时, 也通常采用"一个 service 固定一个 worker" 的策略——这其实就退化为单线程 actor 的横向堆叠。

背压 (backpressure) 是 actor 模型在战斗服里必须解决的工程问题。当消息生产速率超过 actor 处理速率时, 邮箱会无限增长, 内存爆掉, 延迟失控。常见背压策略有三档: (a) drop 策略 (满了丢新消息) 适合"状态可以补偿"的场景, 比如心跳包; (b) spill to disk 策略 (满了落盘) 适合"消息可重放"的场景, 比如技能指令, 但落盘本身有 I/O 延迟; (c) reject client 策略 (满了直接关连接) 适合"客户端必须立即重连"的场景, 比如断线检测。战斗服的"重要指令" (技能、伤害) 走 spill to disk, "心跳" 走 drop, "溢出阈值"走 reject——一个 actor 通常要配三档并存。

消息序列化 与 IDL 设计是 actor 模型的另一关键。protobuf 与 flatbuffers 是两条主流路: protobuf 体积小、解析快、支持 schema 演进, 是战斗服消息的主流选择; flatbuffers 零拷贝、适合大消息 (snapshot), 但前向兼容比 protobuf 笨重。IDL 版本兼容有个铁律: 永远用字段 id (field number) 而不是字段名做寻址, 删字段用 reserved 而不是直接删, 加新字段用新 id 不复用旧 id。这是 protobuf FieldMask 与 schema 演进的基础, 也是为什么"老客户端"能连"新战斗服"。

下面是一份战斗服 actor message 的 IDL 示意 (protobuf3), 展示消息协议应有的最小结构: 头部有消息 id、时戳、源 actor 标识, 主体只放"事件" (event) 而不放"状态" (state) —— 状态由 actor 自己维护, 通信只传增量。

syntax = "proto3";

package combat.v3;

message ActorMessage {
  uint64 message_id    = 1;  // Snowflake ID, 全局唯一
  int64  timestamp_ms  = 2;  // 发送时刻 (sender clock)
  uint64 source_actor  = 3;  // 源 actor ID
  uint64 target_actor  = 4;  // 目标 actor ID (0 = 广播)
  uint32 sequence      = 5;  // actor 内 sequence, 保证因果序
  oneof payload {
    CastSkillEvent      cast_skill      = 10;
    DamageEvent         damage          = 11;
    MoveEvent           move            = 12;
    BuffTickEvent       buff_tick       = 13;
    SnapshotDeltaEvent  snapshot_delta  = 14;
    CrossZoneEvent      cross_zone      = 20;
  }
}

message CastSkillEvent {
  uint64 caster_id   = 1;
  uint32 skill_id    = 2;
  repeated uint64 target_ids = 3;
  int64  cast_at_ms  = 4;
  bytes  payload     = 5;  // 技能附加数据 (位置 / 方向 / 蓄力)
}

message DamageEvent {
  uint64 attacker_id = 1;
  uint64 victim_id   = 2;
  int32  amount      = 3;  // 最终伤害
  uint32 damage_type = 4;  // 物理 / 法术 / 真实
  bool   is_crit     = 5;
  int64  resolved_at_ms = 6;
}

注意 oneof payload 的设计: 一条消息只承载一个事件, 不堆叠多事件。oneof 是 protobuf 3 的"独占字段"语法, 保证"消息大小 + 反序列化速度"双优; 跨服事件 (cross_zone) 单独用 field 20 走专用 topic, 不与副本内事件混流。

四、房间分线：分片策略、跨房事件与一致性边界

房间分线 (zone / shard / instance 切分) 是战斗服横向扩展的核心策略。常见三种分线策略, 在并发、一致性、工程复杂度三轴上各有取舍。

按地图分线 是 MMORPG 最经典的分线方式: 一张地图 = 一个战斗副本, 玩家进入地图时分配到该地图的某个副本 (instance)。优点是"玩家与玩家天然按地图聚类, 同一副本内人数可控 (几十人级别) "; 缺点是"跨地图事件" (比如跨地图追杀、世界 BOSS) 需要跨副本消息。World of Warcraft 的"位面 (sharding)"就是典型按地图分线, 同一服务器的玩家按负载动态分配到不同位面。

按实例分线 是副本制 (raid / dungeon) 游戏的标准做法: 一个副本 ID = 一个战斗服, 玩家组队创建副本时分配到该副本的专属服务器。优点是"副本完全隔离, 一个副本崩了不影响其他副本"; 缺点是"副本间没有共享世界", 跨副本玩法 (跨服战) 需要专门的中转层。FF14 的"副本"与"过场动画"、原神的"秘境"都是按实例分线。

按玩家 ID 哈希分线 是 MOBA / FPS / 吃鸡类游戏的主流: 一个玩家 = 一个固定副本 (server-side authoritative), 玩家加入的房间动态创建副本, 副本生命周期跟房间绑。优点是"玩家状态可以全服共享 (背包 / 段位 / 货币)"; 缺点是"副本与副本之间没有地理概念, 跨副本玩法困难"。Valorant、Apex、CS:GO 都是按玩家 ID 哈希。

一致性边界是房间分线设计的核心: 单线内强一致, 跨线最终一致。单副本内, 状态变更严格按消息顺序推进, 不允许出现"两个玩家看到不一致的怪物体血量"; 跨副本间, 状态变更通过事件总线传递, 允许"另一副本的事件在 100ms-1s 后才生效"。这条边界划清楚了, 工程实现就清晰了: 副本内通信用 in-process message queue (skynet.send / erlang:send), 副本间通信用分布式消息队列 (kafka / rocketmq / pulsar)。

跨服事件总线在战斗服架构里扮演"跨副本通信"的角色。常见模式是: 战斗服把"跨服事件" (玩家升级、获得称号、跨服拍卖) 投到 kafka topic, 跨服玩法服务消费该 topic, 聚合后回写玩家数据。注意: 跨服事件走消息队列, 不走 RPC。RPC 是同步假设 (调用方等返回), 跨服场景必然是异步 (网络分区、节点故障都让 RPC 不可靠), 用 RPC 写跨服玩法会陷入分布式事务的泥潭。

跨服战的"分-合-分"三段式是房间分线在跨服场景下的标准模式: 玩家在原服 (A 服 / B 服) 的副本里活动, 进入跨服战时被拉到一个"撮合副本" (由跨服服务动态创建), 跨服战期间所有玩家的状态都进撮合副本, 战结束后回原服, 结算数据通过事件总线回流。这条流水线在很多 MMO 的"跨服战场""跨服竞技场"里都见过。

三种分线策略在并发 / 一致性 / 工程复杂度三轴的对比如下表 (用 L/M/H 表示低/中/高):

五、跨服玩法：跨服匹配、跨服战、跨服数据合并的工程难题

跨服玩法是 MMO 在 2010 年后逐渐标配的工程难题, 也是房间分线策略的直接衍生。三类跨服玩法各有取舍。

跨服匹配 是"跨服 1v1 / 跨服组队 / 跨服排位"等场景的工程支撑。玩家 ID 命名空间必须全局唯一 (不能用各服自增 ID), 通常用"服 ID + 玩家 ID"两段或 Snowflake / Leaf-segment 模式生成全局唯一 ID。段位聚合 (Elo / TrueSkill / Glicko) 在跨服场景下必须把所有服的玩家段位汇聚到全局匹配池, 这意味着段位数据要写"跨服可见的全局存储" (redis cluster / tidb / cockroachdb), 而不能只写本服数据库。匹配服务的延迟在 100-500ms 是可接受的 (玩家点匹配按钮到进入撮合副本), 实时性要求不高, 但撮合副本的分配要在 50ms 内完成。

跨服战 (跨服战场、跨服世界 BOSS、跨服攻城) 是技术上最复杂的跨服玩法。两种工程模式: "撮合副本模式" 把跨服战玩家拉到一个独立的跨服副本, 副本只承载跨服战, 玩家战前战后回到原服; "跨服场景模式" 把跨服战玩家放在一个跨服的"中立场景"里, 玩家可以同时跟原服 + 跨服玩家交互。前者实现简单, 后者工程复杂度高两个数量级。绝大多数 MMO 选择前者, 只有少数全球同服的大世界游戏 (Genshin Impact、Blue Protocol) 选择后者。

跨服数据合并 是跨服玩法最容易出 bug 的环节。典型场景: 玩家在 A 服打副本升级到 50 级, 同时 B 服推送"跨服战奖励"提升到 51 级, 两条数据回写冲突。解决方案有三档: (a) 最后写入获胜 (LWW) 简单但可能丢数据, 适合"非关键"字段; (b) 字段级合并 (CRDT) 适合"可加可减"的字段 (经验值、金币), 但需要业务层定义合并语义; (c) 全局锁 (distributed lock) 适合"绝对不能丢"的字段 (装备绑定), 但分布式锁本身是性能与可用性的死结。实战中, 跨服数据合并通常用 (a) + (b) 混合: 关键字段用 LWW + 业务校验, 累加字段用 CRDT, 极少用全局锁。

分布式 ID 生成 是跨服玩法的基础设施。Snowflake (Twitter) 用 41 位时间戳 + 10 位机器 + 12 位序列, 单机每毫秒可生成 4096 个 ID, 全局有序, 是 MMO 战斗日志的常见选择; Leaf-segment (美团) 用号段模式, 每次从 DB 拿一段号段本地分配, 适合"非时间敏感"的玩家 ID 生成。两者结合, 时间敏感的战斗事件 ID 用 Snowflake, 玩家 ID 用 Leaf-segment, 是工业界常用组合。UUID 不适合战斗服, 因为它无序, 数据库索引性能差。

全局排行榜是跨服玩法的衍生物: 全服玩家的战力 / 段位 / 成就排名。常见实现是 redis sorted set 分片 (按 rank 区间分片), 定时 (每分钟) 从分片聚合前 N 名到全局 sorted set, 客户端读全局 sorted set 拿排名。这种"分片 + 聚合"模式在社交榜、战力榜、抽奖排行榜都通用。

六、统一视角：把战斗服看作可分形递归的 actor 集群

把 §3 的 actor 模型、§4 的房间分线、§5 的跨服玩法放在一起, 有一个统一视角浮现: 战斗服是可分形递归的 actor 集群。

什么叫分形递归? 一个战斗副本是一个 actor; 一组战斗副本 (一个分线) 也是一个 actor (一个"超级 actor"管理一组"子 actor"); 一组分线 (一个世界) 又是一个 actor (一个"世界 actor"管理一组"分线 actor")。每一层的 actor 都遵循"消息传递 + 私有状态 + 单线程推进"的三元组规则, 只是消息粒度、状态规模、调度粒度不同。这条递归关系让战斗服的扩展性变成"切分粒度自适应"的问题: 副本内拥挤了, 把一个 actor 切两个; 分线内拥挤了, 把一个分线切两个; 世界内拥挤了, 把一个世界切两个。每一层切分都不破坏 actor 抽象, 通信协议不变, 状态机不变。

下面用 mermaid 描绘战斗服 actor 集群的分形拓扑, 展示从单副本到世界的递归结构:

世界 actor 是顶层抽象, 不直接处理战斗事件, 只管理分线生命周期、跨服撮合、跨服事件路由; 分线 actor 管理副本分配、跨副本事件路由; 副本 actor (CombatInstance) 处理真实战斗事件推进, 是单线程消息循环的核心; 系统 actor (BuffSystem / SkillSystem) 是"无状态函数"挂载在副本上, 由副本内消息调用。每层都用相同的消息协议 (ActorMessage) 通信, 不存在"跨层级 RPC 模式变更" 的问题。

从信息几何的视角看, 战斗服的状态是低维流形 (玩家属性、实体关系、空间结构) 嵌入在高维观测空间 (技能 ID × 数值 × 时间戳), 消息是流形上的切向量 (从 t 时刻状态到 t+1 时刻状态的"微元")。流形的低维性意味着战斗服的"有效状态"远小于"原始消息流", 这就是为什么序列化、压缩、剪枝在战斗服里收益巨大——你在压缩的是流形上的有效信息, 不是冗余字节。

通信与计算在战斗服里是一对对偶: 消息多 (消息爆炸) = 通信瓶颈, 状态多 (快照膨胀) = 计算瓶颈。一个好的战斗服架构是在两者之间找到"消息密度"与"状态密度"的最优比例。消息密度过高, 考虑用状态机吸收 (把高频小消息合并成低频大快照); 状态密度过高, 考虑用消息分解 (把大快照拆成消息流, 按需加载)。这条对偶关系给战斗服的性能调优提供了一个普适的取舍框架。

七、对工程实践的推论 (5 条可执行项)

把前面六节的讨论凝练为五条可执行的工程推论, 供战斗服架构师在评审与改造时使用。

推论一: 把战斗服抽象为 actor, 内部状态用 protobuf message 定义, 不暴露 C++ struct / Java class。 这是最容易被违反的——很多团队的代码里, 状态在 C++ struct 里活得好好的, 序列化只是 "toString 一下"。这样做的代价是: 序列化格式与代码强耦合, 重放系统做不出来, schema 演进做不出来, 跨语言客户端 (Lua / JS / Unity C#) 也做不出来。protobuf message 是 actor 状态的唯一"对外接口"。

推论二: 跨服事件一律走消息队列, 不走 RPC。 RPC 是同步假设, 跨服必然异步。用 RPC 写跨服玩法会陷入分布式事务的泥潭——两阶段提交、TCC、Saga 各种模式, 工程复杂度爆炸。消息队列天然是异步的, 投递失败可重试, 消息可回放, 跨语言跨框架可消费, 是跨服玩法的唯一可靠解。

推论三: 房间分线策略在开服前在压测平台验证, 不靠经验。 分线策略的并发上限、一致性边界、性能拐点, 必须在压测平台上用真实战斗场景跑出来, 不能"理论上 1000 实体 / 20Hz tick 没问题"就上线。压测要覆盖: 满员副本的 P99 延迟、空载副本的唤醒延迟、跨服事件的端到端延迟、快照落盘的 I/O 抖动、跨服撮合副本的冷启动延迟。

推论四: 全局 ID 用 Snowflake + Leaf 混合, 不要用 UUID。 战斗事件 ID (日志、回放、replay) 用 Snowflake, 因为它全局有序, 范围查询高效; 玩家 ID 用 Leaf-segment, 因为它对数据库友好, 单调递增, 索引性能好。UUID 的随机性让它不适合做主键 (B+ 树索引页分裂严重), 更不适合做战斗事件 ID (无序无法范围查询)。

推论五: 战斗服的"回放系统"必做, 是 SRE 排障的唯一可靠手段。 战斗服的状态是"消息序列 + 确定性处理逻辑"共同决定的, 重放系统把"消息序列"记录下来, 任意节点都能从这条消息序列重放出相同状态, 这是定位"为什么玩家看到血量不对"这类问题的唯一手段。没有回放系统的战斗服, 出了 bug 只能靠日志瞎猜, 这是工业界 30 年来的血泪教训。

八、讨论与局限

本文的 actor 模型框架对休闲手游 / 单局游戏 / 休闲小游戏不直接适用——这些游戏没有"跨服"概念, 没有"持久化世界状态"概念, 它们的战斗服更接近"无状态函数" (input → output), 不需要 actor 抽象, 也不需要房间分线。本文讨论的工程难题, 集中在"长期在线 + 持续世界 + 跨服玩法"这一象限。

大世界 MMO (Genshin Impact 类) 的战斗服架构在本文 actor 模型之外, 还有另一条路: 客户端预测 + 服务端校验 (client-side prediction + server-side reconciliation)。这条路上, 战斗服只做"客户端上报的最终状态校验", 不主动推进世界; 客户端在本地跑确定性模拟, 把结果上报给服务端, 服务端做权威校验。这条路对网络要求低, 但对"反作弊"要求高。本文 actor 模型与客户端预测模型是互补关系, 不是互斥——很多 MMO 在战斗服里用 actor 模型做"副本内战斗", 同时用客户端预测做"开放世界移动"。

学术界对 actor 系统的形式化研究 (Carolyn Talcott 的 actor 理论、C Hewitt 原始 actor 论文) 远落后于工业实践——工业界早在 1986 年就在电信领域跑 Erlang, 学术界到 2010 年代才把 actor 理论形式化做得比较完整。游戏战斗服的 actor 模型实践, 反过来也推动了分布式系统理论的边界: "消息序列化 + 状态机推进 + 快照落盘" 这条三件套, 在分布式系统教科书里被抽象成"event sourcing + CQRS" 模式, 起源其实是游戏战斗服。

九、给游戏后端架构师的清单

把全文收尾为一份可勾选的清单, 给战斗服架构师在评审、改造、新建战斗服时使用。

战斗服 5 个不可妥协的硬约束:

1. 状态必须用 protobuf message 定义, 序列化格式与代码解耦。
2. 单一 actor 内必须单线程推进, 副本内不允许多线程改同一状态。
3. 跨服事件一律走消息队列, 不走同步 RPC。
4. 战斗回放必须能基于消息序列完整重放, 状态可复算。
5. 跨服数据合并必须用 CRDT 或 LWW + 业务校验, 不允许用全局锁。

房间分线 3 个常见错误:

1. 用 UUID 做战斗事件 ID, 导致日志查询性能差 (用 Snowflake)。
2. 跨服事件走 RPC + 两阶段提交, 工程复杂度爆炸 (用消息队列)。
3. 不做压测就上线分线策略, 高峰期副本切换慢 / 跨服战撮合超时 (开服前必压测)。

跨服玩法 4 个迁移陷阱:

1. 玩家 ID 命名空间不统一, 跨服后 ID 撞车 (用全局唯一 ID + 服 ID 前缀)。
2. 段位 / 战力数据只写本服 DB, 跨服后玩家段位看不到 (用全局聚合存储)。
3. 跨服战撮合副本创建延迟高, 玩家匹配后等半分钟 (冷启动优化 + 预创建池)。
4. 跨服战结束后结算数据丢失, 玩家奖励消失 (回写用幂等 + 业务校验)。

性能基线参考 (单战斗副本, 中等配置 8 核 32GB):

• 1000 实体 / 20Hz tick / P99 延迟 ≤ 50ms / 消息吞吐 2000 条/秒。
• 跨服事件端到端延迟 P99 ≤ 200ms。
• 快照落盘 I/O 抖动 ≤ 10ms。
• 撮合副本冷启动 ≤ 100ms。

参考文献

1. Hewitt, C., Bishop, P., & Steiger, R. (1973). A Universal Modular ACTOR Formalism for Artificial Intelligence. IJCAI.
2. Agha, G. (1986). ACTORS: A Model of Concurrent Computation in Distributed Systems. MIT Press.
3. Armstrong, J. (2007). Programming Erlang: Software for a Concurrent World. Pragmatic Bookshelf.
4. Talcott, C. (1996). Interaction Semantics for Components of Distributed Systems. FMCO.
5. Letz, S. (2018). Skynet: A Actor-based Game Server Framework. GitHub.
6. Bernstein, P. A., & Newcomer, E. (2009). Principles of Transaction Processing. Morgan Kaufmann.
7. Shapiro, M., et al. (2011). A Comprehensive Study of Convergent and Commutative Replicated Data Types. INRIA.
8. DeCandia, G., et al. (2007). Dynamo: Amazon's Highly Available Key-value Store. SOSP.
9. Ongaro, D., & Ousterhout, J. (2014). In Search of an Understandable Consensus Algorithm. USENIX ATC.
10. Twitter. (2010). Snowflake: Generating Unique IDs at Scale. Engineering Blog.
11. Meituan. (2017). Leaf: Distributed ID Generation Service. Engineering Blog.
12. Kreps, J., Narkhede, N., & Rao, J. (2011). Kafka: a Distributed Messaging System for Log Processing. NetDB.
13. Kleppmann, M. (2017). Designing Data-Intensive Applications. O'Reilly.
14. Nystrom, R. (2014). Game Programming Patterns. Genever Benning.
15. Valve. (2018). Source Multiplayer Networking. Developer Wiki.
16. Microsoft. (2017). Orleans: Distributed Virtual Actors for Programming Scalable Cloud Services. CACM.
17. Crooks, N., et al. (2016). Server-side Rewind: Server-side State Synchronization for Multiplayer Games. NSDI.

一句话摘要: 战斗服是 actor 模型的天然载体——单副本单线程、跨副本多线程、跨服异步消息——分形递归的 actor 集群让 MMO 在 16-50ms tick budget 内同时满足强实时、强一致、强可用, 而工程上的关键不是哪条路最优, 而是在副本内 / 副本间 / 跨服三档一致性边界上找到最贴业务的取舍点。