Как получить количество сообщений / событий в ZMQ Publisher / Subscriber QUEUE

Question

Мы реализовали механизм ZMQ PUB / SUB для передачи сообщений между распределенными процессами. Но из-за времени обработки подписчиком сообщения обрабатываются с некоторой задержкой (иногда задержка в часах из-за количества сообщений в очереди). Чтобы преодолеть эту задержку, я планирую увеличивать / уменьшать процессы подписчиков в зависимости от количества ожидающих сообщений в очереди издателя.

Существует ли какой-либо механизм для подсчета / длины издателя ZMQ Очередь?

В настоящее время я рассматриваю порог использования памяти Publisher-server для масштабирования UP / DOWN процессов подписчика.

Answer 1

Q : Как получить количество сообщений / событий в ZMQ Publisher / Subscriber Queue?

PUB -side имеет две опции:
1) простой подсчет всех .send() -коллов позволяет избежать «ошибки мусора» в дизайне вашей программы
2) , если не использовать явный подсчет, может решить сортировку "мусора", используя инструмент socket_monitor (за ваш счет это будет стоить)

SUB -side является пассивным получателем сообщений, поэтому у него есть только одна опция:
- создать свой собственный, определяемый приложением c детектор, используя инструмент socket_monitor (анализируя все позади События API, нет другого способа обмануть за кулисами опубликованную абстракцию API)

Q : Существует ли какой-либо механизм для получения количества / длины ZMQ Очередь издателя?

(ref.above) + зависит от того, где стоит «механизм» наблюдателя:

Добавление другого, независимо работающего Сигнальная контрольная плоскость помогла бы скрестить эти принципы, чтобы расширить все соответствующие контрольные данные с обеих сторон, чтобы получить полную картину трафика в очереди c.