Comments 33
Эх... если бы все статьи были такими четкими, лаконичными!
Согласна полностью. Шикарная статья. Спасибо автору!
если бы все статьи были такими четкими, лаконичными
Твои б слова, да Богу в уши. Вместо этого появится еще одна дюжина статей на темы: "Из ветеринаров в программисты Python", "Как я победил алкоголизм и игроманию", и "Жизнь в Намибии после релокации".
фантастика, здорово "разжевано", но хотелось бы примеров с кодом для наглядности
Чем различаются Kafka и RabbitMQ: простыми словами
Хорошая попытка. Но увы - я уже лет пять примерно тоже самое пытаюсь объяснить, и примерно теми-же словами но... в общем плюнул уже...
а так да - все правильно написано
Количество партиций в топике зависит от количества его конкурирующих подписчиков
не корректно, оно не зависит от подписчиков. Вы можете сделать 10 partitions и 1 consumer, а можете наоборот (тогда конечно 9 консьюмеров будут простаивать). В идеальном случае число partitions должно соответствовать числу потребителей.
Ну очень поверхностно, есть гораздо больше различий, например Кафка более чувствительна к размеру сообщения и времени его обработки в отличие от RabbitMQ, а у последнего есть варианты подписки basic.consume (подписка как в Kafka) и basic.get, который делает только один запрос в queue. В RabbitMQ можно удалять очереди после прочтения сообщения или по timeout, в отличие от Kafka, и т.п.
А еще есть Rabbit.Streams
есть и Kafka Streams – https://docs.confluent.io/platform/current/streams/index.html
Но все же зависимость существует? Если у топика 10 конкурирующих подписчиков то логично создать 10 партиций? В начале предложения надо было добавить слово "Обычно".
Не логично. По крайней мере в общем смысле.
Если захочется проскалировать, добавив консюмера, то придется добавить и партицию. А это 1) ручная операция, 2) поломает партицирование по ключу (если используется)
Если завести 15 партиций на 10 консюмеров, то 5 из них будут нагружены в два раза больше чем 5 остальных.
Может показаться, что надо завести сотню-другую партиций, чтобы примерно распределить нагрузку поровну между изменяемым количеством консюмеров. Но каждая партиция - это минимум 6 открытых файловых дескрипторов на каждой ноде. И большое количество партиций - возможная проблема с Zookeeper.
Увы, приходится это все учитывать, по возможности, заранее.
под управлением Apache Zookeeper
Уже больше года, как под управлением кворума метаданных
Хорошее замечание, спасибо. Статья относится к начальному уровню поэтому многие подробности были опущены. Иначе пришлось бы углубляться и рассказать и о существовании других альтернатив для Zoo в виде Consul, Atomix, Jocko ...
не так ультимативно, Zookeeper так же и остался в Кафке, а Metadata Quorum, он же KRaft (https://developer.confluent.io/learn/kraft/) добавлен как мод, и as production ready он помечен только в последнем релизе, вышедшем буквально несколько дней назад
Простыми словами: Kafka — для работы, RabbitMQ — поиграться.
Совсем не так. Работы бывают разные.
Если для вас "если не хайлоад - то это не работа а на поиграться", то конечно да. Правда, звучит это довольно по-дилетантски - хайлоад это просто немножко другой класс задач, особой сложностью, с учётом имеющегося инструментария, не обладающий.
Немного о разных вещах. Какое-то время назад занимался фрилансом в духе "подниму все, что совсем упало", кролик с тенденцией прилечь был в топе. Может быть, сейчас что-то поменялось. Но Кафка для небольших нагрузок тоже работает нормально. Часто проблемы из пп.1 возникают, потому что проектировали все под девизом "ну у нас же не хайлоад". Наверняка мой датасет весьма перекошен, конечно.
Все понял, кроме одного - почему отправитель обозначен буквой N? 😎
При этом имеет высокий порог вхождения, требователен к ресурсам.
Kafka как раз имеет очень низкий порог вхождения, благодаря хорошей документации и качественной архитектуре. Высоким же этот порог становится лишь для тех, кто привык лишь аннотации расставлять, не понимая происходящего внутри. Мир разработки заполнен плохо понимающими общие принципы быстроделами, но как раз эти общие принципы и дают возможность понять кафку гораздо легче, чем какой-нибудь, прости хосспади, спринг. Спринг требует понимания, что было в голове у автора той или иной части и как он это сумел по быстрому сляпать в своей обвязке вокруг заимствованных компонентов. А кафка, если человек хорошо знаком с базовыми принципами, просто предлагает ему чистую реализацию, без малейшей каши из головы очередного мамкиного "архитектора".
Немного аналогий:
Кафка - это кольцо, оно вставляется в этот цилиндр.
Спринг - это магический круг вечного огня, он разжигает небесное пламя, и после всего лишь нескольких (но очень важных!) заклинаний вы сумеете победить подземного дракона, а потом поймать океанского кита, на чём вы заработаете огромную кучу денег и станете самым уважаемым архитектором в мире вечно зелёных цилиндров, поглощающих пламя вечного кругового огня! Скорее, все на спринг!
Не беспокойтесь, за свои слова я привык отвечать. Сертификаты же на самом деле ничего не доказывают, хоть и есть их у меня несколько штук, правда по технологиям IBM (MQ, Message Broker, etc).
Книги же - способ заработать. Никто не собирается давать вам систематизированные знания просто так, потому что систематизация затратна. Их дают исключительно ради прибыли, которая и окупает затраты. Ну а что бы была прибыль, нужна массовость. Поэтому про любой массовый продукт обязательно пишут книги. Да, про помаду и пенку для задницы малышей тоже пишут книги. Спросите у мамы, насколько сложно ей было разобраться с пенкой для задницы не читая соответствующие книги, поймёте смысл книжек про кафку.
статья норм для теоретической части, но важный момент: как проектировать такое взаимодействие?
Я понимаю, что что архвопрос, но то частый вопрос на людом собеседовании/любом месте работы...
То есть: как выглядит внутри. где можно развернуть поиграться...
Ещё одна разница, могущая стать весомой - Kafka не поддерживает приоритеты в очереди сообщений (что логично по самому принципу её работы), Rabbit - поддерживает.
Возможно, сейчас что-то изменилось в лучшую сторону, но где-то полгода назад пришлось велосипедить несколько топиков для псевдо-как-бы-приоритезации в кафке, потому что когда выяснилась эта необходимость - уже поздно было пить брожоми переходить на Rabbit.
Самое главное то не написали:
Kafka - надо её опрашивать 100 раз в секунду - есть что нового ?
RabbitMQ - сам вызовет функцию CallBack приложения когда придёт новое сообщение, не надо его опрашивать совсем.
Kafka - надо её опрашивать 100 раз в секунду - есть что нового ?
Если только средствами Kafka - нет. А вот другими средствами обеспечить нотификацию подписчика из публикатора никто не запрещает. Знаю, костыль. Через REST делаю это в исключительных случаях.
все написано, статью по диагонали читаете? тогда поищите слова push и pull.
Поясните пожалуйста, почему Rabbit уступает в отказоустойчивости? Там же есть и персистентность на уровне очередей и сообщений, режимы подтверждений как для паблишера, так и для получателя. Есть реликация между нодами и кворумные очереди на случай если живые ноды теряют связь между собой.
Ну а какой-нибудь IBM MQ не стали рассматривать... наверно из-за того что он платный )))
Чем различаются Kafka и RabbitMQ: простыми словами