0MQ PUB/SUB子系统的设计

简介

PUB/SUB (publish/ subscrib)是一个用来给任意多个订阅者分发数据的消息传输模式。在0MQ的环境中，PUB/ SUB集中于可扩展性，即增加更多的订阅者到系统中去而不会使其过载的能力。

最小化网络流量

除了分发数据以外，PUB/ SUB子系统的另一个主要设计目的是最小化网络流量。毕竟，PUB/ SUB归结于因会使网络过载而臭名昭著的多播。因此，设计描述基于以下需求：

If there's no subscriber for a particular message in a specific portion of the distribution tree the data should not even traverse associated network segments.

虽然这个需求是不言而喻的，但是，它经常不被今天使用的消息传输系统所尊重。在大多数基于broker的系统中，订阅者使用broker订阅消息，然而，broker却没有办法去向发布者订阅消息。所以，即使没有客户对消息感兴趣，消息也会从发布者传输到broker，只是在broker处丢弃他们而已：

相反地，我们想要获得的东西是，一个系统中，假设如果一个消息没有一个人对其感兴趣，就要尽快得丢弃掉，即便在正在被往网络中发送：

我们也希望这个性质是可传递的，即，即使在发布者和订阅者之间有多个中间节点 (brokers, devices)，不需要的信息仍然应该被尽快地丢弃掉：

更一般地，我们想要消息传输只通过消息分布树的这些格子，导向消费者感兴趣的消息：

此外，它将是更好的，如果传送消息通过图的任何边仅仅一次，即使有多个客户在在树的那个分支下面。换句话说，消息复制应该发生在顺着流尽可能远的位置——这种情况下，复制发生在节点D而不是节点P。

订阅转发

为了获得这种类型的设计，订阅必须被传送给上游节点，以使上游节点可以使用它们，避免发送订阅者不感兴趣的消息到路径中。这个属性应该是可传递的，即上游节点应该转发订阅到其父节点，以此方式依次传送给当前节点的父节点

所以，当客户应用程序订阅一个话题订阅，除了应用于本地，它还要向上游跳跃，知道它到达终极的生产者。

这种模型技术上的难点在于，如何通过中间设备传递订阅信息。回想一下，一个设备只是一对由用户代码连接起来的0mq socket。因此，没有方法可以实现设备的订阅转发而没有用户代码参与到这个过程。而这正是XPUB/ XSUB socket所做的事情。

XPUB和一个PUB socket类似，除了你可以从中接收消息以外