Comments 27
Начали проект на кафке с горящими сроками и в итоге перелезли на NATS -- легко и очень быстро для наших нужд. Столкнулись как раз с указанными в статье проблемами....
NATS классный! Жаль что у него нет (и не будет, по всей видимости: https://github.com/nats-io/nats-streaming-server/issues/524) возможности распараллеливания обработки сообщений в случаях, когда порядок обработки для вас важен (в event sourcing например) — то, что достигается в Кафке с помощью партиционирования и consumer groups.
А ещё натс указан в https://landscape.cncf.io
Решение: мы заменили Kafka на RabbitMQ, который может по ключу определить, в какой канал отправить конкретное сообщение и кто его должен получить. Также по этому ключу потребители могут подписываться на обновления.
ничего не понял. Что мешало сделать один большой топик и все рецепты кидать туда как в общую шину, а на стороне консумеров сделать фильтрацию на основе ключа, который покажет подтип сообщения? Аналогия с газетой очень хорошая. Консумер один будет читать первую и последнюю страницу, консумер второй - первую и вторую, а третий - какую-то посередине. Все довольны. Единственная проблема, которая возникнет - если понадобится поменять формат сообщения. Это надо будет обновить продюсер и все консьюмеры. Но, черт возьми, в ребите будет ТОЧНО такая же проблема. А Кафка еще и производительнее
Проблема: есть consumer, который потребляет данные. Вы радостно отправляете данные в Kafka, но потом замечаете, что consumer ничего не потребляет. Kafka работает, consumer работает, но ничего не происходит.
по этой проблеме. Нужно было честно сказать - что речь о консумер группе, потому что никто не мешает два независимых консьюмера отправить читать топик с нулевого офсета. Но за рассказ спасибо. Это может реально кому-то сэкономить немного времени
Решение: мы увеличили max.poll.interval до двух часов и Session timeout до 5 часов. И пришли к следующей схеме — consumer подъезжал, загружал в себя данные и висел с ними около двух часов. В итоге топики блокировались, и из них ничего нельзя было достать.
ожидали какие-то чудеса? ну, нет никакой магии. И в принципе все логично. Если консумер ушел в какое-то cpu bound или i/o надолго и бесперспективно, то он не сможет читать сообщения.
У нас похожая система работает для обработки файлов: сообщения о новых PDF/JSON/etc. файлах пишутся в один топик и все обработчики слушают его и решают обрабатывать или игнорировать файл.
А Кафка еще и производительнее
Зачем использовать менее удобный (для конкретной задачи), но более производительный инструмент там, где эта производительность не важна?
В сабжевой задаче, насколько я понял, rabbit благодаря своему гибкому роутингу, не выходя из rabbit-а, решил конкретную проблему, без сложностей вида «на стороне консумеров сделать фильтрацию».
ну тут наверное можно сравнить стоимость замены кафки на кролика в стэке и написание доп 3 строчек кода на стороне приложения.
Зачем использовать менее удобный (для конкретной задачи), но более производительный инструмент там, где эта производительность не важна?
если производительность не важна - парни берут и делают очередь на редисе ) А Кафка уже во многих организациях есть как некое стандартное платформенное решение. Берешь и подключаешься.
Какая производительность? :)
это троллинг?
Тут рецепты хавки в кафке хранились.
откуда я знаю - может это какая-нибудь ДоДо пицца была, с одновременным запуском в печь 10000 пиццуль. В конце-концов народ умудряется с кривой архитектурой и аналитикой данных бигдату и хайлоад на ровном месте учудить
— Мы тут рецепты в кафке хранили и перенесли в rabbit, стало удобнее.
— Вы чо! Кафка производительней!
— Зачем нужна эта производительность?
— А вдруг бигдата есть?! А вдруг додо пицца?! Верните кафку!
Автор же уже пояснил, что им кролик удобнее. Значит им его производительности хватает.
да я не спорю, что кроль привычнее и удобнее разрабам. Но более правильным решением от этого не становится. Я сам неоднократно говорил, что на мой взгляд голая кафка слишком низкоуровневая. И это получается практически закат солнца вручную. Ну, та же история с ретраями, да? Как в Кафке это красиво сделать, без того, чтобы плодить топики. И чтобы не усложнять продюсер. Но именно по этой причине вокруг Кафки уже есть целая экосистема на любой вкус. Kafka Streams, Ksql. Сами конфлюентовцы предлагают Кафку как бд использовать. В принципе, это уже троллейбус из буханки получается, но для ряда задач - почему нет? а что с реббитом? да ничего ))) И, повторюсь, что если нужна простая очередь - ну, ее легко сделать на чем угодно - redis/pg, или взять что-то более нативное и современное вроде NATS (тоже есть в нескольких проектах и прекрасно себе работает)
В случае с кафкой, как Вы сами сказали, придется чем-то ее сверху наворачивать или что-то свое пилить.
наворачивание заключается в подключении правильной библиотеки. Для разработчиков это не должно быть проблемой.
А у колнфлюента еще и на каждом шагу с вас будут пытаться срубить тонны бабла.
я не предлагал пользоваться конфлюентом. Кафка - опенсурс и бесплатная. Бери и пользуй. И даже, наоборот, возможность купить поддержку у конфлюента является плюсом. А ребит кто там коммерчески поддерживает? Честно - не знаю.
Изначально мы попытались решить проблему, сделав много разных топиков на каждого потребителя. И это закономерно привело к тому, что Kafka «встала колом».
Объясните пожалуйста почему Kafka встала колом от 150 топиков? Confluent, насколько мне известно, говорит о тысячах, если не десятках тысяч топиков без проблем. Ну и, в целом, чем плох паттерн с topic=адрес сервиса, если я правильно понял вашу топологию?
The rule of thumb is that the number of Kafka topics can be in the thousands. Jun Rao (Kafka committer; now at Confluent but he was formerly in LinkedIn's Kafka team) wrote: At LinkedIn, our largest cluster has more than 2K topics. 5K topics should be fine.
Как связано время старта приложения и ребалансировка консьюмер группы?
У вас что - приложение запускается, читает и обрабатывает сообщение и гасится? Это какая-то полная хрень, как и часовые таймауты на обработку сообщения. Кафка вообще не для этого.
Но вообще-то коллега прав. В момент старта кучи реплик консумера в консумер группе будет ребаланс. И когда консумер сдохнет. Тоже будет ребаланс. И сам по себе время от времени ребаланс может быть. И про это же ниже - что не должно быть так, что Кафка ТОЛЬКО ЛИШЬ ребалансом занимается ( я видел такие кейсы ).
Странно читать. Мы наоборот переходим с раббита на кафку в местах где нужны несколько консюмеров, для декаплинга доменов, где нужен order of messages например в скопе аккаунта или на более гранулярном уровне например reservation, или нужна sequence обработка что бы уменьшить оверхед работы optimistic concurrency.
Раббит попрежнему используем для round robin обработки, ритраев, роутинга и т.д.
Я думаю что все таки зависит от целей и бизнеса. Так категорично менять раббит на кафку везде мы бы не стали.
Но вот некоторые вещи из статьи пригодятся!
В статье есть некоторые неточности
compacting - это не про то, чтобы почистить сообщения старше 7 дней. Это про то, чтобы убрать дубликаты - записи с одинаковым значением ключа. Из нескольких дубликатов кафка оставит только последнюю запись. А удалить все сообщения старше оговоренного срока - это retention. Оба этих параметра настраиваются независимо друг от друга
max.poll.interval.ms - это не про heartbeat. это про обработку сообщений, т.е. максимальный интервал между чтением последовательных сообщений. Heartbeat выполняется в другом потоке, следовательно, не зависит от обработки сообщений. Heartbeat должен отправляться не реже чем session.timeout.ms, так консьюмер дает понять кафке что он жив, получив ответ на heartbeat консьюмер может увидеть что идет ребалансировка. Частота, с которой консьюмер отправляет heartbeat, регулируется параметром
heartbeat.interval.ms
Heartbeat отправляются всеми consumer в Kafka, при этом промежуток между двумя heartbeat не должен превышать max.poll.interval.
Здесь как раз не должен превышать именно session.timeout.ms. Про эти две настройки хорошо написано здесь
Решение: мы увеличили max.poll.interval до двух часов и Session timeout до 5 часов
...
Мы решили снизить max.pool.interval, а Session timeout оставить, как есть
Но как раз таки session.timeout.ms не должен быть таким большим. Осталось загадкой, понизили ли вы его до разумных в итоге, или нет :)
Видимо решением фейла №3 было - делать мониторинг, следить за здоровьем consumer, исправить TTL через настройку retention.ms (по-умолчанию она 7дней).
А то в тексте что-то странное написано.
Решение: мы увеличили max.poll.interval до двух часов и Session timeout до 5 часов. И пришли к следующей схеме — consumer подъезжал, загружал в себя данные и висел с ними около двух часов. В итоге топики блокировались, и из них ничего нельзя было достать.
Вот уж решение достойно экранизации.
А по поводу статьи: тут описаны такие азы что жуть берет. Хуже наверно только статьи о минусах кафки, которую не смогли (не удалось) установить
Не совсем понял идею max.poll.interval до 5 часов. Мне кажется проблема не в кафка а в реализации consumer сервиса. Получается что он не завершал обработку сообщения по времени за 2 часа. Ну причины надо смотреть в коде - как сделано, как сообщение сериализуется/десериализуется, может затыкалось на каком то варианте данных.
Обкафкился по полной: 3 фейла с Apache Kafka