Как избежать отбрасывания сообщений zeromq pub sub

Question

Я видел несколько вопросов об этом, но у меня нет ответов. Я нашел удовлетворительным. Этот вопрос, в частности, относится к zeromq pattern: pub/sub with guaranteed delivery, хотя я открыт для использования любого другого механизма zeromq для достижения такого же эффекта.

Мой вопрос в том, есть ли способ отправить сообщения в шаблон для фанатов, например, подписчик издателя в ZeroMQ с уверенностью, что сообщения будут доставлены? Кажется, что Дилер с нулевым копированием мог бы сделать это хорошо, но это было бы намного грязнее, чем pub-sub. Есть ли лучший вариант? Каковы же недостатки в этом, помимо необходимости писать больше кода?

Причина необходимости этого:

Я пишу код для анализа данных, поступающих от измерительных приборов. Модуль, который подключается к инструменту, должен иметь возможность передавать данные другим модулям для их анализа. Они, в свою очередь, должны передавать свои проанализированные данные в модули вывода.

На первый взгляд pub-sub с ZeroMQ казался идеальным для работы, но сообщения отбрасываются, если какой-либо абонент замедляется и попадает на знак высокой воды. В случае этой системы неприемлемо, чтобы сообщения были отброшены только на часть модулей из-за непрерывности событий. Все модули должны анализировать событие, чтобы результат был значимым. Однако, если никакие модули не получили сообщения для события, это было бы хорошо. По этой причине было бы хорошо заблокировать издателя (инструментальный модуль), если один из модулей анализа попадет в знак высокой воды.

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

EDIT: Наверное, думая об этом дальше, я ожидаю, что сообщение отправлено = сообщение доставлено, потому что я использую inproc и общаюсь между потоками. Тем не менее, если бы я отправлял сообщения по tcp, есть вероятность, что сообщение может быть потеряно, даже если ZeroMQ не будет его специально отбрасывать. Означает ли это, что мне, вероятно, нужно иметь дело с отброшенными сообщениями, даже если я использую блокировку отправки? Существуют ли какие-либо гарантии доставки сообщений с помощью inproc?

Answer 1

В целом, я думаю, что нет возможности предоставить паб/югу гарантию на 0MQ. Если вам действительно нужна полная надежность обмена сообщениями, вам придется сворачивать самостоятельно.

Сети по своей сути ненадежны, поэтому TCP делает так много рукопожатия только для того, чтобы получить пакеты.

Как всегда, это баланс между задержкой и пропускной способностью. Если вы готовы пожертвовать пропускной способностью, вы можете сами наладить связь с сообщениями - возможно, используя REQ/REP - и обрабатывать трансляцию самостоятельно.

Руководство 0MQ содержит некоторые идеи о том, как пройти хотя бы часть того, что вы хотите here.

Answer 2

Я согласен с SteveL. Если вам действительно нужна надежность на 100% (или близко к ней), ZeroMq, вероятно, не является вашим решением. Вам лучше идти с коммерческими сообщениями, в которых гарантируется доставка сообщений и постоянство, в противном случае вы будете использовать функции надежности кодирования в ZeroMq и, вероятно, вытащите свои волосы в процессе. Внедрите ли вы свой собственный сервер приложений, если вам требуется соответствие ACID между вашим приложением и базой данных? Если вы не хотите реализовать свой собственный менеджер транзакций, вы купите WebLogic, WebSphere или JBoss, чтобы сделать это за вас.

Означает ли это, что мне, вероятно, нужно иметь дело с отброшенными сообщениями, даже если я использовать блокировку отправки?

Я бы держаться подальше от явно блокирует ничего, это слишком хрупкими. Синхронный отправитель может вешать бесконечно, если что-то пойдет не так на стороне потребления. Вы можете обратиться к этому, используя опрос и тайм-ауты, но опять же, это хрупкий и грязный код; придерживаться асинхронного.

Есть ли гарантий относительно доставки сообщений с помощью inproc?

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