Как не сбрасывать сообщения в zeromq pub sub
Я видел несколько вопросов по этому поводу, но ни один из них не нашел ответов, которые я нашел удовлетворительными. Этот вопрос, шаблон zeromq: паб / саб с гарантированной доставкой в частности, похоже, хотя я открыт для использования любого другого механизма zeromq для достижения того же эффекта.
Мой вопрос: есть ли способ отправлять сообщения в виде разветвления, как подписчик издателя в ZeroMQ, с гарантией того, что сообщения будут доставлены? Кажется, что Дилер с нулевой копией мог бы сделать это хорошо, но это было бы намного более грязно, чем pub-sub. Есть ли лучший вариант? Каковы недостатки такого способа, кроме необходимости писать больше кода?
Причина, по которой это необходимо:
Я пишу код для анализа данных, поступающих от приборов. Модуль, который подключается к контрольно-измерительным приборам, должен иметь возможность передавать данные другим модулям для их анализа. Им, в свою очередь, необходимо передавать свои проанализированные данные на выходные модули.
На первый взгляд pub-sub с ZeroMQ казался идеальным для этой работы, но сообщения теряются, если какой-либо абонент замедляется и достигает максимальной отметки. В случае этой системы недопустимо отбрасывать сообщения только в части модулей из-за непрерывности событий. Все модули должны проанализировать событие, чтобы выходные данные были значимыми. Однако, если никакие модули не получили сообщения для события, это было бы хорошо. По этой причине было бы хорошо заблокировать издателя (инструментальный модуль), если один из модулей анализа достигнет максимальной отметки.
Я предполагаю, что другой альтернативой является обработка пропущенных сообщений после факта, но это просто тратит время на обработку событий, которые позже будут отброшены.
РЕДАКТИРОВАТЬ:
Думаю, подумав об этом, я ожидаю, что сообщение отправлено = сообщение доставлено, потому что я использую inproc и общаюсь между потоками. Однако, если бы я отправлял сообщения через tcp, есть вероятность, что сообщение может быть потеряно, даже если ZeroMQ не уронит его намеренно. Означает ли это, что мне, вероятно, нужно иметь дело с отброшенными сообщениями, даже если я использую блокировку отправки? Есть ли гарантии доставки сообщений с помощью inproc?
Решение
В общем, я думаю, что нет никакой возможности предоставить гарантию для pub / sub самостоятельно с 0MQ. Если вам действительно нужен полностью надежный обмен сообщениями, вам придется свернуть свой собственный.
Сети по своей природе ненадежны, поэтому TCP делает так много рукопожатий только для передачи пакетов.
Как всегда, это баланс между задержкой и пропускной способностью. Если вы готовы пожертвовать пропускной способностью, вы можете сами сделать рукопожатие — возможно, с помощью REQ / REP — и самостоятельно управлять вещанием.
В руководстве 0MQ есть некоторые идеи о том, как выполнить хотя бы часть того, что вы хотите Вот.
Другие решения
Я согласен со SteveL. Если вам действительно нужна 100% -ная надежность (или близкая к ней), ZeroMq, вероятно, не является вашим решением. Вам лучше идти с коммерческими продуктами для обмена сообщениями, где гарантированная доставка сообщений и постоянство адресов решены, в противном случае вы будете кодировать функции обеспечения надежности в ZeroMq и, скорее всего, потянете себя за дело. Вы бы внедрили свой собственный сервер приложений, если бы вам требовалось соответствие ACID между вашим приложением и базой данных? Если вы не хотите реализовывать свой собственный менеджер транзакций, вы должны купить WebLogic, WebSphere или JBoss, чтобы сделать это для вас.
Означает ли это, что мне, вероятно, нужно иметь дело с пропущенными сообщениями, даже если я
использовать блокировку отправки?
Я бы держался подальше от явного блокирования что-нибудь, это слишком хрупко Синхронный отправитель может зависнуть на неопределенный срок, если что-то пойдет не так на стороне потребления. Вы можете решить эту проблему, используя опрос и тайм-ауты, но опять же, это хрупкий и грязный код; придерживаться асинхронного.
Есть ли гарантии доставки сообщений с помощью inproc?
Ну, одна вещь гарантирована; вы не имеете дело с физическими сокетами, поэтому все сетевые проблемы устранены.