当前位置：首页 > news >正文

像 LOL 一样匹配 —— 动态绑定逻辑服与资源调度

news 2026/5/3 16:27:55

匹配系统的本质问题

LOL、王者荣耀的匹配机制大家都很熟悉：点击匹配 → 等待 → 匹配成功 → 进入对局。但在技术层面，匹配系统需要解决一个核心问题：

如何将匹配成功的玩家，分配到一台最合适的服务器上？

这些玩家可能连接到不同的对外服。分配之后，他们所有的对局操作都必须由同一台逻辑服处理。而且，这台逻辑服应该是当前负载最低的——否则就是人为制造热点。

传统做法需要：Redis 存储匹配状态 + ZooKeeper 做服务发现 + 负载均衡器选节点 + 消息队列同步分配结果。

ionet 用一个 API 就搞定了。

动态绑定逻辑服

ionet 提供了"动态绑定逻辑服"能力。核心概念很简单：

将用户绑定到特定的逻辑服实例，之后这些用户的请求都由该逻辑服处理。

完整匹配流程

以象棋为例，假设部署了 3 台象棋逻辑服：

1. 匹配服找到两个玩家

Player-1 (对外服-1) ──→ 匹配服 ←── Player-2 (对外服-2)

2. 查询哪台象棋逻辑服最空闲

使用 request/multiple_response 通信模型，一次请求获取所有象棋逻辑服的房间数量：

// 向所有同类型逻辑服广播请求，收集响应
var responses = communication.requestMultipleResponse(chessCmd, requestData);// 找到房间数最少的那个
var bestServer = responses.stream().min(Comparator.comparingInt(r -> r.roomCount)).orElseThrow();

3. 将两个玩家绑定到该逻辑服

long[] userIds = {player1Id, player2Id};
int[] logicServerIds = {bestServer.getLogicServerId()};var message = BindingLogicServerMessage.builder(BindingEnum.COVER).addLogicServerId(logicServerIds).addUserId(userIds).build();communication.bindingLogicServer(message);

4. 之后的操作请求自动路由到绑定的逻辑服

Player-1 ──(下棋)──→ ChessLogicServer-2
Player-2 ──(下棋)──→ ChessLogicServer-2  ← 自动路由到同一台

绑定操作类型

ionet 提供了 4 种绑定操作：

操作	说明
`COVER`	覆盖绑定 — 用新的替代旧的
`APPEND`	追加绑定 — 在已有基础上新增
`REMOVE`	移除绑定 — 移除指定的绑定
`CLEAR`	清除所有绑定

FlowContext 还提供了便捷方法，仅对当前用户生效：

// 覆盖绑定当前用户
flowContext.bindingLogicServer(BindingEnum.COVER, logicServerIds);// 清除当前用户所有绑定
flowContext.clearBindingLogicServer();

不只是游戏匹配

动态绑定逻辑服的能力不限于游戏匹配，任何需要"有状态路由"的场景都适用：

场景	绑定对象	效果
LOL 匹配	对局逻辑服	所有操作发到同一服
聊天室	聊天逻辑服	同一房间消息绑定
会议系统	会议逻辑服	参会者请求聚合
IoT 设备组	设备管理服	同组设备路由