ZeroMQ XPub/XSub模式

ZeroMQ XPub/XSub模式

---

Motivation

相对于XPub/XSub模式，我们很容易想到Pub/Sub模式，即订阅发布模式。当我们使用ZeroMQ创建一个包含订阅发布模式的系统时，我们通常创建一个消息的发布者，即Publisher，和若干个消息订阅者(Subscriber)。消息的发布者绑定端口，订阅者通过发布者的IP和端口连接发布者，并且注册消息主题(Topic)，然后进行接收匹配主题的消息。整体结构如下图：

在订阅发布模式下，订阅者可以动态加入，随时连接消息的发布者，然后接收消息。但是，在这种结构中，如果有新的Publisher加入，那么所有订阅者都需要连接到这个Publisher上。如果系统中有成百上千的订阅者，每一个新的Publisher的加入都会给系统造成很大的操作成本，这显然限制了系统规模。要解决这个问题，也很简单，就像只有一个发布者情况，所有的订阅者都只与这一个消息发布者交互，不管是Publisher内部发生什么变化，Subscriber都可以动态感知这种变化。所以很容易我们可以想到创建一个中间件来解耦Publishers和Subscribers，所有Subscriber都只与这一个中间件交互，换句话说，这个中间件从很多个Publisher那里接收消息，然后转发给Subscibers。事实上，有了这个中间件，我们可以做很多Pub/Sub模式做不了的事情，比如说对传送过程中的消息进行管理，重构，或者对系统进行负载均衡等等。我们把这个中间件称为Broker，上面说的这种模式，我们称之为XPub/XSub模式。

XPub/XSub

在XPub/XSub模式中，对Publisher来说由Pub/Sub模式中的bind操作变成了connect操作，connect的对象为Broker中的XSub端口。对Subscriber而言，和Publisher的操作一样，只不过connect的是Broker的XPub端口。在Broker中我们绑定XSub和XPub这两个端口。Proxy的作用即为中转消息，在ZMQ的API中提供了zmq.proxy方法来中转消息，其实Proxy就是一个代码块，在这个代码块中可以做任何我们想做的操作。后面会介绍一个简单的例子。从XPub/XSub这个模式中，我们可以发现，不管是Publisher还是Subscriber，它们的加入和离开都可以被系统动态发现。

XPub/XSub例子

在这个例子中，我们让Publisher从CSV文件中读取数据，在Broker中维护一个buffer，如果有Subscriber加入，我们首先发送缓冲区的历史消息，然后转发新消息给Subscribers。

封装ZMQ API

# -*- coding: utf-8 -*-
# utl.py
import zmq

def get_publisher(address, port):
    context = zmq.Context()
    socket = context.socket(zmq.PUB)
    connect_addr = 'tcp://%s:%s' % (address, port)
    socket.connect(connect_addr)
    return socket

def get_subscriber(address, port, topics):
	# Subscriber can register one more topics once
    context = zmq.Context()
    socket = context.socket(zmq.SUB)
    connect_addr = 'tcp://%s:%s' % (address, port)
    socket.connect(connect_addr)
    if isinstance(topics, str):
        socket.subscribe(topics)
    elif isinstance(topics, list):
        [socket.subscribe(topic) for topic in topics]
    return socket

def get_broker(xsub_port, xpub_port):
    context = zmq.Context()