> 0mq в принципе не может того, что может Кафка. Я

уже час пытаюсь от тебя это выяснить, что??? Что такого может Кафка?

Нет сохранения сообщений (если упадет - все пропадет) Сообщение может быть недоставлено Нет кодирования сообщений Нет брокера

Уууу….

Опять мимо…. что может Kafka, чего не может сделать 0mq быстрее?

Ты делаешь вид, что не заметил моего ответа, я понял Ну и ладно

Значит ты не умеешь им пользоваться?

Не заметил. Повторю вопрос? Что может такого Kafka чего не может zeromq?

Очевидно не получу ответа, к сожалению((

Персистентность

Опять мимо…. что может Kafka, чего не может сделать 0mq быстрее?

Так как это всё ещё забавно, могу попробовать по одному пункту вкидывать Exactly once

Покажи пример быстрой персистентности на 0mq

я хуйней страдаю, присоединяйся на любой пункт просто отвечаешь "Опять мимо…. что может Kafka, чего не может сделать 0mq быстрее?"

Давай, я задал один вопрос. Интересно откуда ты какие-то пункты нашел

Exactly once - опровержение будет? 0mq умеет в него?

я знаю какой будет ответ можно я, можно я🙋

Все mq это тупой брокер. Одно сообщение - один клиент. Если хочется сделать что-то сложнее (fan-out, группы) то начинаются мучения

Ты наверное сути этих инструментов не понимаешь. В своей сути, это канал связи. Фундаментально инструменты тут делятся на две группы. 1 группа, даёт в своей сути готовый "протокол". 2 группа даёт инструмент для реализации вещей, где "протокол" не даёт тех свойств, которые необходимы. Используя данные инструменты, ты соответственно лишаешся "надежности". Сравнивать либу и фреймворк нельзя. Это разные инструменты, каждый для своих задач. Да, где то их свойства пересекаются.

со всеобщего позволения отвечу Опять мимо…. что может Kafka, чего не может сделать 0mq быстрее?

Какфка даёт всеобще признаную притокольную надёжность. С Зеро ты сам создаёшь соглашение под свои хотелки, отсюда отсутствие надежности.

Гарантированно доставлять сообщения.

Опять мимо…. что может Kafka, чего не может сделать 0mq быстрее?

Чтобы попробовать закрыть гештальт, вернусь к перечисленным выше пунктам Гарантии доставки exactly once в 0mq нет. И нет в первую очередь потому, что нет гарантии доставки вообще: если клиент недоступен, сообщение будет потеряно. Сообщения, отправленные паблишерами, не хранятся в персистентном хранилище. Это то отсутствие журнала, про которое я писал выше. Тебя это возмутило, и если я не прав, покажи, пожалуйста, в чём я не прав. Я же нашёл в доке 0mq забавную фразу Reliability requires complexity that most of us don’t need. Не нужно вам это, короче 😁 В каких-то случаях действительно можно терять сообщения без ущерба для функционирования. Но далеко не всегда Ещё одно следствие отсутствия гарантий доставки - отсутствие гарантий на сохранение порядка сообщений. Опять же, для множества систем это может быть критически важно. Кафка позволяет гарантировать очерёдность даже для множества инстансов подписчика одного топика через партиции и группы. При этой схеме все сообщения с одинаковым ключом будут в порядке очередности предоставлены конкретному инстансу из группы. То есть не будет такой ситуации, что первое сообщения для пользователя А получил процесс 1, а второе процесс 2, и более быстрый процесс 2 отработал раньше процесса 1, что привело к несогласованности данных Ещё я писал про брокер. Брокер нужен для того, чтобы компоненты системы не были привязаны к текущей топологии. Чтобы новые сервисы можно было добавлять, удалять, переносить без изменений во всех остальных сервисах ZeroMQ is brokerless - они сами себя так описывают. Вроде всё очевидно. Сделать брокер самостоятельно можно, но из коробки его нет. Причём Кафка из коробки умеет поднимать кластер из множества брокеров, масштабировать партиции по брокерам. Реализовать подобную функциональность будет на порядок сложнее, чем реализовать одиночный брокер При всём сказанном выше я по прежнему считаю, что сравнивать кафку (и кролик, и натс - любой полноценный брокер) с 0mq на самом деле некорректно. Это инструменты для разных целей. Для ipc 0mq может быть очень хорошим вариантом. Пока мы остаёмся в рамках одной машины, нам может быть действительно важно общаться быстро, и гораздо проще будет учитывать все ограничения 0mq. Но полноценный брокер эта библиотека не заменит

под конец темы с mq а не будет ли хорошей практикой абстрагироваться от message broker в приложении? или в большинстве случаев не имеет смысла?

Зависит от того, для чего используется брокер, и какие возможности вообще нужны Часто замена одного на другое невозможна или сложна технически, потому что кролик и Кафка используют разные подходы, и могут применяться для решения разных задач. Иногда в одном приложении одновременно используются несколько брокеров, каждый для своей цели (дискуссия о том, насколько это хорошая практика, вполне уместна, но тем не менее - так бывает) Но если ограничить применение брокера каким-то минимумом, который можно реализовать на каждом из них, такая абстракция вполне уместна. Одна из вещей, за которые я люблю молекулер - возможность одной строкой в конфиге менять транспорт между кафкой, кроликом, натсом, редисом, и чем угодно ещё, для чего существует адаптер При этом надо понимать, что в данном случае брокер будет использован только как транспорт. Его специфичные возможности могут не использоваться, сильные стороны могут игнорироваться. В примере с молекулером, например, не вижу зачем можно было бы использовать кафку или кролика, и, вероятно, всегда более оптимальным выбором будет натс или редис

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

ну в молекулере делать несколько транспортеров одновременно это тот еще ад имею ввиду несколько брокеров в приложении

Про несколько брокеров в одном приложении - другой контекст, не связано с молекулером, и подразумевает использование брокеров для разных целей