这是与以前相同的问题：
我在问我是否应该为每个比赛使用我的node.js游戏进行子进程。
但我意识到以前我忽略了一些非常重要的细节。
游戏允许玩家以某些有限的方式操纵游戏规则。但是，这仍然会导致无限循环/内存泄漏/停顿和崩溃。
每个匹配的1个进程是否可扩展/合理？
答案 0 :(得分：4)
如果任何一个游戏进程都占用了所有内存或CPU，那么这是不可扩展的。如果你的服务器是一个8核的机器，8个游戏可以占用所有的CPU时间，除了通过top监控进程并根据需要杀死它们之外你无能为力 - 但这会导致服务器颠簸
现在，如果你设法首先防止这些东西（听起来对我来说更好），它 是可行的。每个进程将占用超过30mb的内存，因此每隔几百个内存就需要一台强大的服务器。以http://site.nodester.com为例，它们似乎在一台机器上运行大约600个进程。他们的软件堆栈也是开源的：https://github.com/nodester/nodester
node v0.8 will bring Isolates（无共享线程），它可能比子进程使用更少的资源。
对此更为“严肃”的解决方案是使用某种类型的虚拟化，例如OpenVZ，这将允许您设置资源限制，然后只保留一个虚拟服务器池，每个游戏都有它自己的。它并不像它看起来那么重，每台服务器的开销大约为18mb，每台机器可以容纳数百台，尽管它的设置要复杂得多。
答案 1 :(得分：2)
简短的回答是否定的，它不会扩展！
答案很长
让我们首先看一下可扩展性。我采用wikipedia提出的定义：“可扩展性是指系统，网络或流程能够以优雅的方式处理不断增长的工作量或能够扩大以适应这种增长的能力。”
如果您的某个进程耗尽了调度程序（More details on the linux scheduler）授予的CPU，您的系统将无法以“优雅的方式”扩展！因此，您需要的可扩展性是Ricardo Tomasi提出的设置，其中每个匹配都需要它自己的VM。但这并不优雅，并考虑到成本，这是不可行的解决方案。
您的系统无法扩展的问题是它背后的算法，没有架构可以修复它，但算法需要修复。
您修复算法的选项
即使你的算法被修复，为每次匹配产生一个进程也会占用你有限的RAM资源的一些MB，这在可扩展性方面并不优雅。
答案 2 :(得分：1)
我认为 actor模型肯定应该提供可伸缩性：
您可能需要一个主进程来平衡和控制所有进程，跟踪事件等。使用actor模型，您可以跨机器网络扩展，事实上您甚至可以使用对等方如果您希望这样做，可能需要使用RSA密钥进行身份验证。我建议从一个主人开始 只是等待进程连接，实现工作者骨架，看看如何实现控件方面的事情。坚持使用2名工作人员作为初学者，调试起来更简单。
对于Web前端，您还可以使用代理，例如 Nginx ，它将调用主服务器，然后主服务器会告诉它指向新客户端的位置。我想你需要实现一个UI模块，然后在worker中使用它。 我的意思是主人不会提供UI，你的工作人员会在不同的端口上监听，虽然 Nginx 会将其隐藏起来远离用户（他会在URL栏中看不到任何端口）你也可以在此基础上实现RESTful API。
答案 3 :(得分：0)
这是一个难以回答的问题，因为我们不知道你的游戏做了什么...
如果它崩溃，所有游戏都会崩溃，所以我认为有多个过程是个好主意。
但我没有看到为什么你应该有多个过程的任何其他充分理由。 （可能是大量的数据库事务，处理大量文件等等大量的阻塞操作）
就像@Samyak Bhuta所说，你可以永远使用或集群来重启你的过程。我们正在使用monit来实现此目标
答案 4 :(得分：0)
这里有很多事情需要讨论。
有多少玩家可以连接到比赛？
您使用的是哪种数据库？它有快速写入吗？
重新启动进程是最后一个解决方案，因为如果你有一个游戏，一切都应该快速发生，并且你重新开始这个过程，那么在玩家重新连接它之前需要几秒钟。
我不认为每个匹配的一个进程是可扩展的，例如当你同时拥有50.000个匹配时会发生什么？我想说一个更好的解决方案是按照2个标准对儿童过程进行分组：
a）通过匹配id（某种分片算法）
b）如果越来越多的玩家突然出现另一个进程（甚至更多），基于玩家的数量。
在对游戏进行一些测试之前，确定要做什么真的很难。你应该真正测试它，看它是如何表现出几个真正的匹配（它“吃”了多少CPU，内存），并根据数据进行一些分析。没有人能够确切地说出在这种情况下该做什么，因为它取决于项目。