Как я могу ограничить общее количество одновременных подключений подписчиков к конечной точке издателя ZeroMQ?
При создании службы pub-sub с использованием ZeroMQ в системе Linux, существует ли какой-либо способ принудительного ограничения одновременных абонентов?
Например, я мог бы захотеть создать службу издателя ZeroMQ в системе с ограниченными ресурсами и предотвратить перегрузку системы, установив ограничение, скажем, в 100 одновременных подключений к конечной точке издателя tcp. После достижения этого предела все последующие попытки подключения от подписчиков ZeroMQ будут неудачными.
Я понимаю, что ZeroMQ не предоставляет уведомления о подключении / отключении, но я искал варианты сокетов, которые могли бы разрешить такие ограничения - пока что, не повезло.
Или это то, что должно быть обработано на каком-то другом уровне, возможно, в рамках протокола?
2 ответа
Да, ZeroMQ - это система обмена сообщениями Can-Do:
Помимо тривиальных элементов Formal Communication Pattern Framework (примитивы библиотеки), сильнейшие возможности ZeroMQ - это способность разрабатывать собственные системы обмена сообщениями.
В вашем случае достаточно обогатить сцену несколькими дополнительными вещами... SUB -процесс -> PUB -процесс -канал потока сообщений, чтобы PUB процесс подсчета количества SUB экземпляры -процесса одновременно подключены и позволяют разъединить (шаг, скорее делегированный "назад" SUB -процессный ход самоубийства, как классический PUB -процесс намеренно не имеет инструментария для управления подписками), как только лимит будет достигнут динамически. Плюс добавьте немного динамики для межузловой сигнализации, чтобы начать пересчет и / или оборудовать SUB сторона (и) процесса с механизмом саморекламы для push-keepAliveSIG-s на PUB и ожидаем, что эта сигнализация будет слабой и информативной только для индикации, поскольку существует много реальных коллизий, когда децентрализованный узел просто не может доставить сообщение (я) с гарантированной доставкой и хорошо спроектированную, распределенную, низко Высокопроизводительная система с задержкой должна хорошо справляться с этой реальностью и иметь политики самовосстановления для восстановления состояния, разработанные и встроенные в собственное поведение.
(Рис. Любезно предоставлено imatix/ZeroMQ)
Пожалуйста, примите во внимание, что библиотека ZeroMQ является довольно мощным набором инструментов LEGO для проектирования классных распределенных систем, а не готовым жестким квазирешимым квазирешимым решением для аккумуляторов, включающим в себя батареи (ну, это можно считать таковым, но просто для какой-то легкомысленной жизни, в то время как наша жизнь намного более красочная и дразнящая, не так ли?)
Итак, "Как?"
Стоит потратить несколько дней, чтобы прочитать обе книги Питера Хинтдженса, и несколько недель, чтобы заставить себя начать проектировать с полными полномочиями ZeroMQ на своей стороне.
С помощью всего лишь нескольких дополнений Python (zmq.Context() ранняя настройка, и не забывая finally:aContext.term())
Вам обязательно понравится этот умный мир.
Я не знаю, как настроить ZMQ для автоматического ограничения соединений... однако у вас есть другие варианты для достижения того, что вы ищете. Возможно, "традиционный" способ сделать это - второй набор "сетевых коммуникаций"... возможно REQ/REP от подписчика к издателю, запрашивая разрешение на подключение.
У вас также есть возможность, в зависимости от вашей версии ZMQ (и я никогда не использовал ее, и я не могу найти ее в течение 5 минут поиска, поэтому я не знаю, какой должна быть ваша последняя версия), чтобы использовать XPUB/XSUB розетки, которые могут выполнять двунаправленную связь. Вы можете подключиться к XSUB, отправить запрос на подписку, затем получить положительный или отрицательный ответ (возможно, вам придется поиграть с темами ваших подписчиков, чтобы напрямую общаться только с одним подписчиком, я не уверен), и реагировать соответствующим образом.
В любом случае, вы будете разрешать какое-то соединение между двумя системами, а затем либо разрешать, либо прерывать его в зависимости от ситуации. Это может быть не совсем идеально, так как вам придется немного сэкономить на обработке соединений, от которых вы будете отказываться... допустим, вы наберете 100 клиентов и вдруг получите 100 новых запросов на подписку... Вы можете или не можете справиться с таким интенсивным трафиком.
Вы можете проверить издержки в альтернативных коммуникационных средах... как вы могли бы опубликовать веб-сервис, который указывает статус подписчика, который клиент может проверить первым, но, возможно, не лучше, чтобы клиенты подключались таким образом.
Если вы абсолютно ограничены в своих ресурсах, вам придется настроить второй сервер для обработки статуса подписчика:
- Сервер 1 - ваш издатель. Вы можете настроить его с
PUBрозетка иREPразъем. - Сервер 2 - это ваш сервер состояний. Оно имеет
REQразъем. Пусть он подпишется на что-то вроде "системный статус" или что-то в этом роде. Он также будет иметь ваш механизм для общения с новыми подписчиками, будь то сокет ZMQ или веб-сервис или что-то еще. - Клиент запросит статус у вашего сервера состояния. Сервер состояния отправит запрос вашему издателю, который увеличит количество подписчиков и успешно ответит, или сохранит количество подписчиков и ответит с ошибкой. Об этом успехе или неудаче будет сообщено обратно подписчику, который будет использовать эту информацию для подключения или нет.
- О разъединениях нужно будет сообщать аналогичным образом... и вам придется использовать своего рода сердцебиение, чтобы убедиться, что клиенты не являются жертвами катастрофического сбоя.
Это позволит вашему издателю сделать разумный выбор, есть ли у него ресурсы или нет. Если вы просто хотите установить статический номер, вам даже не нужно соединение между сервером состояния и издателем, вы можете просто вести учет на сервере состояния... но просто для обеспечения общего состояния сети, тогда это вероятно, лучше не идти этим упрощенным путем.
Во всяком случае, это всего лишь некоторые идеи для достижения того, что вы ищете. ZMQ предоставляет вам варианты для создания ваших решений в большей степени, чем реальные решения.