Q27: Real、Ghost、Shadow Entity 之间如何转换？如何高效同步？

核心结论

这三个概念真正需要抓住的是“权威归属”和“副本职责”：

• Real 是唯一权威实体
• Ghost 是服务端其他节点上的受控镜像
• Shadow 是客户端用于显示和补偿的本地状态

转换的重点不是名词切换，而是“谁拥有写权限”和“切换期间如何不丢状态”。

一、三者的边界

1. Real

负责：

• 权威状态推进
• 战斗与移动逻辑
• 最终属性修改

同一时刻只能有一个 Real。

2. Ghost

负责：

• 为其他 Cell 或邻区提供远端镜像
• 参与边界感知和迁移预热
• 承接受控同步

Ghost 一般不负责最终结算。

3. Shadow

负责：

• 客户端显示
• 插值和平滑
• 本地玩家预测与校正

它不是服务端权威对象的简单平移版。

二、什么时候发生转换

1. Real 变 Ghost

最典型场景是实体跨分区迁移。

原本负责该实体的节点不再拥有权威后，会降级为 Ghost 或进入回收状态。

2. Ghost 变 Real

目标分区在接手权威时，会把预热好的镜像提升为新的 Real。

3. Shadow 更新

客户端的 Shadow 通常不会“升格成 Real”，它更多是接收服务端权威状态并做本地平滑。

三、迁移时真正重要的步骤

一个更稳妥的迁移流程通常是：

1. 目标节点先创建或预热 Ghost
2. 持续同步必要状态
3. 到达切换条件后，切换权威归属
4. 旧 Real 降级或清理
5. 周边 AOI 和客户端同步关系更新

这里最容易出问题的是：

• 双 Real 并存
• 旧 Ghost 数据过期
• 切换瞬间丢事件

四、同步应该同步什么

高效同步的前提是不要把所有字段一股脑全发出去。

通常应区分：

• 迁移必需状态
• 邻区观察状态
• 客户端显示状态

例如邻区 Ghost 可能只需要：

• 位置
• 朝向
• 阵营
• 基本生命周期状态

而不需要整份背包和任务明细。

五、为什么 Shadow 的同步策略和 Ghost 不一样

Ghost 更接近服务端逻辑镜像，Shadow 更接近渲染与交互状态。

所以：

• Ghost 关注状态正确性和边界协作
• Shadow 关注显示连续性和玩家手感

客户端往往会对 Shadow 做：

• 插值
• 预测
• 平滑校正

这些都不适合直接套到服务端 Ghost 身上。

六、工程上怎么提高同步效率

常见做法包括：

• 脏字段同步
• 增量版本号
• 按观察者裁剪字段
• 批量发送
• AOI 约束副本数量

核心目标始终是：

• 降低副本成本
• 保持切换稳定
• 避免重复结算和双写

七、常见误区

1. Ghost 可以顺便执行一些关键逻辑

这很危险，容易造成分叉状态和重复结算。

2. 客户端 Shadow 看到的就是权威状态

不对。Shadow 往往带有预测和插值，是体验层状态。

3. 转换只要改个标志位

不对。真正困难的是主从切换顺序、状态完整性和事件不丢。

参考资料

• KBEngine / BigWorld 架构资料中的 Real / Ghost / Shadow 设计说明