所以我现在正在开发一个 node.js 游戏服务器应用程序，我在这里遇到了一些障碍。我的问题是我正在使用 socket.io 接受来自游戏客户端的入站连接。这些客户端可能连接到游戏世界的几个区域或区域之一。
基本架构如下所示。主进程为运行 Zone Manager 进程的游戏的每个 Zone 派生一个子进程；专用于维护区域数据（3d 模型、玩家/实体的位置等）的过程。然后，主进程为它创建的每个区域管理器派生多个“通信线程”。这些线程创建一个 socket.io 实例并监听该区域的端口（多个线程监听一个端口）。这些线程将在自己的进程中处理大部分游戏逻辑，并与支持游戏服务器的数据库进行通信。唯一的问题是，在某些情况下，他们可能需要与区域管理员沟通以接收有关区域、玩家等的信息。
例如：玩家想要与区域中的非玩家角色 (NPC) 进行买卖/交易。区域通信线程需要询问区域管理器线程，如果玩家距离 NPC 足够近，可以进行交易，然后才允许交易发生。
我在这里遇到的问题是我打算利用 node.js 集群功能并使用进程的send()和on()方法来处理来回传递消息。这很好，除了我遇到的一个警告。由于所有子进程都与cluster.fork()只能与“主”进程通信。node.js 根进程成为所有通信的瓶颈。我使用一个脚本在我的系统上运行了一些基准测试，该脚本实际上只是使用集群的进程间通信 (IPC) 来回反弹一条消息，并跟踪每秒执行了多少次中继。就它可以中继的 IPC 数量而言，似乎最终节点的上限约为每秒 20k。这个数字在 Phenom II 1.8ghz 四核笔记本电脑和 FX-8350 4.0ghz 8 核台式机上都是一致的。
现在这听起来相当高，除了这基本上意味着无论有多少区域或通信线程，所有 IPC 仍然通过充当整个应用程序“中继”的单个进程成为瓶颈。这意味着虽然每个单独的线程似乎每秒可以中继 > 20k IPC，但整个应用程序作为一个整体永远不会中继超过这个数量，即使它在一些疯狂的 32 核系统上，因为所有通信都通过单个线程进行。
这就是我遇到的问题。现在进退两难了。我已经阅读了很多关于那里的各种其他选项的内容，并且在堆栈上阅读了关于这个主题的 20 个不同的问题，并且我经常看到一些事情弹出：
Redis： 我现在实际上在我的服务器上运行 Redis，并将其用作 socket.io 数据存储，以便多个线程中的 socket.io 可以共享连接数据，以便用户可以连接到 N 个 socket.io 中的任何一个区域的线程，以便服务器可以自动对传入连接进行负载平衡。
我对此的担心是它通过网络堆栈运行。几乎不适合同一服务器上的多个进程之间的通信。我觉得从长远来看，延迟将是一个主要问题。
0MQ (zeromq/zmq)： 我以前从未将这个用于任何事情，但我最近听到了一些关于它的消息。根据我所做的阅读，我发现了很多人将它与 TCP 套接字一起使用的例子，但关于人们将它用于 IPC 的讨论并不多。我希望也许这里有人曾经使用过 0MQ for IPC（甚至可能在 node.js 中？）并且可以为我提供一些关于这个选项的信息。
dnode： 同样，我从未使用过它，但从我所见，它看起来像是另一种设计用于通过 TCP 工作的选项，这意味着网络堆栈再次受到阻碍。
node-udpcomm： 有人在这里的另一个问题中链接了这个（不幸的是，我似乎无法再次找到）。我什至从未听说过它，它看起来像是一个非常小的解决方案，可以打开并侦听 UDP 连接。尽管这可能仍然比 TCP 选项更快，但我们仍然有网络堆栈，对吗？我绝对像这里一样在我的“程序员区”之外大约一英里，并且很好地进入了我不太了解的网络/计算机架构领域，哈哈
无论如何，底线是我完全被困在这里，不知道在这种情况下 IPC 的最佳选择是什么。我目前假设 0MQ 是我上面列出的那些选项中的最佳选择，因为它似乎是唯一一个为通信协议提供“IPC”选项的选项，我认为这意味着它使用的是 UNIX 套接字或其他东西没有通过网络堆栈，但我无法确认或任何事情。
我想我只是希望这里的一些人知道的足够多，可以为我指出正确的方向，或者告诉我我已经去那里了。我正在从事的项目是一个多人游戏服务器，旨在“开箱即用”地与多人游戏客户端一起使用 Three.js 为其 3D 图形/计算提供动力。一旦我让它们都工作到我满意，客户端和服务器就会对所有人开放源代码，我想确保架构尽可能可扩展，这样人们就不会在此基础上构建游戏然后再去扩展起来并最终撞到墙上。
无论如何，如果你真的阅读了所有这些，谢谢你的时间:)