您将如何从多个连接中获取最新消息到单个 ZMQ 套接字？

Question

我是 ZMQ 的新手，不确定我想要的是否可行，或者我是否应该使用其他技术。

我想要一个多个服务器可以流式传输到的套接字。

看来 ZMQ 套接字可以根据此文档执行此操作： http ://api.zeromq.org/4-0:zmq-setsockopt

我将如何在接收端实现一个只获取从每个服务器发送的最新消息的 ZMQ 套接字？

Answer 1

你可以用 Zmq 的 PUB / SUB 来做到这一点。

第一个关键是一个 SUB 套接字可以连接到多个 PUBlisher。 这在指南的第 1 章中有所介绍：

关于发布-订阅（pub-sub）模式的一些要点：

• 订阅者可以连接到多个发布者，每次使用一个连接调用。 然后数据将到达并交错“公平排队”，这样就没有一个发布者会淹没其他发布者。

• 如果发布者没有连接的订阅者，那么它将简单地丢弃所有消息。

• 如果您使用的是 TCP 而订阅者速度很慢，则消息将在发布者上排队。 稍后我们将研究如何使用“高水位线”来保护发布者免受这种情况的影响。

所以，这意味着您可以在客户端上拥有一个 SUB 套接字。 这可以连接到多个 PUB 套接字，一个用于客户端需要从中流式传输消息的每个服务器。

最新讯息

可以使用高水位线部分处理“最新消息”（正如我怀疑您已经开始发现的那样）。 ZMQ_RCVHWM选项允许将接收的数字设置为 1，尽管这是一个不精确的控制。

您还必须考虑“最新”消息的含义； PUB 服务器和 SUB 客户端对此有不同的看法。 例如，当 PUB 服务器上的 zmq_send() 函数返回时，发送的消息是 PUBlisher 认为是“最新”的消息。

然而，在客户端并不知道这一点，因为还没有通过发布服务器的操作系统网络堆栈，没有任何东西接触到以太网，等等。所以订阅客户端此时对“最新”消息的看法及时是 ZMQ 的内部缓冲区/队列中等待应用程序读取的消息。 与 PUBlisher 刚刚开始发送的消息相比，这条消息可能已经很旧了。

实际上，客户端 SUBscriber 看到的“最新”消息将取决于 SUBscriber 应用程序运行的速度。

• 如果它足够快以跟上所有 PUBlisher，那么 SUBscriber 收到的每条消息都将尽可能接近“最新”消息（消息将仅与网络传播延迟和所花费的时间一样旧通过 ZMQ 的内部协议、缓冲区和队列传输）。

• 如果 SUBscriber 的速度跟不上，那么它将看到的“最新”消息至少与每条消息的处理时间乘以 PUBlisher 的数量一样旧。 如果您已将接收 HWM 设置为 1，并且订阅者没有跟上，发布者将尝试发布消息，但订阅者套接字将一直拒绝它们，直到订阅的应用程序清除了导致队列拥塞的旧消息，等待用于zmq_recv() 。

如果订阅者跟不上，订阅者最好的做法是：

• 有一个接收线程专用于接收消息并处理它们直到处理可用

• 有一个单独的处理线程来进行处理。

• 让两个线程通过 ZMQ 进行通信，通过inproc连接使用REQ / REP模式。

• 接收线程可以zmq_poll到 PUBlishing 服务器的 SUB 套接字连接和到处理线程的 REP 套接字连接。

• 如果接收线程在 REP 套接字上收到一条消息，它可以使用从 SUB 套接字读取的下一条消息进行回复。

• 如果它从 SUB 套接字收到一条没有到期 REPly 的消息，它就会处理该消息。

• 处理线程向其REQ套接字发送1字节的消息（内容无关紧要）以请求最新消息，并从PUBlisher接收最新消息作为回复。

或类似的东西。 这将使消息从 PUBlisher 流向 SUBscriber，因此 SUBscriber 总是有一条尽可能接近“最新”的消息，并尽可能地处理它，处理它无法处理的消息。