正确的套接字类型的消息追赶机制？

Question

我有一个发布者应用程序(PUB)，它有N个订阅者(SUB)

如果重新启动这些订阅服务器，或者丢失消息，这些订阅者需要能够赶上它们。

我们已经实现了发布者写入的简单事件存储。我们实现了一个CatchupService，它可以查询事件存储并向订阅者发送丢失的消息。

我们在订阅服务器中实现了一个推送套接字，该套接字发送丢失消息的请求。订阅服务器还具有一个拉套接字，用于侦听独立端口上丢失的消息。

订户将：

1. 发现空隙
2. 向我们的CatchupService发送丢失消息的请求，请求还包含要将结果发送到的地址。
3. 追赶服务有一个拉套接字，它在其上侦听请求。
4. 当CatchupService收到请求时，它启动一个工作线程，其中：
   1. 获取丢失的消息。
   2. 打开连接到订阅者的推送套接字，拔出套接字。
   3. 向订阅服务器发送丢失的消息。

​

这看起来很好，但是我们不确定我们是否为这类应用程序使用了正确的套接字类型。这些是正确的还是应该使用不同的模式。

Answer 1

听起来不错。否则，当节点在短时间内脱机时，0MQ能够从消息丢失中恢复。看看套接字选项，特别是选项ZMQ_SNDHWM。

我不知道0MQ恢复机制是如何保证的，所以也许您最好还是保持现有的状态，但这是需要注意的。