MMORPG服务器维护

我怀疑他们正在部署他们的代码的最新版本，这要求他们重新启动应用程序（并希望在重新启用访问之前运行一些testing）。 从这个angular度来看，它更像是一个StackOverflow问题，更less一个ServerFault问题。

我认为有可能创build一个热补丁系统，但这一定会非常复杂。 据我所知，一个MMO服务器“应用程序”由几个不同的组件组成 –

• login服务器 – 处理身份validation，充当游戏服务器之间的“中心”。 一旦客户端在游戏中，他们不再与login服务器交互。 在这样的系统中，您可以应用修补程序并重新启动login服务器，而不会干扰游戏（尽pipe您将有一段时间无法login）。

• 游戏机服务器 – 分组为独立逻辑单元（“世界”等）的机器簇。 假定每个游戏集群使用某种内部通信协议来相互对应状态; 你可能不得不一次性修补每个簇。 一种可能的方法是修补一个温故障转移。 那么你需要能够两个

  1. 指示客户端连接到温故障转移，并从旧集群断开连接。
  2. 在所有客户端进行传输的同时，保持故障切换和过时的应用程序服务器之间的状态保持同步。

• 数据库服务器 – 某种持久性数据存储，就像RDBMS一样。 希望你没有经常更改数据存储。 据推测每个游戏服务器/集群都有一个独立的数据存储。 您也许可以使用相同的技巧进行热切换（并告诉游戏服务器断开连接，等待旧数据库和故障切换数据库同步，然后重新连接到故障切换），但对我来说这似乎相当危险。

上述所有情况都会给已经很复杂的系统增加难以置信的复杂度，并引入一些代码失败可能导致数据丢失或损坏的地方。

另一种解决scheme是使用专为100％正常运行时间devise的语言，并具有对运行代码进行热修补的内置function。 Erlang是一个不错的select（ hotpatching的例子 ）， Java有类似的function 。

没有其他人有经验，实际上运行这样的事情？ 呵呵。

桥接代码和系统有几个原因。 首先，请记住，目前大部分“大型”MMO引擎是在几年前编写的，尽pipegraphics和技术升级，但仍取决于这些系统中的许多是在2000年左右编写的。 例如，Eve-Online仍然运行在一个巨大的Microsoft SQL Server实例上，这就是为什么他们总是试图通过升级硬件来实现更多function的原因。

自从WoW和EVE开始以来，一个改进的例子就是在分布式键/值数据库（例如Google的MapReduce（及其开源实现，Hadoop），极快的肯定性响应处理队列服务（Amazon SQS）以及其他“云“为导向的技术。

我拥有EVE最多的经验（我更像是一个激战家伙，而不是一个战斧的家伙），所以这些例子中的一些更多的是面向EVE的。

就系统原因而言：

• 物理节点在一致的基础上失败。 当一个节点发生故障时，通常使用任何方式将活动迁移到其他地方。 但是，节点需要尽快恢复服务。 在EVE的情况下，他们使用无堆栈处理语言和虚拟服务器; 我不确定暴雪的架构是什么样的。
• 数据库一致性需要检查，日志需要刷新，索引和数据caching需要重build。 这在像EVE这样只有一个“实时”数据库实例的系统中尤为重要。
• 操作系统补丁需要在重新启动节点的时候应用，而不必在其他地方迁移太多的活动。 迁移占用了大量的networking资源，否则可能致力于在线处理。
• 基于RDBMS的MMO在数据locking和参照完整性方面存在巨大的问题。 停机时间用于清除活动日志中的旧锁和完整性中断。
• 大多数游戏在重要使用地区，即东海岸和美国西海岸，实施静态或半静态的地理位置数据caching（请参阅下面的caching摘要数据）。 这些caching在停机时间内手动更新。

就软件原因而言：

