ZeroMQ指南-第1章-基础-放出消息(二)
端点并接收和计数消息
发布者绑定到一个端点并立刻发送1000条消息
那么订阅者很可能不会接收到任何东西。你可以眨眨眼，检查一下是否设置了正确的过滤器，再试试，然而订阅者还是不会接收任何东西。
建立TCP连接牵涉到大概几毫秒的来回握手，这取决于网络状况和节点之间跳跃的次数。这个时间里， MQ已经可以发送好多消息了。为了证明，假设花费5毫秒来建立连接，而相同的链路可以搞定1M每秒的消息。在订阅者连接到发布者的5毫秒里，发布者仅耗费1毫秒就将这1K的消息发送出去了。
在第2章 - 套接字与模式中我们会解释如何让发布者和订阅者同步，以便无需等待订阅者（们）都已连接并就绪时才开始发布数据。有一个简单的笨办法来延迟发布者，通过睡眠sleep。但是在真实程序中可不要这么做，因为这极为脆弱、不雅而缓慢。先用sleep向自己证明到底发生了什么，然后等到第2章再看正确做法。
同步的另一种替代方案是简单的假设发布的数据流是无限的，没有开始也没有结束。还假设订阅者不在乎它启动之前发生过什么。这就是我们建造的例子天气客户端的方式。
客户端订阅到选定的地区编码并收集1000个更新。也就是大概1000万服务器更新，如果地区编码是随机分发的。你可以先启动客户端，再启动服务器，而客户端会持续工作。你可以随时停止并重启服务器，而客户端会持续工作。当客户端收集到了1000个更新，它计算出平均值，打印输出，然后退出。
关于发布订阅模式的一些要点：
订阅者可以每次调用“connect”来连接到一个以上的发布者。数据会交错到达（“公平队列”）以避免发布者相互淹没。
如果一个发布者没有已连接的订阅者，那么它直接丢弃所有消息。
如果你使用TCP时一个订阅者很慢，消息会在发布者那里排上队。我们待会看看这种情况下如何用“高水位线”来保护发布者。
从 MQ 3.x开始，使用已连接协议（tcp: 或 ipc:)将在发布者方面进行过滤，使用epgm://协议时，会在订阅者一方进行过滤。在 MQ2.x中所有过滤都在订阅者方面进行。
如下是在我的笔记本电脑中接收过滤10M消息花费的时间，电脑配置是2011-era Intel i5，体面但也没啥特殊的。
[plain]
$ time wuclient
Collecting updates from weather server...
Average temperature for zipcode '10001 ' was 28F
real 0m4.470s
user 0m0.000s
sys 0m0.008s