我提前道歉这个解释有多长，我不知道如何使它更简洁，因为我想这几乎所有这些都是相关的。遗憾！
我正在使用Twisted设计一个Python游戏服务器（可能不相关，因为这是一个架构问题）。
一般的想法是玩家连接并被放入大厅。然后他们可以排队比赛（例如，死亡竞赛或团队死亡竞赛），并且当找到匹配时，他们被置于该游戏中。比赛结束后，他们将被放回大厅。
因为我知道分布式系统有多复杂，所以我尽量简化它。我想出的想法是将有关玩家的所有信息抽象为对象。所有游戏逻辑都在GameHandler中实现。当玩家连接时，他们被分配到一个Lobby（GameHandler）实例。当他们加入一场比赛时，他们会被重新分配给一个死亡竞赛（GameHandler）实例（它们存放在服务器地图中：gamehandler）。
此时，当玩家被添加到匹配中时，他们实际连接的服务器充当反向代理（我没有写客户端而且它不能被修改，不能有任何连接重新协商）并将有关播放器的信息发送到匹配服务器。然后，使用实例映射，来自该播放器的所有流量都被路由而不被查看它们所在的游戏实例，反之亦然，使用ID系统。我不认为这是一个问题，因为服务器应该都能够在千兆位LAN上转发数据。
当游戏结束时，它只会通知转发玩家的所有大厅服务器（反向代理），并且它们会返回到Lobby实例。
这应该意味着我可以通过添加后端服务器来扩展资源，通过添加更多反向代理大厅服务器来扩展网络链接，我还可以扩展任何单个节点。也没有技术限制迫使后端服务器成为后端，每个服务器都可以有一个Lobby实例，但游戏可以通过网络分发。
现在，到目前为止一直这么好（理论上，我还没有开始实施分发，因为我想事先确定要点），但这留下了一个主要问题：
如何控制所有节点需要知道的元信息？
例如：
我可以实现P2P解决方案或主服务器来处理这类事情。我主要担心的是添加主控制服务器会增加单点故障（我想避免），但P2P解决方案似乎要复杂一个数量级，并且可能会显着降低速度或使用相当数量的资源缓存所有节点上的数据。
所以问题是：我的设计是否合适，您认为这两种元信息问题解决方案的优缺点是什么？有更好的第三种解决方案吗？你认为最好的是什么？
提前感谢您，非常感谢您的帮助。
答案 0 :(得分：1)
有许多解决方案可以实现共享数据库。这取决于您的技术堆栈，网络架构，编程语言等。这个问题太过广泛，无法在几个段落中回答。选择一种方法并继续使用它，但如果需要，可以使代码模块化，以便用另一种方法替换您的方法。
更新：根据你使用Twisted的评论，我会问你一个问题。如果你有一个Twisted服务器集群都是共享网络状态（你的“分布式节点”），你会如何从这些服务器请求你的“复杂操作”，你将如何取回结果？如果您能够足够详细地回答这个问题，那么您将确定节点的要求。然后，您可以确定它们如何共享和更新网络状态。此时，您可以提出更具体的问题（例如“如何在节点间复制内存缓存？”）。