Комментарии 4
Биндинг (Binding) — условие, по которому обменник определяет, в какую из очередей сообщения должны попадать.
Не обязательно, можно соединять и exchange-и, а ещё может занимается фильрацией по шаблонам, выбирая куда послать сообщение
Для реализации RPC в RabbitMQ необходимо создать клиентский и серверный код.
Он не сильно отличается от обычного коннекта к очереди или эксченджю, а по размеру так вообще тоже самое (это через amqp - другие не пробовал)
после подтверждения о доставке RabbitMQ удаляет сообщение
это зависит от парамеров коннекта консюмера, может и не удалять, можно двигаться по очереди, как кафки, только этим мало пользуются
Репликация: Kafka автоматически реплицирует данные на несколько серверов, что обеспечивает избыточность данных и улучшает отказоустойчивость.
Масштабирование: В Kafka можно легко добавить больше серверов, когда объем данных увеличивается.
У раббита всё это есть, только оно чуть по другому работает из-за другой архитектуры. Нужна отказоустойчивать - сразу ставит 3 реплики раббита. Потом наращивают
RabbitMQ Написан на Erlang и совместим с большинством популярных ОС.
Жуткая морока с этим эрлангом, если надо собрать раббит, а не использовать готовый бинарник: собираются не все версии, собирается очень долго, возня с плагинами, которые опять не со всеми версиями собираются, а про некоторые функции, типа дедупликатора сообшений, посылают только ставить плагины
Zookeeper — всё это должен кто-то координировать, и делает это Zookeeper.
только этого координатора постепенно выпиливают из кафки, чтобы могла работать сама :)
Kafka ... если есть сценарии, когда несколько потребителей должны получить все сообщения
В раббите 1 exchange соединяется с несколькими очередями, если 1 потребитель - добавляем очередь, ушёл потребитель - удалили очередь. Разница в другом: кафка может быть базой, хранящей сообщения хоть за пару лет, и новая группа может вычитать все сообщения с нуля, а вот в раббите это надо планировать очень заранее, т. к. очередь хотя и может хранить сообщения, но работать базой она всё же не планировалась, надо заранее подумать о хранении.
RabbitMQ используется там, где нужна надежность и
гарантированная доставка. А также там, где требуются паттерны, которые
не поддерживает Apache Kafka:
Не знаю, может я что-то не так настраивал, но если раббит пишет в clickhouse через view, то у меня терялись сообщения, причём чем больше поток, тем больше потерь, а вот у кафки такой проблемы не было. Но я потом обошёлся AsyncInsert-ом в clickhouse.
PS Веб-морда для управления удобнее у раббита.
Биндинг (Binding) — условие, по которому обменник определяет, в какую из очередей сообщения должны попадать.
Не обязательно, можно соединять и exchange-и, а ещё может занимается фильрацией по шаблонам, выбирая куда послать сообщение
Для реализации RPC в RabbitMQ необходимо создать клиентский и серверный код.
Он не сильно отличается от обычного коннекта к очереди или эксченджю, а по размеру так вообще тоже самое (это через amqp - другие не пробовал)
после подтверждения о доставке RabbitMQ удаляет сообщение
это зависит от парамеров коннекта консюмера, может и не удалять, можно двигаться по очереди, как кафки, только этим мало пользуются
Репликация: Kafka автоматически реплицирует данные на несколько серверов, что обеспечивает избыточность данных и улучшает отказоустойчивость.
Масштабирование: В Kafka можно легко добавить больше серверов, когда объем данных увеличивается.
У раббита всё это есть, только оно чуть по другому работает из-за другой архитектуры. Нужна отказоустойчивать - сразу ставит 3 реплики раббита. Потом наращивают
RabbitMQ Написан на Erlang и совместим с большинством популярных ОС.
Жуткая морока с этим эрлангом, если надо собрать раббит, а не использовать готовый бинарник: собираются не все версии, собирается очень долго, возня с плагинами, которые опять не со всеми версиями собираются, а про некоторые функции, типа дедупликатора сообшений, посылают только ставить плагины
Zookeeper — всё это должен кто-то координировать, и делает это Zookeeper.
только этого координатора постепенно выпиливают из кафки, чтобы могла работать сама :)
Kafka ... если есть сценарии, когда несколько потребителей должны получить все сообщения
В раббите 1 exchange соединяется с несколькими очередями, если 1 потребитель - добавляем очередь, ушёл потребитель - удалили очередь. Разница в другом: кафка может быть базой, хранящей сообщения хоть за пару лет, и новая группа может вычитать все сообщения с нуля, а вот в раббите это надо планировать очень заранее, т. к. очередь хотя и может хранить сообщения, но работать базой она всё же не планировалась, надо заранее подумать о хранении.
RabbitMQ используется там, где нужна надежность и
гарантированная доставка. А также там, где требуются паттерны, которые
не поддерживает Apache Kafka:
Не знаю, может я что-то не так настраивал, но если раббит пишет в clickhouse через view, то у меня терялись сообщения, причём чем больше поток, тем больше потерь, а вот у кафки такой проблемы не было. Но я потом обошёлся AsyncInsert-ом в clickhouse.
PS Веб-морда для управления удобнее у раббита.
Кафка уже несколько лет как может работать без zookeeper. Все оффсеты она тогда хранит (если ничего опять не поменялось) внутри полностью реплицированного системного топика
На картинке ошибка – клиент с Zookeeper’ом не общается и вообще не знает, что он есть. Это чисто внутренняя кафковская заморочка для надёжного хранения конфигурации кластера.
Сравнительный анализ Apache Kafka и RabbitMQ