对于这个解释有多长,我提前道歉,我不知道如何使它更简洁,因为我想几乎所有这些都是相关的。对不起!
我正在用 Twisted 用 Python 设计一个游戏服务器(可能不相关,因为这是一个架构问题)。
一般的想法是玩家连接并被放置在大厅中。然后他们可以排队参加比赛(例如,死亡竞赛或团队死亡竞赛),并且当找到比赛时,他们会被放入该游戏中。当游戏结束时,他们被放回大厅。
因为我知道分布式系统有多么复杂,所以我尝试尽可能地简化它。我想出的想法是将有关玩家的所有信息抽象到一个对象中。所有游戏逻辑都在 GameHandler 中实现。当玩家连接时,他们被分配到一个 Lobby(GameHandler) 实例。当他们加入比赛时,他们被重新分配到一个死亡比赛(GameHandler)实例(保存在服务器 map 中:gamehandler)。
此时,当玩家被添加到比赛中时,他们实际连接的服务器充当反向代理(我没有写客户端,无法修改,不能有任何连接重新-negotiation)并将有关玩家的信息发送到比赛服务器。然后,使用实例 map ,来自该玩家的所有流量都被路由到他们所在的游戏实例,反之亦然。我认为这不是问题,因为服务器都应该能够在千兆 LAN 上转发数据。
当游戏结束时,它只会通知所有转发玩家的大厅服务器(反向代理),然后他们会返回到大厅实例。
这应该意味着我可以通过添加后端服务器来扩展资源,通过添加更多反向代理大厅专用服务器来扩展网络链接,并且我还可以在任何单个节点上进行扩展。也没有强制后端服务器成为后端的技术限制,每台服务器都可以有一个 Lobby 实例,但游戏可以通过网络分发。
现在,到目前为止一切顺利(理论上,我还没有开始实现分发,因为我想事先弄清楚要点),但这留下了一个主要问题:
如何控制所有节点都需要知道的元信息?
例如:
我可以实现一个 P2P 解决方案,或者一个主服务器来处理这类事情。我主要担心的是添加主控制服务器会增加单点故障(我想避免这种情况),但 P2P 解决方案似乎要复杂一个数量级,并且可能会显着减慢速度或使用相当数量的资源在所有节点上缓存数据。
所以问题是:我的设计体面吗?您认为这两种解决元信息问题的方法的优缺点是什么?有没有更好的第三个解决方案?你认为什么是最好的?
提前感谢您,非常感谢您的帮助。
请您参考如下方法:
实现共享数据库的解决方案有很多。这取决于您的技术堆栈、网络架构、编程语言等。这个问题太宽泛,无法在几段中回答。选择一种方法并采用它,但使您的代码足够模块化,以便在必要时用另一种方法替换您的方法。
更新:根据您使用 Twisted 的评论,我会问您一个问题。如果您有一个 Twisted 服务器集群,它们都共享网络状态(您的“分布式节点”),您将如何从这些服务器请求您的“复杂操作”以及如何取回结果?如果你能足够详细地回答这个问题,你就已经确定了你的节点的要求。然后您可以确定它们如何共享和更新网络状态。此时,您可以提出一个更具体的问题(例如“如何在我的节点之间复制 memcache?”)。
