我们实现了ZMQ PUB / SUB机制，用于在分布式进程之间进行消息传输。但是由于订户的处理时间，消息的处理会有所延迟（有时由于排队的消息数，延迟以小时为单位）。为了克服此延迟，我计划根据发布者队列中待处理消息的数量来扩大/缩小订阅者进程。
是否有任何机制来获取ZMQ发布者队列的计数/长度？
当前，我正在考虑Publisher-server RAM利用率阈值来扩大/缩小Subscriber进程。
Q：如何在ZMQ发布者/订阅者队列中获取消息/事件计数？
PUB侧有两个选择：1]所有.send()-调用的简单计数避免了程序设计中的“小虫”2]如果不使用显式计数，则可以使用socket_monitor工具解决“垃圾”整理问题（这样做需要您额外付费）
SUB端是消息的被动接收者，因此它只有一个选择：-使用socket_monitor工具创建自己的特定于应用程序的检测器（分析所有API背后事件，没有其他方法可以掩盖已发布API抽象的幕后花絮）
Q：是否有任何机制可以获取ZMQ发布者队列的计数/长度？
（ref.above）+取决于观察者“机制”所在的位置：
添加另一个独立工作的信令控制平面将有助于杂交这些原理，以便从双方增加所有相关的控制数据，从而获得排队流量的全貌。