ZeroMQ：向多个工作者发布消息并等待确认。

Question

我正在开发一个应用程序，在重启即将发生时通知多个工作进程，然后等待所有工作进程执行一些任务并在重启之前发送确认消息。工作进程的数量可能会更改，因此我的应用程序需要知道当前订阅的工作进程数量，以便它知道每个工作进程都已发送确认消息。

使用发布/订阅方式是实现这一功能的最佳方法吗？它是否提供了一种确定当前连接的订阅者数量的方法？我的应用程序是否应该使用REP套接字来侦听工作进程的确认消息？是否有更优雅的设计方式？

谢谢。

- philipdotdev

Answer 1

使用发布/订阅方法从服务器广播“服务器重启”消息对于收到消息的工作人员来说是可以的，但它并非完美无缺。慢加入者综合症可能会阻止一个或多个工作者接收消息。为了解决这个问题，一旦服务器发布重启消息，应该继续发布该消息，直到所有工作者都回复ACK，但这会带来一个新问题：服务器如何跟踪所有工作者以确保它接收到所有必要的ACK？

不提供一种方法来确定当前连接了多少订阅者。暴露这些信息会破坏ZeroMq的抽象模型，该模型隐藏了连接和连接的对等方的物理细节。您可以通过发布/订阅定期向工作程序发送心跳消息；工作者响应逻辑节点ID（WorkerNode1等），服务器在哈希表中跟踪每个工作者以及未来的过期时间。当工作者响应心跳时，服务器只需重置该工作者的未来到期时间；服务器应定期检查哈希表并删除过期的工作者。

这是您跟踪工作者的最佳方法。到期时间越短，工作者列表反映得越准确。

我的应用程序是否应该使用REP套接字来侦听工作者的ACK？有没有更优雅的设计方式？

REQ/REP套接字的用途有限。我会在服务器上使用PUB来发送重启和心跳消息；ROUTER用于接收ACK。工作者应该使用DEALER来发送ACK（和其他任何内容），并使用SUB来接收心跳/重启。ROUTER和DEALER是双向且完全异步的，也是最通用的；不会错。

希望对您有所帮助！

- raffian

---

谢谢提供信息。现在，如果服务器一直发布重启消息，直到所有工作进程都回复ACK，这是否意味着工作进程可能会收到重复的重启消息，或者SUB套接字会为工作进程清除重复消息？ - philipdotdev

可以，但那不是问题。当工作单元收到重新启动消息时，它应该进入反映当前情况的状态，例如“等待重新启动”状态。工作单元完成所有未完成的工作，然后发送确认信息。如果在此期间有任何消息到达，则工作单元将检查其状态以确定是否已处于“等待重新启动”状态，如果是，则仅忽略这些重复消息。当服务器重新启动时，它应向所有工作单元广播一条消息，以便它们可以将状态重置回正常状态并继续工作。顺便说一下，SUB套接字不会丢弃重复消息。 - raffian