• 游戏在运行时使用大量的OLTP – 即在线事务处理 – 对数据库的读/写types。 然而，有时候你需要一份总结报告，比如你在过去三年中磨死了多less兽。 这最好由OLAP报告处理 – 即在线分析处理 – 其中包含基于巨量数据集中的许多行的摘要信息。 实际上，游戏实现的系统使用OLAP来构build一个caching，以限制需要读取的查询数 – 也就是说，它们构build一个特定date的总数，然后当您提出问题时，他们只是读取行从OLTP商店中总结出自某个date以来的时间段。 合并这两个，你可以量化你的生活变得多么无价值。
• 前面提到的热补丁，我认为这是一个软件问题，但软件开发人员认为这是一个系统问题。 ;）
• 补充物品存储 – 在夏娃，小行星带每晚更新，某些复合物也被回收。 这可以在线上完成，但是某些algorithm过于复杂，需要在离线模式下完成，因为它们在简要介绍前一天的经济活动的同时，简要地将数据库引入其中。

经营一个既封闭又开放的循环经济是MMO运营商面临的一个问题 – 如果你不相信我，请阅读一些关于游戏经济学的学术论文，以及Ultima Online等老游戏的一些研究。有相对原始的经济。 需要进行的分析来补充开放循环，识别作弊和其他负面经济活动需要在数据的快照下离线发生，有时只能在数据库完全locking的情况下进行。

如果你会注意到，夏威夷的维护是在英国这个主要数据中心的中午发生的。

我怀疑，暴雪（我推断，假设这是一个星期二早晨，你发布你的问题）维修报价的总时间是整个集群; 不是每个服务器都需要很长时间才能完成工作。

虽然有可能使个别服务器更快地恢复，但是对于那些在领先时间早些时候下降的玩家来说，这将会非法地咆哮。 因此，他们把所有的事情都放下来，直到所有的工作完成。 有数百个领域的工作，他们可能并行地完成大部分工作，但是在将事情恢复到在线状态之前，仍然要对最终的检查进行序列化。 如果您正在进行硬件升级，则可能需要在尽可能多的数据中心上进行序列化。

至于为什么他们执行维护，其中一些可能只是性能重启。 如果不需要这样的重新启动会很好，但这样做的成本与不这样做的影响可能是在这里指导他们的select。

当你看看为什么他们不能集群进程和执行滚动维护时，人们对魔兽世界基础设施的了解就表明，多个机器为每个领域提供服务（例如，一个为世界，一个为实例和raid，一个为战场等），它们不使用状态共享的主动 – 主动过程设置。 没有实时状态共享，只有通过数据库的持久数据共享。

最后，向大量用户群提供有状态的在线服务的机制挑战了我们在讨论网站或其他传统的基于互联网的服务时可能支持的一些最佳实践。

EvE Online中最近发生的一些延迟停机时间是关于像更快的SAN一样安装新的硬件。 虽然在技术上可以通过在新驱动器上创build一个新的文件组来移动大部分数据，然后清空主驱动器，但由于持续的I / O会导致性能下降。 所以他们select分离1.1TB数据库并一次性移动它。

这个问题的答案也依赖于具体的应用。 例如，处理特定明星系统的服务器不能在不中断游戏的情况下被激活，所以使用停机时间将更强大的服务器重新分配到潜在的热点。 另外，计算星系的所有权计算（主权）。 这取决于几十个不同的variables，所有这些都可以根据玩家的行动而改变。 不用说，这样做会导致过多的locking和/或其他并发问题。 但是解决这些问题最好留给计算器 。

大概是你不能通过集群/负载平衡（比如主要数据库模式更改）处理的东西。

在最近的一个话题中， 我应该多长时间重新启动一次linux服务器 ，提到另外一个好处，validation在重新启动或任何（重大）configuration更改之后，所有设备都能正常启动。

硬件（或硬件更换）的简单升级也被MMORPG游戏称为“服务器维护”。 如此微不足道，我们经常忘记它。

我在Erlang中实现了一个支持热代码升级和分发的MMO体系结构。 例如，一个“GamePlay服务器”可以在任意数量的机器上运行，如果需要进行硬件升级，其对象可以（实时）传送到其他机器。 这使得软件硬件升级没有任何停机时间。

你可以查看我的网站http://www.next-gen.cc 。

我被带到相信维护窗口也允许例行的硬件replace，以确保组件不会失败。