消息分发与路由

概述

网关解码出 GameMessage 后，需要按 Opcode 找到对应的业务处理器执行，还要决定"这段业务代码在哪个线程跑"。这就是消息分发与路由：Opcode → Handler 的映射机制、消息线程模型（同一玩家串行）、业务线程池隔离，以及异步处理与回调。分发设计直接决定游戏服务器的并发正确性与吞吐上限。

一、Opcode 到 Handler 的映射

1.1 分发器核心结构

java

public interface MessageHandler {
    void handle(ChannelHandlerContext ctx, GameSession session, byte[] body);
}

java

public class MessageDispatcher {

    private final ConcurrentHashMap<Short, MessageHandler> handlers = new ConcurrentHashMap<>();

    public void register(short opcode, MessageHandler handler) {
        handlers.put(opcode, handler);
    }

    public void dispatch(ChannelHandlerContext ctx, GameMessage msg) {
        MessageHandler handler = handlers.get(msg.getOpcode());
        if (handler == null) {
            // 未注册的 Opcode：日志 + 忽略（或回错误码）
            return;
        }
        handler.handle(ctx, sessionOf(ctx), msg.getBody());
    }
}

设计要点：
  ConcurrentHashMap 保证注册与查询并发安全
  注册表在启动时一次性注册完毕，运行期只读
  未注册 Opcode 要记录日志（可能是新客户端/异常流量）

1.2 自动注册（Spring 集成）

java

@Component
public class HandlerRegistry implements ApplicationListener<ContextRefreshedEvent> {

    @Autowired
    private MessageDispatcher dispatcher;

    @Autowired
    private List<MessageHandler> handlers;

    @Override
    public void onApplicationEvent(ContextRefreshedEvent event) {
        for (MessageHandler handler : handlers) {
            MessageMapping mapping = handler.getClass().getAnnotation(MessageMapping.class);
            if (mapping != null) {
                dispatcher.register(mapping.opcode(), handler);
            }
        }
    }
}

java

@MessageMapping(opcode = 1001)
@Component
public class LoginHandler implements MessageHandler {
    @Override
    public void handle(ChannelHandlerContext ctx, GameSession session, byte[] body) {
        // 登录逻辑
    }
}

自动注册的好处：
  新增一个 Handler 只需写类 + 注解，无需改注册代码
  依赖 Spring 扫描，Handler 可注入各种 Bean
  多人协作互不冲突

1.3 Opcode 命名规范

建议：
  常量类集中定义，避免魔法数字
  分段规划：1001-1100 系统（登录/心跳/登出）
            1101-2000 大厅（房间/匹配/好友）
            2001+     玩法消息（按玩法细分）
  预留区间，避免需求变更撞号

二、消息线程模型

2.1 核心问题

解码在 IO 线程（EventLoop）执行
业务逻辑如果也在 IO 线程：
  一个慢业务（查库/复杂计算）会卡住整个 EventLoop
  该线程上所有连接的读写全部阻塞
→ 必须把业务从 IO 线程剥离

2.2 串行化原则：同一玩家消息串行

为什么必须串行：
  玩家状态（金币、背包、房间）是共享可变数据
  若两个线程同时处理同一玩家的消息 → 数据竞争
  加锁简单但低效（玩家粒度锁粒度太粗）

Netty 提供的解法：
  同一个 Channel 的事件天然在一个 EventLoop 上串行
  只要业务也绑定同一线程（或按玩家取模定线程），就无锁

2.3 EventExecutorGroup 方案

java

// 为业务 Handler 指定独立线程组，且保证同一 Channel 的消息落同一线程
EventExecutorGroup businessGroup = new DefaultEventExecutorGroup(businessThreads);

pipeline.addLast(businessGroup, "business", new BusinessHandler());

原理：
  DefaultEventExecutorGroup 内含 N 个线程
  每个 Channel 注册时绑定其中固定一个线程
  同一 Channel 的所有业务消息都在该线程串行执行
  → 天然满足"同一玩家串行"

参数选择：
  线程数 = 按核心数与业务复杂度压测
  通常 CPU 核数 × 2 ~ × 4

2.4 按玩家路由的线程池

更精细的做法：业务线程池按 playerId 取模路由
  executor = pool[playerId % poolSize]
  同一玩家永远进同一线程 → 串行
  不同玩家可能进同一线程 → 共享但串行

实现：
  自定义 Executor：按 key 路由到固定线程
  或使用 Disruptor / 自研多队列线程池

对比：
  EventExecutorGroup：按连接绑定（玩家=连接时等价）
  按玩家路由：玩家跨连接/重连后仍稳定同一线程
  一般游戏用 EventExecutorGroup 足够，重连恢复时再同步

三、业务线程池隔离

3.1 分层线程池模型

第一层：IO 线程（EventLoop）
  只做：编解码、读写、心跳、限流
  绝不：查库、复杂计算

第二层：业务线程池
  做：业务逻辑、状态更新、房间广播准备
  同一玩家串行

第三层：异步任务池（可选）
  做：日志写入、统计、异步落库
  可并行，不要求顺序

