全栈攻城狮

Appearance

Actor 模型在游戏中的应用 ​

概述 ​

理解了 Actor 基础，关键在如何把游戏业务映射成 Actor：谁该是 Actor、谁不该是，Actor 之间怎么通信，生命周期如何管理。本文以玩家/房间/匹配三类核心 Actor 为例，讲清职责划分、消息通信与生命周期管理，并给出与 Netty 网关的桥接方案。

一、Actor 职责划分 ​

1.1 玩家 Actor ​

PlayerActor（每个在线玩家一个）：
  状态：货币、背包、任务、好友（该玩家的全部数据）
  消息：操作请求（购买/对战/领取）、系统事件
  特性：
    单线程串行处理该玩家所有请求
    状态天然线程安全
    离线时停止（状态已持久化）
职责边界：
  管理玩家私有数据
  校验玩家操作（余额/背包）
  与其它 Actor 协作（申请加入房间）

不做：
  不直接操作数据库（委托持久化服务）
  不处理网络编解码（网关层做）

1.2 房间 Actor ​

RoomActor（每个房间一个）：
  状态：房间配置、成员列表、对局状态
  消息：加入/离开/出牌/心跳
  特性：
    房间内操作全部串行
    房间与房间互不干扰（天然并行）
    对战结算在房间内完成
房间 Actor 的价值：
  对局逻辑单线程 → 无需锁
  房间生命周期 = Actor 生命周期
  崩溃恢复：重建房间 + 通知玩家重连

1.3 匹配 Actor ​

MatchActor（少量，按模式划分）：
  状态：匹配池（各段位排队玩家）
  消息：申请匹配/取消匹配/匹配结果
  特性：
    匹配逻辑集中（避免多线程竞争匹配池）
    匹配结果通知相关玩家 Actor
划分原则：
  数据内聚 → 谁拥有数据谁是 Actor
  粒度适中 → 不要为临时行为建 Actor
  热点拆分 → 匹配按模式拆多个 Actor

二、Actor 间消息通信 ​

2.1 消息设计 ​

消息要求：
  不可变（final 字段，无 setter）
  携带最小必要信息（避免传大对象）
  带请求上下文（playerId/requestId）便于追踪

示例：
  PlayerActor → RoomActor：JoinRoomMsg(playerId, roomId)
  RoomActor → PlayerActor：RoomStateMsg(roomId, snapshot)
  MatchActor → PlayerActor：MatchFoundMsg(roomId)

2.2 通信模式 ​

请求-应答（ask）：
  玩家查询自己的状态 → ask PlayerActor
  注意超时（Actor 不可达/处理慢）

通知（tell）：
  广播、事件通知（单向，不等待）
  房间状态变更 → tell 所有成员

代理转发（forward）：
  网关收到消息 → forward 给目标 Actor
  保持原始 sender（便于回执）
// 玩家请求转发到玩家 Actor
public class GameGatewayActor extends AbstractActor {
    @Override
    public Receive createReceive() {
        return receiveBuilder()
            .match(PlayerRequest.class, msg ->
                playerActor(msg.playerId).forward(msg, context()))
            .build();
    }
}

2.3 消息路由 ​

路由策略：
  玩家 ID → 一致性哈希 → 玩家 Actor（稳定路由）
  房间 ID → 分片 → 房间 Actor
  路由表维护在 Actor 系统内（Cluster 则靠分片）

消息乱序：
  单发送方单接收方 → mailbox 保序
  跨 Actor 协作 → 用 requestId/序列号校验

三、Actor 生命周期管理 ​

3.1 生命周期模型 ​

生命周期状态：
  Created → Started → Running → Stopped

关键节点：
  创建：配置初始化（从持久化恢复状态）
  运行：处理消息
  停止：持久化未落盘数据、清理资源

停止触发：
  玩家离线（延迟停止，留宽限期）
  房间对局结束（解散房间）
  系统维护（优雅停止）

3.2 玩家 Actor 生命周期 ​

玩家上下线：
  登录：查找/创建 PlayerActor → 从持久化恢复
  离线：宽限期（如 30 秒）→ 停 Actor → 落盘
  重登：复用宽限期内的 Actor（状态热）

问题：宽限期内状态在 Actor 内存，停机丢数据？
  对策：定期快照 + 操作流水（见持久化章节）
// 定时停止空闲玩家 Actor（配合持久化）
getContext().system().scheduler().scheduleOnce(
    Duration.ofSeconds(30),
    () -> getContext().stop(self()),
    getContext().dispatcher()
);

3.3 监督与恢复 ​

监督策略：
  玩家 Actor 崩溃 → 重启（恢复持久化状态）
  房间 Actor 崩溃 → 通知玩家 → 重建房间
  匹配 Actor 崩溃 → 重启（匹配池可重建）

故障边界：
  单个 Actor 失败不蔓延
  监督树层级管理

四、与 Netty 网关桥接 ​

4.1 整体架构 ​

架构分层：
  Netty 网关：连接管理、编解码、心跳（无状态）
  Akka 逻辑层：玩家/房间/匹配 Actor（有状态）

桥接：
  网关收到消息 → 路由到玩家 Actor
  Actor 回执 → 转发到网关 → 写回连接
  连接与玩家映射在网关（Session 表）
// 网关 → Actor 的桥接（伪代码）
public void onPlayerMessage(Channel ch, long playerId, Object msg) {
    ActorRef player = actorRouter.route(playerId);
    player.tell(new GatewayMsg(ch.id(), msg), gatewayRef);
}

4.2 通信设计要点 ​

可靠性：
  Actor 消息内存传送（不跨进程）→ 不丢
  跨节点（Cluster）→ 参考 Akka Cluster 章节
  玩家重连 → 用快照恢复（见实时对战章节）

压力控制：
  Actor mailbox 无限增长风险 → 背压/丢弃策略
  玩家高频操作 → 频率限制在网关层先挡

五、实现要点 ​

设计清单：
  数据内聚划分 Actor（玩家/房间/匹配）
  消息不可变 + 最小信息
  tell 优先，ask 需超时
  玩家离线延迟停止 + 持久化
  监督树定义故障边界
  网关与 Actor 桥接分层

常见坑：
  Actor 里做阻塞 IO → 卡 mailbox
  Actor 数量失控 → 资源上限 + 清理
  全局 Actor（单点）→ 拆分为多 Actor/分片
  消息风暴 → 限流 + 背压
与其他系统衔接：
  房间系统 → RoomActor 改造（实战章节）
  Cluster 分片 → 房间分布式 Actor 章节
  持久化 → Event Sourcing / 快照
  网关 → 网络层章节