如果socket.send()仅使用一次,则zmq订阅者无法订阅已发布的消息

时间:2016-12-02 13:04:34

标签: node.js zeromq publish-subscribe

如果zmq在发布商中仅使用 ,则socket.send()订阅者无法订阅该邮件。

订阅者能够在发布者使用以下代码时订阅消息:

var zmq = require('zmq')
  , sock = zmq.socket('pub')

sock.bindSync('tcp://127.0.0.1:3000');
var message = {"test" : true};
setInterval(function(){
    sock.send(['notify_anomaly', JSON.stringify(message)]);
},1000);

但如果在发布商代码中删除setInterval,则无效,如下所示:

var zmq = require('zmq')
  , sock = zmq.socket('pub')

sock.bindSync('tcp://127.0.0.1:3000');
var message = {"test" : true};
sock.send(['notify_anomaly', JSON.stringify(message)]);

2 个答案:

答案 0 :(得分:2)

这是"慢木匠"问题

以下是guide

的引用
  

有一个关于PUB-SUB插座的重要事项:你   不知道用户何时开始收到消息。甚至   如果您启动订阅者,请等待一段时间,然后启动发布者,   订阅者将始终错过发布者的第一条消息   发送。这是因为订阅者连接到发布者   (出版商可能需要很小但非零的时间)   已经发送消息了。

基本上,当发布者运行时,它与订阅者握手。由于这是异步的,因此发布者可以在握手完成之前完成发送消息。在这种情况下,订户将错过消息。为了让订阅者获得第一条消息,发布者需要等待发送,直到确定订户已连接为止。

这是另一个引用:

  

在第2章 - 套接字和模式中,我们将解释如何同步a   发布商和订阅者,以便您不会开始发布数据   直到订阅者真正连接并准备就绪。

它显示了如何使用REQ-REP来使用另一个套接字对,以便在订户准备好接收到子网套接字here时发出信号。

答案 1 :(得分:1)

嗯,不完全是,先生。

从历史上看,
ZeroMQ使用 SUB - 边订阅(主题过滤)。这意味着两件事。 PUB - 发布者不了解谁SUB对什么&在主题过滤处理上花费零努力。此外,它倾注并且必须这样做,所有消息都传递到所有不同的传输级通道上,朝向(仅限于主题过滤)SUB - 划线员(主要是在一定程度上造成某种程度的低效率)传输层资源)。

因此,如果您的代码使用“旧的”ZeroMQ包装器/语言绑定,那么您的“PUB-lisher”不是问题的根本原因,因为它的设计并不关心任何问题,包括“后期订户”,交易对手。延时有助于(不是 PUB.send() ,而是

// unknown SUB code, a default SUB-state is TOPIC-FILTER throws everything, YES !
//                                                       THROWS EVERYTHING AWAY
SUB.setsockopt( zmq.SUBSCRIBE,
                "<some_TOPIC_FILTER_string_to_be_used_after_this_happens_in_time"
                );

所以这与 PUB 方面的代码无关,QED,但设计师必须考虑时间巧合,如果设计强大的应用程序 - 架构。

接下来:较新的ZeroMQ版本已切换为 PUB - 侧过滤。这似乎是一个重大变化,但它对你的例子没有任何重大影响。

PUB -side过滤刚刚通过PUB方面的集中主题过滤删除了传输层拥塞,但代价是总和(如此 - 便宜 - '因为 - 分布式' - 工作量,现在集中在PUB侧。

因此,您的观察结果仍显示未在SUB方面收到任何消息,那么为什么要详细说明呢?那么,现在,对于较新版本,如果SUB没有设法“告诉&amp;传递”它的SUB - 对的编程偏好PUB - 在此之前,已经发送了PUB.send( aFirstMESSAGE_to_Those_whom_I_know_they_SUBed_to_this_TOPICFILTER ) 由于分布式系统事件传播的“强>时间重合”,所以再也没有音乐了。及时投放,不是由PUB - 侧(仅)代码调整

尾声:

在任何一种情况下,ZeroMQ都是一个无代理消息传递框架。这意味着,消息的持久性甚至不打算创建,也不提供。每个可扩展正式通信模式的行为原型节点都已在API文档,缓冲区管理和消息中明确指定 - {retain |丢弃}和其他规则。一定要检查不同版本的ZeroMQ低级协议,它正在分布式系统领域的所有节点上使用(通常无法控制,但可能会设计版本感知的行为策略强制来处理这种生产生态系统不确定性)。


最佳
下一页
步骤:

  

如果一个人努力在分布式系统的专业设计领域保持一段时间,那么最好的办法就是从ZeroMQ的一位父亲Pieter HINTJENS(may check other post on ZeroMQ and follow the direct link to the book's PDF-version)那里阅读这本神话般的书。