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

Question

所以我目前正在开发一个 node.js 游戏服务器应用程序，但我在这里遇到了一些障碍。我的问题是我使用 socket.io 来接受来自游戏客户端的入站连接。这些客户端可能连接到游戏世界的多个区域或区域之一。

基本架构如下所示。主进程为运行区域管理器进程的游戏的每个区域创建一个子进程；一个致力于维护区域数据(3d 模型、玩家/实体的位置等)的过程。主进程然后为它创建的每个区域管理器派生多个“通信线程”。这些线程创建一个 socket.io 实例并监听该区域的端口(多个线程监听单个端口)。这些线程将在自己的进程中处理大部分游戏逻辑，并与支持游戏服务器的数据库进行通信。唯一的问题是，在某些情况下，他们可能需要与区域管理器通信以接收有关区域、玩家等的信息。



例如:玩家想与区域中的非玩家角色 (NPC) 进行买卖/交易。区域通信线程需要在允许交易发生之前询问区域管理器线程玩家是否离 NPC 足够近以进行交易。

我在这里遇到的问题是我计划使用 node.js 集群功能并使用 send()和 on()处理来回传递消息的进程的方法。除了我遇到的一个警告外，那会很好。由于所有子进程都以 cluster.fork() 分拆只能与“主”进程通信。 node.js 根进程成为所有通信的瓶颈。我使用一个脚本在我的系统上运行了一些基准测试，该脚本实际上只是使用集群的进程间通信 (IPC) 来回退回消息，并跟踪每秒执行的中继数。就其可以中继的 IPC 数量而言，似乎最终 Node 的上限约为每秒 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 的讨论并不多。我希望这里的某个人以前曾为 IPC 使用过 0MQ(甚至可能在 node.js 中？)，并且可以为我阐明这个选项。

dnode :
我再一次从未使用过它，但从我所看到的情况来看，它似乎是另一种旨在通过 TCP 工作的选项，这意味着网络堆栈再次成为障碍。

node-udpcomm :
有人将此链接到此处的另一个问题中(不幸的是，我似乎无法再次找到)。我什至从未听说过它，它看起来像一个非常小的解决方案，可以打开并监听 UDP 连接。虽然这可能仍然比 TCP 选项更快，但我们仍然有网络堆栈，对吗？我绝对像这里一样离我的“程序员区”大约一英里，并且深入到我不太了解的网络/计算机架构领域，哈哈

无论如何，底线是我完全被困在这里，不知道在这种情况下 IPC 的最佳选择是什么。我目前假设 0MQ 是我上面列出的最佳选择，因为它是唯一一个似乎为通信协议(protocol)提供“IPC”选项的选项，我认为这意味着它使用的是 UNIX 套接字或其他不通过网络堆栈，但我无法确认或任何事情。

我想我只是希望这里的一些人可能知道足够的知识来为我指明正确的方向，或者告诉我我已经到了那里。我正在从事的项目是一个多人游戏服务器，旨在与多人游戏客户端一起“开箱即用”，同时使用 Three.js 为其 3D 图形/计算提供支持。一旦我让他们都满意地工作，客户端和服务器将向所有人开放源代码，我想确保架构尽可能具有可扩展性，因此人们不会在此基础上构建游戏然后进行扩展并最终撞到墙上。

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

Answer 1

我认为 0MQ 将是一个非常好的选择，但我承认我不了解其他 :D

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

"inproc://<id>" - 通过内存在线程之间进行进程内通信端点

"ipc://<filepath>" - 依赖于系统的进程间通信端点

"tcp://<ip-address>" - 清除

"pgm://..."或 "epgm://..." - 实用可靠组播的端点

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

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

管理器:REP 套接字，线程:REQ 套接字；或

经理:ROUTER，线程:REQ 或 DEALER

然后线程将它们的套接字连接到分配给它们的单个 Manager 套接字，就这样，它们可以开始发送请求并等待响应。他们必须决定的只是他们用作端点的路径。

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

希望对大家有所帮助，加油!