node.js 集群中的子进程间通信选项

Question

所以我目前正在开发一个 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 图形/计算提供动力。一旦我让它们都工作到我满意，客户端和服务器将向所有人开放源代码，我想确保架构尽可能可扩展，这样人们就不会在此基础上构建游戏然后再去扩展起来，最后撞到了墙上。

如果您真的阅读了所有这些内容，无论如何感谢您的时间:)

Answer 1

我认为0MQ会是一个很好的选择，但我承认我不知道其他人:D

对于 0MQ，您决定使用什么传输是透明的，库调用是相同的。这只是在开始调用zmq_bind 和zmq_connect 期间选择特定的端点（以及因此传输）。基本上有 4 条路径可供您决定：

1. "inproc://<id>" - 线程之间通过内存进行的进程内通信端点
2. "ipc://<filepath>" - 系统相关的进程间通信端点
3. "tcp://<ip-address>" - 清除
4. "pgm://..." 或 "epgm://..." - 实用可靠多播的端点

简单地说，您在列表中的位置越高，速度越快，考虑到延迟和可靠性方面您必须面对的问题就越少。所以你应该尽量保持尽可能高。由于您的组件是进程，因此您自然应该使用 IPC 传输。如果您以后需要更改某些内容，只需更改端点定义即可。

现在，实际上比您选择的传输方式更重要的是套接字类型，或者说是您决定使用的模式。您的情况是典型的请求-响应式通信，因此您可以这样做

1. 管理器：REP 套接字，线程：REQ 套接字；或
2. 经理：ROUTER，线程：REQ 或 DEALER

线程然后将它们的套接字连接到分配给它们的单个管理器套接字，仅此而已，它们可以开始发送请求并等待响应。他们所要决定的只是他们用作端点的路径。

但是详细描述所有这些套接字类型和模式的含义绝对超出了本文的范围，但是您可以并且应该在ZeroMQ Guide 中阅读更多相关信息。在那里，您不仅可以了解所有套接字类型，还可以了解如何连接组件并让它们相互通信的许多不同方式。我提到的只是一个非常简单的。一旦你理解了，你就可以建立任意的层次结构。就像乐高积木;-)

希望对你有所帮助，干杯！