为什么分三层：
  各层负载独立，慢业务不影响 IO
  串行层保一致性，并行层保吞吐
  每层可独立扩缩容与监控

3.2 阻塞操作规范

业务线程池内仍然避免阻塞：
  数据库查询 → 异步化（回调继续）
  跨服务调用 → 异步 RPC
  如果真的同步阻塞，线程池会耗尽
  → 监控业务线程池活跃度/队列长度

四、异步处理与回调

4.1 异步写回

业务线程处理完，如何回包：
  不能直接 channel.write()（跨线程写注意安全）
  Netty 的 writeAndFlush 是线程安全的
  业务线程可直接调用 ctx.channel().writeAndFlush(msg)

  但要注意写回顺序：同一玩家的写需串行
  推荐统一走"玩家消息队列"回写

java

// 安全回写
Channel channel = session.getChannel();
if (channel != null && channel.isActive()) {
    channel.writeAndFlush(response);
}

4.2 异步业务回调

java

// 伪代码：异步查库后继续处理
asyncPlayerDao.load(playerId)
    .thenAccept(player -> {
        // 回到玩家串行线程继续
        executor.execute(() -> {
            doGameLogic(player);
            sendResult(session, result);
        });
    });

回调注意：
  回调恢复执行要回到"玩家串行线程"，否则并发风险
  异步链路要有超时与错误处理（超时回滚、异常兜底）
  避免回调地狱：用 CompletableFuture 编排

4.3 请求-响应匹配（游戏内较少用）

业务后端常用 req/resp 一一对应
游戏服务器多为"指令 + 事件广播"模式：
  客户端发操作，服务器回结果 + 广播给房间
  异步事件（房间状态变化、对手出牌）主动推送

五、顺序、幂等与并发安全

5.1 消息顺序保证

同一玩家的消息必须按到达顺序处理：
  玩家快速连点"出牌/移动" → 顺序不能乱
  EventExecutorGroup 串行天然保证
  注意：异步处理后回队列，仍要保序

5.2 幂等处理

游戏消息幂等场景：
  重复登录、重复领取奖励
  客户端重发（超时重传）
  实现：状态机校验（已登录拒绝重复登录）、防重标志

5.3 并发安全清单

场景	保护方式
同一玩家消息	绑定线程串行
房间共享状态	房间线程/房间锁
Handler 注册表	启动时一次性写入，运行期只读
Session 集合	ConcurrentHashMap
广播集合遍历	快照遍历 / 房间锁

六、监控与排查

需要监控的指标：
  分发延迟（消息入队到处理完成）
  各 Opcode 处理耗时（Top N）
  业务线程池：活跃线程、队列积压
  未注册 Opcode 数（异常流量）

排查链路：
  TraceId 贯穿：网关接收 → 分发 → 业务 → 落库
  慢消息采样日志：Opcode + 耗时 + 玩家

七、小结

消息分发是"网关到业务"的咽喉：MessageDispatcher 用 ConcurrentHashMap<Opcode, MessageHandler> 完成路由，配合 Spring 注解自动注册让新增 Handler 零成本。线程模型是分发设计的灵魂——IO 线程只做编解码，业务线程池处理逻辑，且同一玩家的消息必须串行执行，DefaultEventExecutorGroup 天然满足这一要求。耗时操作异步化并回调到玩家串行线程，保证正确性的同时不阻塞 IO。分发层把"网络字节"翻译成"有序、串行、可监控的业务调用"，是并发正确性的第一道也是最重要的一道保障。

消息分发与路由 ​

概述 ​

一、Opcode 到 Handler 的映射 ​

1.1 分发器核心结构 ​

1.2 自动注册（Spring 集成） ​

1.3 Opcode 命名规范 ​

二、消息线程模型 ​

2.1 核心问题 ​

2.2 串行化原则：同一玩家消息串行 ​

2.3 EventExecutorGroup 方案 ​

2.4 按玩家路由的线程池 ​

三、业务线程池隔离 ​

3.1 分层线程池模型 ​

3.2 阻塞操作规范 ​

四、异步处理与回调 ​

4.1 异步写回 ​

4.2 异步业务回调 ​

4.3 请求-响应匹配（游戏内较少用） ​

五、顺序、幂等与并发安全 ​

5.1 消息顺序保证 ​

5.2 幂等处理 ​

5.3 并发安全清单 ​

六、监控与排查 ​

七、小结 ​

消息分发与路由

概述

一、Opcode 到 Handler 的映射

1.1 分发器核心结构

1.2 自动注册（Spring 集成）

1.3 Opcode 命名规范

二、消息线程模型

2.1 核心问题

2.2 串行化原则：同一玩家消息串行

2.3 EventExecutorGroup 方案

2.4 按玩家路由的线程池

三、业务线程池隔离

3.1 分层线程池模型

3.2 阻塞操作规范

四、异步处理与回调

4.1 异步写回

4.2 异步业务回调

4.3 请求-响应匹配（游戏内较少用）

五、顺序、幂等与并发安全

5.1 消息顺序保证

5.2 幂等处理

5.3 并发安全清单

六、监控与排查

七、小结