【问题标题】:Scalability advice for large game site大型游戏网站的可扩展性建议
【发布时间】:2011-04-17 19:20:41
【问题描述】:

我正在建立一个网站,玩家可以在其中玩虚拟积分的回合制游戏(类似于扑克网站,但有所不同)。我想出的设置:

  • 一个数据服务器,包含所有玩家帐户和相关数据(数据库+服务)。如果有帮助,可以将数据库和 API 拆分为两个服务器。
  • 一个或多个为网站提供服务的网络服务器,在需要时连接到数据服务器。
  • 一个大厅服务器,玩家可以在其中找到彼此并设置游戏(可以多个,但用户友好性较差)
  • 运行游戏的多个游戏服务器(所有规则等都在服务器上,客户端只是一个远程控制和查看器),带有一个负载平衡器。
  • 游戏客户端

客户端将使用 Flash 制作,网络服务器将使用 PHP。剩下的都是Java。

通讯

  • 玩家登录网站。网络服务器将用户名/密码发送到数据服务器,数据服务器创建一个会话密钥(如 cookie)
  • 播放器启动客户端。客户端连接到大厅服务器,传递会话密钥。大厅服务器与数据服务器检查此密钥
  • 创建大厅并且必须开始游戏后,大厅服务器会从负载平衡器中获取游戏服务器并在此游戏服务器上设置游戏。
  • 大厅服务器通知客户端连接到游戏服务器并开始游戏。
  • 游戏结束后,游戏服务器会通知大厅服务器。大厅服务器将检查分数并更新数据服务器中的积分。

协议

  • Java 到 Java:RMI
  • PHP 或 Flash 到 Java:通过套接字自定义二进制协议。该协议支持在空闲时关闭套接字,同时保持虚拟连接处于活动状态和可恢复状态。

如果客户有他的意愿,该网站将需要支持成千上万的并发玩家。有了这些信息,您能看到我的设置中的任何瓶颈吗?我个人有点担心只有一个数据服务器的存在,但我不知道如何拆分它。也欢迎其他可扩展性(或其他)评论。

【问题讨论】:

  • @更接近:这不属于服务器故障,因为它不是通过简单添加服务器来解决的,而是必须在开发阶段设计。
  • 您的实际问题似乎与扩展数据库和定位瓶颈有关。这确实更像是一个 DBA 问题而不是开发人员问题。开发人员也许可以帮助改进表格设计,但您没有发布有关表格的任何详细信息。也高度依赖于未命名的数据库实际上是什么。 - 需要为游戏成功完成而准备的大厅对我来说似乎是一个设计问题。如果我的游戏结束时大厅服务器关闭了一段时间,如果你输掉了我的游戏结果,我会很高兴的。
  • @Affe:我可以改变它,大厅服务器告诉数据服务器游戏已经开始,游戏服务器在游戏结束时告诉数据服务器,无需大厅参与。

标签: java php flash networking scalability


【解决方案1】:

您的架构有许多单一服务,这些服务对于系统的任何部分为任何用户工作都至关重要。我考虑这些SPOFs。

  • 您可能需要为您的数据服务器考虑sharding(或水平分区)。
  • 考虑多个大厅服务器。如果您愿意,Flash 客户端仍然可以将它们伪装成单个大厅。就我个人而言,我不喜欢和无法用任何我不懂的语言交谈的人玩游戏。另外,我不喜欢加入大厅服务器,发现有成千上万的游戏,却不认识任何人。使多个大厅成为一项功能(当您考虑它时,您真的可以)。拥有 10000 人的大厅没有真正的用处。如果您仍然想通过它,您仍然可以尝试分区,基于玩家过滤特定参数(对手级别,游戏类型等)的假设,尝试按照一个甚至多个标准分割大厅。李>
  • 我想负载平衡器实际上并不需要足够的电力来成为物理服务器。为什么不在所有大厅服务器上复制它?它只需要知道可用性/服务器。假设你有 10000 个游戏服务器(我认为在这种情况下是一大堆)和 1 秒的刷新率(这在这里远远超过了),你同步的只是每秒 10000 个整数(假设你可以将可用性表示为一个数字(我想你可以))。如果您想出比将每个游戏服务器与每个大厅服务器连接更好的方法,那么这甚至不需要在一台机器上进行太多连接。

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

【讨论】:

    【解决方案2】:

    我曾开发过几款 Facebook 游戏,我想说的是:

    考虑为数千名玩家提供可扩展性,但您必须获得数以万计的玩家,然后为这些玩家进行扩展的努力才能获得回报。

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

    我怀疑您描述的设置对于您的初始用户群来说会表现得很好。在构建过程中,请避免执行以下操作: 要求登录服务器与大厅服务器通信。让每台服务器独立运行,最重要的是服务之间的相互依赖关系。

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

    【讨论】:

    • 我肯定会在这里走敏捷的道路,成千上万的并发用户是未来的事情。最初,所有这些服务都将在一个机器上运行。尽管如此,我还是想知道我能期待什么,这样我就不会把自己编程到一个角落里。
    猜你喜欢
    • 2011-11-14
    • 2011-08-12
    • 1970-01-01
    • 1970-01-01
    • 2021-07-22
    • 1970-01-01
    • 1970-01-01
    • 2011-06-20
    • 1970-01-01
    相关资源
    最近更新 更多