ZMQ 如何在 2 台不同的机器之间工作

How ZMQ works between 2 different machines

我不确定我是否从根本上理解 ZMQ(或任何消息队列)如何知道如何在两个服务器之间进行通信,否则这两个服务器彼此之间一无所知。

例如,使用 request/reply 模式:

请求者将像这样绑定到主机和端口:

var requester = zmq.socket("req");
 requester.bind('tcp://*:5555'), function (err) {
            callback(err);
        });

在另一台服务器上的另一个 node.js 进程中,我使用连接函数:

 var replier = zmq.socket('rep');
    replier.connect('tcp://127.0.0.1:5555', function (err) {
       callback(err);
    });

但我不明白的是,如果回复者在几乎任何地方的完全不同的服务器上的不同进程中,请求者如何知道将消息发送到哪里?

我想你对哪个是请求者哪个是回复者感到困惑。或者更恰当地说,哪个是客户端,哪个是服务器。

The Server 是又名 socket.bind('tcp://*:5555') 的绑定。这没有什么神奇的。该星号并不意味着多播或发现某些网络上的服务器。这意味着绑定又名侦听机器的所有网络设备。

The client 可能是你的名字错误 reply.connect('tcp://127.0.0.1:5555 ....

客户端知道服务器在哪里,就像在 HTTP 中一样。 (提示它在同一台机器上 :))。

ZeroMQ 非常简单。它甚至不是真正的消息队列。它没有自动发现或中央代理,因此您必须自己记录服务器和客户端(例如 Major Domo 模式)。

您已经在评论中找出一个问题 - connect() 是同步的,而您试图异步使用它。

我建议,在 node.js 中,您 bind()connect() 同步,您从 运行 这种一次性启动操作中得不到什么好处异步地,它只是让代码更清晰地同步地完成它。如果你在中间过程中建立和拆除套接字,而且你确实有充分的理由这样做,那么你可以忽略这个建议,但是节点给了你很好的理由只做一次并在整个生命周期中使用相同的套接字过程。

至于两个不同的服务器如何找到对方,你的例子会失败:

// this tells the socket to listen to all incoming connections on post 5555
// but it does not create a connection to any other machine or process
requester.bindSync('tcp://*:5555');

...在另一台机器上...

// this tells the socket to connect to a bound socket on the same machine
// it will not find a socket on another machine
replier.connect('tcp://127.0.0.1:5555');

因此,您必须反转 bind()connect(),然后更改您的 requester,如下所示:

// change 111.222.33.44 to the IP address or DNS name of your other machine
requester.connect('tcp://111.222.33.44:5555');

...在另一台机器上...

replier.bindSync('tcp://*:5555');

...或者,更改您的 connect() 调用以指定第一台机器的 IP 地址,而不是环回地址。

以下是您应该 connect()bind() 的评估,因为我觉得其他建议不完整。

bind()connect() 站在哪一边并不重要,只要你 bind() 站在 持久 一边(你的 "server") 和 transient 一侧的 connect()(你的 "client")。如果它们同样持久,那么下一个选择的方法是 bind() 在 "owns" 数据的一侧,服务器的方式 connect() 在 [=72] 的一侧=] 数据,客户的方式。

这就是为什么传统上,您将 bind() REP 套接字和 connect() REQ 套接字,因为 REQ 套接字 "wants" 它请求的数据,REP 套接字 "owns" 它发送回的数据。同样,您将 bind() 一个 PUB 套接字,因为它 "owns" 它正在发布的数据,并且您将 connect() 一个 SUB 套接字,因为它 "wants"它订阅的数据。

这只是一个经验法则,SUB 套接字完全有可能比它的伙伴 PUB 套接字更持久,或者 REQ 套接字 "own" 它发送到 REP 套接字的数据。在许多情况下,您无论如何都可以选择任何一方,而后果为零,但这些是要遵循的有用规则,可以让您清楚地了解正在发生的事情。