Сообщения «Гарантированная доставка» - посоветуйте: MQTT или ZeroMQ?

Question

Нам нужно облегченное клиентское решение для обмена сообщениями.Ранее мы использовали AMQP, RabbitMQ, но в C ++ у нас есть проблемы.

Мы хотели бы выбрать ZeroMQ с malamuteserver или MQTT?Наш IoT будет публиковать данные (45 kb) почти каждые 5 минут.

Мы должны доставить это сообщение на 100% и не хотим терять какое-либо сообщение.

Мы пробовали MQTT QoS level 2, но когда сервер отключен или у клиента основного сервера возникла проблема, мы теряем опубликованные сообщения.

Нам нужна именно модель задачи / работника RabbitMQ.Сообщения должны находиться в очереди на сервере до тех пор, пока потребители не подключатся, если что-то случится.

Любые предложения, указания и примеры приветствуются.

PS: Это будет производственный процесс, поэтому мы хотим выбрать менее проблемный способ :)

Большое спасибо.

Answer 1

Я думаю, что MQTT преувеличен, уверен, что результат, я думаю, из-за доступных серверов с открытым исходным кодом.Zeromq предлагает множество функций для создания чего-то, что будет соответствовать требованиям.Чем больше я смотрю на доступные варианты, тем больше склоняюсь к zeromq.В нашем случае мы будем получать данные через произвольные интервалы с очень большого числа устройств (шлюзы в ячеистой сети или конечные узлы).Наш окончательный размер сообщения очень прост: строка с разделителями, двоичное кодирование, сжатый (<100 байт) и отправленный по сети.Я решил на zeromq на сервере, чтобы получать сообщения.Причины основаны не только на том, что Zeromq является брокером, но и на том, как мы можем использовать его функции curveZmq, чтобы упростить настройку устройств и обеспечить простую ZTP (систему подготовки Zero Touch) и управление ключами.Я в заданное время спорю об использовании шаблонов публикация / публикация и push / pull, где на каждом конечном устройстве есть издатель или пушер с прокси-подписчиком на облачном сервере.в то время как обычно паб в пабе / субабоненте меньше издателей и больше подписчиков в типичном крупномасштабном развертывании IOT, есть больше издателей и меньше подписчиков, поэтому мне интересно, стоит ли мне идти с пабом / суб, и там есть проблема потерисообщения из-за медленного присоединения подписчика - что, если мы отключим сервер для технического обслуживания, устройства на местах будут продолжать публиковать сообщения, пока не будет достигнут HWM.Полагаю, что всегда существует риск потери сообщений независимо от того, что находится вне сети - транспортная сеть не работает, а устройство подключено к HWM - это из-под контроля.</p>

У Маламута не так много документации, иначе я бы изучил его немного подробнее.

Итак, вы решили, что использовать?Если вы хотите сохранять сообщения до тех пор, пока они не будут использованы, я настоятельно рекомендую zeromq в качестве прокси-сервера с рабочими, помещающими сообщения в постоянное хранилище. Вы также можете проявить творческий подход, включив последовательность # и т. Д., И разрешив клиентам запрашивать сообщения, данныедиапазон последовательности и т. д., если они потеряны.

Answer 2

A: Мы должны доставить это сообщение на 100% и не хотим терять ни одного сообщения.
B: Сообщения должны находиться в очереди на сервере до тех пор, пока потребители не подключатся, если что-то произойдет.
C: Это будет производственный процесс, поэтому мы хотим выбрать менее проблемный способ:)

A: выполнимо
A: + B: выполнимо, сложнее, но все еще выполнимо
A: + B: + C: нет, этот набор требований действительно стоит по стоимости

D: Любые предложения, указания и примеры приветствуются.

ZeroMQ под рукой, так как легкий , вне всякого сомнения, настраиваемый / настраиваемый далеко за пределы заявленной пропускной способности ~ 45 [kb / 5 min], однако Дьявол приходит к правильному пониманию сильных сторон Дзэн-Zero , пакет, как есть, по своему замыслу стремится обеспечить НУЛЬНУЮ ГАРАНТИЮ и позволяет всем добрым пользователям создавать свои собственныеспецифичные для e (читаются как «достаточная» гарантия, которая необходима, поэтому не теряйте ни малейшей эффективности для остальных случаев использования, оу, ага).

Итак, D: затрачивает достаточное количество проектных усилий для покрытия « затрат » - из - C:, и вы достигли цели проектирования.

Так просто, Мария, Это обычная задача для любого и всех CTO, чтобы справиться с этим и решить следующие шаги.

---

Бонусная часть:

Если вам необходимо минимизировать требования к IoT-устройствам, можете пойти и сравнить их costs -of- C: с аналогичной пользовательской адаптациейдаже более легкая структура для масштабируемых архетипов формальных коммуникаций, разработанная Мартином СУСТРИКОМ и др., как младшая сестра ZeroMQ, - nanomsg , может бытьэкономия на ресурсах с низким энергопотреблением / ограниченных ресурсах, которые обычно присутствуют в массовых когортах IoT-устройств.

---

Anyway, держите нас в курсе, где ваша реализация производства оказалась, хорошо?