似乎大多数 mmorpg 游戏都会定期进行服务器维护，有些是每天一次，有些是每周一次。他们实际上要做什么，为什么有必要这样做？
如果您开始这样的项目，您可以做些什么来避免这种情况？
答案1
我怀疑他们正在部署最新版本的代码，这需要他们重新启动应用程序（并希望在重新启用访问之前运行一些测试）。从这个角度来看，这更像是 StackOverflow 问题，而不是 ServerFault 问题。
我认为可以创建一个热补丁系统，但它必然会非常复杂。据我所知，MMO 服务器“应用程序”由几个不同的组件组成——
登录服务器-- 处理身份验证并充当游戏服务器之间的“枢纽”。客户端进入游戏后，将不再与登录服务器交互。在这样的系统中，您可以应用补丁并重新启动登录服务器，而不会干扰游戏（尽管会有一段时间人们无法登录）。
游戏服务器-- 将机器集群分组为逻辑上独立的单元（“世界”等）。假设每个游戏集群都使用某种内部通信协议来相互对应状态；您可能需要一次性修补每个集群。一种可能的方法是修补热故障转移。然后您需要能够同时
- 向客户端发出信号，使其连接到温故障转移并断开与旧集群的连接。
- 在所有客户端进行传输时，保持故障转移和过时的应用程序服务器之间的状态同步。
数据库服务器-- 某种持久性数据存储，如 RDBMS。希望您不会经常更改数据存储。大概每个游戏服务器/集群都有一个独立的数据存储。您可能能够使用相同的技巧进行热故障转移（并告诉游戏服务器断开连接，等待旧数据库和故障转移数据库同步，然后重新连接到故障转移），但这对我来说似乎非常危险。
所有上述情况都会给本已复杂的系统增添难以置信的复杂性，并引入了许多代码故障可能导致数据丢失或损坏的地方。
另一个解决方案是使用一种专为 100% 正常运行时间而设计且具有内置热修补运行代码功能的语言。Erlang是一个不错的选择（热补丁示例）， 和Java 有类似的功能。
答案2
没有其他人有实际运行此类程序的经验吗？呵呵。
有多种原因将代码和系统联系起来。首先，请记住，大多数当前的“大型” MMO 引擎都是几年前编写的，尽管此后图形和技术进行了升级，但仍然依赖于 2000 年左右编写的许多系统的方式。例如，Eve-Online 仍然在一个巨大的 Microsoft SQL Server 实例上运行，这就是为什么他们总是试图通过升级硬件来从中获得更多收益。
自 WoW 和 EVE 开始以来，改进的一个例子是在分布式键/值数据库（如 Google 的 MapReduce（及其开源实现 Hadoop）、极快的肯定响应处理队列服务（Amazon SQS））和其他面向“云”的技术中所做的工作。
我对 EVE 最有经验（我更喜欢激光而不是战斧），所以其中一些例子更多地是以 EVE 为导向的。
就系统原因而言：
- 物理节点经常发生故障。当一个节点发生故障时，通常会使用多种方式将其活动迁移到其他地方。但是，该节点需要尽快恢复服务。在 EVE 的情况下，他们同时使用无堆栈处理语言和虚拟服务器；我不确定暴雪的架构是什么样的。
- 需要检查数据库一致性、刷新日志、重建索引和数据缓存。这对于像 EVE 这样只有一个“实时”数据库实例的系统来说尤其重要。
- 操作系统补丁需要在可以重启节点时应用，而不必将太多活动迁移到其他地方。迁移会占用大量网络资源，而这些资源原本可以用于在线处理。
- 基于 RDBMS 的 MMO 在数据锁定和引用完整性方面存在巨大问题。停机时间用于从活动日志中清除陈旧的锁定和完整性破坏。
- 大多数游戏都在频繁使用的区域（即美国东海岸和西海岸）实施地理位置数据缓存，用于存储静态或半静态信息（请参阅下面的缓存摘要数据）。这些缓存在停机期间手动更新。
就软件原因而言：
- 游戏在运行时会使用大量 OLTP（即在线事务处理）类型的数据库读取/写入。但是，有时您需要一份摘要报告……例如，在过去 3 年的磨练中您杀死了多少只特定野兽。最好通过 OLAP 报告（即在线分析处理）来处理，其中包含基于大量数据集中的行的摘要信息。实际上，游戏会实现使用 OLAP 构建缓存的系统，以限制需要读取的查询数量——即，它们会构建截至某个日期的总数，然后当您提出问题时，它们只会从 OLTP 存储中读取总结自特定日期以来的时间段的行。将两者合并，您就可以量化您的生活变得多么毫无价值。
- 前面提到的热补丁，我认为是软件问题，但软件开发人员认为是系统问题。;)
- 补充物品库存——在《星战前夜》中，小行星带每晚都会更新，某些建筑群也会被回收。这在一定程度上可以在线完成，但有些算法过于复杂，需要在离线模式下完成，因为它们会在汇总前一天的经济活动时短暂地使数据库瘫痪。
对于 MMO 运营商来说，运营一个既有闭环又有开环的经济系统是一个问题——如果你不相信我的话，可以读读一些关于游戏经济的学术论文，以及一些关于《网络创世纪》等经济系统相对原始的旧游戏的研究。补充开环和识别作弊行为和其他负面经济活动所需的分析需要离线进行，并且需要对数据进行快照，而有时只有在数据库完全锁定时才能进行快照。
如果你注意到的话，Eve 的维护发生在主数据中心所在的英国中午时分。
答案3
我怀疑暴雪 (我推断这是因为你是在星期二早上发布问题的) 所说的维护总时间是针对整个集群的；并不是每个服务器都需要那么长时间来完成工作。
虽然可以更快地恢复单个服务器，但这会引起对那些在计划中较早被关闭的服务器的偏袒。因此，他们会暂停一切，直到所有工作完成；由于有数百个服务器需要处理，他们可能会同时完成大部分工作，但在恢复在线状态之前仍会进行最终检查。如果您正在进行硬件升级，这可能会在他们拥有的尽可能多的数据中心中进行序列化。
至于他们进行维护的原因，部分原因可能只是性能重启。虽然如果不需要进行此类重启会很好，但这样做的成本与不这样做的影响可能是他们做出此选择的原因。
当您查看为什么它们无法集群化进程并执行滚动维护时，人们对 WoW 基础设施知之甚少，他们认为多台机器为每个领域提供服务（即一台用于世界，一台用于实例和突袭，一台用于战场等），它们不使用状态共享的主动-主动进程设置。没有实时状态共享，只有通过数据库共享持久数据。
最后，向如此庞大的用户群提供有状态的在线服务的机制挑战了我们在谈论网站或其他传统基于互联网的服务时可能倡导的一些最佳实践。
答案4
大概是您无法通过集群/负载平衡来处理的事情，例如重大的数据库模式更改。