本文在战斗服管理器横向扩展的基础上继续延伸，讨论管理器全互联之后的负载均衡问题。
管理器实现全互联后，就不再依赖 Redis，各节点之间可以直接互发消息。对于本服不存在的房间号，可以通过房间号加密混淆可逆算法直接定位目标组，然后将请求转发过去。为了避免请求被二次转发，一个简洁的做法是用两个独立的 RPC 函数来区分"本服处理"和"跨服转发"两种路径。
跨服加入房间的问题解决后，剩下的两个核心问题都涉及负载均衡：
- 当本服创建房间失败时，需要把请求转发给其他管理器处理（即跨服开房间）。
- 当本服单人匹配失败时，同样需要转发给其他管理器处理（即跨服单人匹配）。
跨服单人匹配
目前单人匹配和创建房间都只在本服内处理，一旦涉及跨服操作，就需要分开设计。
单人匹配的跨服策略，理论上应尽可能采用全服填坑式——按服务器组逐组塞满，让全服玩家都有机会相互匹配到。
问题的根源在于管理器本身是多实例的。如果全服只有一个管理器，逻辑会简单很多，但单点吞吐量不足——因为管理器同时还承担战斗服的负载均衡职责，全服所有战斗服都挂在它下面，压力会非常大。
方案一：独立匹配服（Match）
新增一个服务器角色——匹配服（Match），全服只部署一台或极少数几台，同台玩家之间可以相互匹配。设计原则是功能尽可能简单，同时将网络 IO 协程容量尽可能做大，因为匹配等待时间可能较长，需要保证服务器在高并发长连接下的处理能力。
TODO