大型游戏网站的可扩展性建议

Question

我正在建立一个网站，玩家可以在其中玩虚拟积分的回合制游戏（如扑克网站，但不同）。我提出的设置：

• 一个数据服务器，包含所有具有关联数据的玩家帐户（数据库+服务）。如果有帮助，数据库和API可以分成两个服务器。
• 为网站提供服务的一个或多个网络服务器，在需要时连接到数据服务器。
• 一个大厅服务器，玩家可以找到彼此并设置游戏（多个可能，但用户不太友好）
• 运行游戏的多个游戏服务器（所有规则都在服务器上，客户端只是一个遥控器和查看器），有一个负载均衡器。
• 游戏客户端

客户端将使用Flash制作，网络服务器将使用PHP。其余的都是Java。

通信

• 播放器登录网站。 Web服务器将用户名/密码发送到数据服务器，从而创建会话密钥（如cookie）
• 玩家启动客户端。客户端连接到大厅服务器，传递会话密钥。大厅服务器使用数据服务器检查此密钥
• 一旦创建了一个大厅并且游戏必须开始，大厅服务器就从负载均衡器中取出一个游戏服务器并在该游戏服务器上设置一个游戏。
• 大厅服务器告诉客户连接到游戏服务器并播放游戏。
• 当游戏结束时，游戏服务器让大厅服务器知道。大厅服务器将检查分数并更新数据服务器中的信用。

协议：

• Java to Java：RMI
• PHP或Flash to Java：通过套接字自定义二进制协议。该协议支持在空闲时关闭套接字，同时保持虚拟连接的活动和可恢复。

如果客户有他的意愿，该网站将需要支持数千个并发玩家。有了这些信息，你能看到我设置中的任何瓶颈吗？我个人有点担心只存在一个数据服务器，但我不确定如何分解它。其他可扩展性（或其他）评论也是受欢迎的。

Answer 1

您的架构有许多单一服务，这些服务对于任何用户的系统任何部分都至关重要。我认为这些是SPOF。

• 您可能需要考虑数据服务器的sharding（或水平分区）。
• 考虑多个大厅服务器。如果您愿意，Flash客户端仍然可以将它们伪装成单个大厅。就个人而言，我不喜欢和我不懂的任何语言的人交游戏。此外，我不喜欢加入大堂服务器找到n千游戏而不认识任何人。让多个大厅成为一个特征（当你把思想放入其中时，你真的可以）。拥有10000人的大堂没有真正的用途。如果您仍然想要使用它，您仍然可以尝试分区，基于玩家过滤特定参数（对手级别，游戏类型等）的假设，尝试按照一个甚至多个标准分割大厅。
• 我认为负载均衡器实际上并不需要足够的电力来作为物理服务器。为什么不在所有大厅服务器上复制它？它必须知道的是可用性/服务器。假设你有10000个游戏服务器（在这种情况下我认为这是一个完整的他妈的很多），刷新率为1秒（这里远远不够），你同步的每秒10000个整数（让我们假设你可以将可用性表示为数字（我想你可以））。如果你找出比将每个游戏服务器连接到每个大厅服务器更好的东西，这甚至不需要在一台机器上连接太多。

在这种类型的应用程序中，我认为水平分区是一个好主意，因为对于一个它可以轻松完成并增加系统的可靠性。假设您的SPOF是分区的，而不是冗余的。这更容易，也可能更便宜。如果SPOF的一部分出现故障（假设您的20个独立和物理分布式数据服务器中有1个），这很糟糕，因为5％的玩家被锁定了。但可能很快就会起床。如果您的SPOF是多余的，那么任何失败的可能性都会降低。但如果确实如此，那么每个人都会被锁定。这是一个问题，因为你会让所有人同时尝试重新上线。一旦你的SPOF回来了，它会受到一些高于它通常要处理的请求数量级的命中。并且您仍然可以同时使用水平分区和冗余，如平衡服务所建议的那样。

Answer 2

参与了几场Facebook游戏，我会说：

考虑成千上万玩家的可扩展性，但是在为这些玩家进行扩展之前，你必须得到成千上万的玩家。

也就是说，提前计划，但担心在为数千名并发玩家计划系统之前获得1名玩家。

我怀疑您描述的设置对初始用户群的效果非常好。在构建时，请避免执行以下操作：要求登录服务器与大厅服务器通信。让每个服务器都独立存在，杀死你的大事是服务之间的相互依赖。

但最重要的是，尽可能以最便捷的方式完成。如果你有足够的用户对你的系统征税，这将是一件非常好的事情。您可以聘请DBA来帮助您了解在拥有那么多用户时如何扩展。