如果仅使用socket.send（）一次，则zmq订户无法订阅发布的消息
如果socket.send()在发布程序中仅使用一次 ，则zmq订阅服务器无法订阅该消息。
订阅者能够在发布者使用以下代码时订阅邮件：
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)]);
那么，先生，不完全是。
从历史上看，
ZeroMQ使用了SUB -side订阅（主题过滤）。 这意味着两件事情。 PUB publisher对于谁主pipe什么和花费主题filter处理的零花费没有任何知识。 此外，它倾倒并且必须这样做，所有的消息传送到路上的所有不同的传输级别的信道上，朝向（仅在那里的话题过滤）子用户（主要在传输层资源上产生一定程度的低效） ）。
所以，如果你的代码使用“旧”的ZeroMQ包装器/语言绑定，你的“PUB-lisher”不是问题的根本原因，因为它的devise不关心任何问题，包括“认购人“，交易对手。 时间延迟帮助（不是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没有任何关系，但是如果devise强大的应用程序体系结构，devise人员必须牢记计时巧合。
下一个，
最新的ZeroMQ版本已经切换到PUB side过滤。 这似乎是一个重大的变化，但是它对你的例子没有什么重大的影响。
PUB side过滤刚刚通过PUB的集中式主题过滤来消除传输层拥塞，代价是现在所驻留的总成本（so-far-cheap-'cause-distributed）-workloads，集中在PUB 。
所以，你的观察仍然显示没有收到任何消息，为什么要进入这样的细节？ 好吧，现在，在新版本的情况下，如果SUB没有设法“告知”并将它传递给PUB side的SUB Scription偏好，那么在此之前已经派发了PUB.send( aFirstMESSAGE_to_Those_whom_I_know_they_SUBed_to_this_TOPICFILTER )由于分布式系统事件的传播和传递的时间重合 ，而不是由于PUB-侧（唯一）代码调整 ，所以再也不是音乐了。
结语：
在这两种情况下，ZeroMQ都是一个无代理的消息传递框架。 这意味着，消息的持续性甚至无意创造，也没有提供。 每个可伸缩的正式通信模式的行为原型节点都已经在API文档，缓冲区pipe理和消息保留中明确指出。 抛弃}等规则。 一定要检查ZeroMQ低层协议的不同版本，这些协议在分布式系统领域的所有节点上都使用（通常不能控制），但可能devise版本感知的行为策略强制来处理这种生产环境不确定性）。
该
最好
下一个
步：
如果人们努力在分布式系统的专业devise领域保持一段时间，那么最好的办法就是从ZeroMQ的父亲之一Pieter HINTJENS（ 可以查看ZeroMQ上的其他post并按照直接链接到本书的PDF版本 ）。
这是“慢速木匠”问题的结果。
以下是指南中的一段话：
还有一件重要的事情要了解PUB-SUBsockets：你不知道用户何时开始获取消息。 即使您启动订阅者，稍等片刻，然后启动发布者，订阅者将始终错过发布者发送的第一条消息。 这是因为当订阅者连接到发布者（需要很less但非零的时间）时，发布者可能已经在发送消息。
基本上，当发布者运行时，它与订阅者握手。 由于这是asynchronous的，发布者可以在握手完成之前完成发送消息。 在这种情况下，用户将错过这些消息。 为了让订阅者获得第一条消息，发布者需要等待发送，直到确认订阅者已经连接。
这是一个进一步的报价：
在第2章 – 套接字和模式中，我们将解释如何同步发布者和订阅者，以便在订阅者真正连接并准备就绪之前，不会开始发布数据。
它显示了如何使用REQ-REP来使用另一个套接字对，以便在用户准备好在子套接字套接字处接收信号时发出信号。