对于这个解释有多长，我提前道歉，我不知道如何使它更简洁，因为我想几乎所有这些都是相关的。对不起！
我正在用 Twisted 用 Python 设计一个游戏服务器（可能不相关，因为这是一个架构问题）。
一般的想法是玩家连接并被放置在大厅中。然后他们可以排队参加比赛（例如，死亡竞赛或团队死亡竞赛），并且当找到比赛时，他们会被放入该游戏中。当游戏结束时，他们被放回大厅。
因为我知道分布式系统有多么复杂，所以我尝试尽可能地简化它。我想出的想法是将有关玩家的所有信息抽象到一个对象中。所有游戏逻辑都在 GameHandler 中实现。当玩家连接时，他们被分配到一个 Lobby(GameHandler) 实例。当他们加入比赛时，他们被重新分配到一个死亡比赛（GameHandler）实例（保存在服务器地图中：gamehandler）。
此时，当玩家被添加到比赛中时，他们实际连接的服务器充当反向代理（我没有写客户端，不能修改，不能有任何连接重新-negotiation）并将有关玩家的信息发送到比赛服务器。然后，使用实例地图，来自该玩家的所有流量都被路由到他们所在的游戏实例，反之亦然。我认为这不是问题，因为服务器都应该能够在千兆 LAN 上转发数据。
当游戏结束时，它只会通知所有转发玩家的大厅服务器（反向代理），然后他们会返回到大厅实例。
这应该意味着我可以通过添加后端服务器来扩展资源，通过添加更多反向代理大厅专用服务器来扩展网络链接，并且我还可以在任何单个节点上进行扩展。也没有强制后端服务器成为后端的技术限制，每台服务器都可以有一个 Lobby 实例，但游戏可以通过网络分发。
现在，到目前为止一切顺利（理论上，我还没有开始实施分发，因为我想事先弄清楚要点），但这留下了一个主要问题：
如何控制所有节点都需要知道的元信息？
例如：
- 在客户端连接之前，服务器列表显示多少玩家在线？
- 是否以某种 P2P 方式实现了匹配（我计划使用 Microsoft 的 TrueSkill 算法，如果这很重要），还是我应该为此委托整个服务器（甚至是元信息）？
- 玩家一起排队的派对系统怎么样？哪个服务器跟踪组中的玩家？
- 我如何管理配置，例如被禁止的玩家？每个转发服务器都需要了解它们。
- 如果玩家连接的大厅实例碰巧已满，我如何找到另一个未满的大厅实例，以便将他们的连接路由到那里？这又回到了第一点，我需要有一种方法让节点轻松查询网络状态
我可以实现一个 P2P 解决方案，或者一个主服务器来处理这类事情。我主要担心的是添加主控制服务器会增加单点故障（我想避免这种情况），但 P2P 解决方案似乎要复杂一个数量级，并且可能会显着减慢速度或使用相当数量的资源在所有节点上缓存数据。
所以问题是：我的设计是否体面，你认为这两种解决元信息问题的优缺点是什么？有没有更好的第三个解决方案？你认为什么是最好的？
提前感谢您，非常感谢您的帮助。