Как избежать сбоя маршрутизатора ZeroMQ со стороны многих подключенных ДИЛЕРОВ?

#zeromq #distributed-computing #low-latency

#zeromq #распределенные вычисления #низкая задержка

Вопрос:

У меня есть ROUTER сокет в приложении, к которому подключаются несколько DEALER сокетов в разных приложениях. Я бы хотел ROUTER , чтобы он был как можно более надежным.

Вот конкретный сценарий, с которым я хотел бы хорошо справиться на ROUTER :

  1. 1000 DEALER подключений подключаются к ROUTER
  2. Каждый DEALER отправляет запрос на ROUTER than, что приведет к ROUTER отправке большого ответа обратно на DEALER
  3. Вместо того, чтобы читать ответ, DEALER -ы немедленно повторяют второй шаг

Поведение, которое я вижу на ROUTER : он создает тонну очень больших сообщений ZeroMQ для ответов, затем zmq отправляет обратно DEALER . ZeroMQ становится ответственным за освобождение сообщений при их фактической отправке. Поскольку DEALER -s никогда не вызываются recv() , ZeroMQ хранит сообщение вечно, и память медленно «утекает», пока O / S не завершит процесс, когда у него закончится память.

Некоторые опции, которые я использовал, помогают :

ZMQ_SNDHWM : ограничивает нас только хранением N-сообщений в нашей исходящей очереди для каждого DEALER , хотя и не идеально, потому что a ROUTER отбрасывает исходящие сообщения, когда очередь заполнена

ZMQ_SNDTIMEO : ZeroMQ отбросит сообщение через N миллисекунд без успешной отправки

При указанных параметрах все еще возможно сбой ROUTER , если открыты 1000 DEALER подключений, поскольку для каждого клиента применяется максимальная отметка.

Есть ли какие-либо другие варианты, которые я мог бы использовать для защиты от сбоев клиентских запросов?

Ответ №1:

Вопрос: «Есть ли какие-либо другие варианты, которые я мог бы использовать для защиты от сбоев в клиентских запросах?»

Хотя настройка выходит за рамки моего воображения, зачем перемещать миллиарды байтов, чтобы никогда .recv() их не использовать, позвольте мне предложить вам один трюк, чтобы уменьшить выделение памяти до рабочего минимума :

Мы можем использовать .setsockopt( zmq.CONFLATE ) трюк (используя диалект Python), чтобы не буферизировать что-либо еще, кроме одного, самого последнего входящего сообщения.