Основы технологии Apache Kafka, вторая тема открытого базового курса
HTML-код
- Опубликовано: 30 июл 2024
- Пройти полный курс Apache Kafka База - to.slurm.io/yVOq3g
На курсе расскажем, как настраивать распределенный отказоустойчивый кластер, как отслеживать метрики и многое другое. После прохождения курса станете гуру равномерного распределения нагрузки.
В этом уроке:
00:00 - Цели урока.
00:30 - Kafka vs Queues.
05:37 - Структура данных.
08:35 - Consumer groups.
14:42 - Apache Zookeeper.
16:16 - Резюме урока.
✅Дополнительные материалы к уроку: github.com/Slurmio/kafka-free
❗️Посмотреть программу продвинутого курса: to.slurm.io/yVOq3g
Все уроки базового курса в плейлисте: • Apache Kafka, открытый...
Авторы курса:
Анатолий Солдатов, Lead Engineer в Авито
Александр Миронов, Infrastructure Engineer в Stripe, ex-Booking
Полезные ссылки:
Канал Слёрм в телеграм: t.me/slurmnews
Это божественно! Именно то, что и я и искал. Супер! Спасибо большое!
Прям очень круто! Спасибо!
Спасибо!
Еще, еще, прям надо еще, где взять ? Очень годный контент!
Соглашусь с теми, кто был недоволен подачей материала, хотел уговорить начальство оплатить курс по кафке на слёрме (кстати, интересен генезис наименования), но теперь думаю найти похожий где-то в другом месте. В данный момент являюсь слушателем курса "кубик для разработчиков", вот там все спикеры просто класс, но не здесь!
Есть одно видео на ютуб где все по полочкам
Круто молодцы
Отличная подача материала, спасибо за ваши старания!
Толя перестал говорить "тошто", браво! Но стал похожим на робота )
1. В какую партицию записывается сообщение?
2. зачем читать сервиса из всех портиций, почему бы не читать с одной?
3. Если кафка брокер то внутри ещё брокеры? 7:37
4. Как быть с консистентностью если данные в разных партициях?
1. по хэшу от ключа. но в видео не сказали, что ключа может и не быть. в этом случае применяется round robin алгоритм (последовательно распределяется по всем партициям)
2. сервис читает из топика вообще-то. вопрос некорректный. если сервисов (потребителей) много с одним и тем же group id, то они читают с разных узлов одновременно.
3. не кафка брокер, а в кластере кафки много брокеров.
4. кому быть? это забота брокеров в кластере. вон стрелок куча с репликациями.
Огонь, просто огонь! Я "купил"
10:46
не понял про номера партиций и хеширование(
а что у вас есть для системных аналитиков ?
- Чем отличаются различные брокеры сообщений друг от друга?
- Смотря какой фабрик, смотря сколько дитейлс. Так шо они юнивёрсал. Кафка же эмейзинг для всех.
кафка аналог рест апи что ли? также позволяет обмениваться данными между приложениями?
Спасибо за полезный материал.
Как партиции работают для Cosumer'ов вроде понял.
Простите за глупые вопрос джуна)
А как партиции работают для Producer'ов?
Например, у меня 2 партиции и 3 Продюсера, все аппендится будет в зависимости от ключа по его уникальности Murmur Hash или случайно RoundRobin.
И возможность сказать Продюсеру пиши только в эту партицию - это использовать уникальный ключ?
Но как тогда "запретить" остальным двум туда писать - ведь они могут туда аппендить "сообщение" со случайным ключем - RoundRobin.
Или это лишнее?
Не является ли пример, где 3 партиции и 4 потребителя неким "аналогом" резервсного потребителя. Т.е. если один из трех работающих перестал работать. Начинает работать четвертый. Или это плохо, т.к. непонятно откуда этот четвертый начнет, что прочитает и следовательно нарушится последовательность, если она нужна.
Спасибо)
> все аппендится будет в зависимости от ключа по его уникальности Murmur Hash или случайно RoundRobin
Это можно контролировать на клиенте (можно оба режима использовать). В тч можно настроить продюсеров всегда использовать распределение по ключу если он есть и кидать раундробином если ключ не указан. Если не нравится мурмур, можно написать свой и использовать его для распределения как нужно в вашем кейсе
> Не является ли пример, где 3 партиции и 4 потребителя неким "аналогом" резервсного потребителя.
активных консьюмеров в таком кейсе все равно будет три (тк три партиции). Четвертый консьюмер будет просто стоять в сторонке и потреблять ресурсы. "Резервный" здесь не совсем правильное слово, кажется - консьюмеры не содержат стейта и их можно легко терять и поднимать. Те в общем случае нет смысла держать "резервного" консьюмера в холостом режиме на подхвате (легче просто зарестартить упавшего консьюмера или поднять нового когда это будет нужно).
И еще один момент - в таком случае если произойдет ребаланс в группе из 4 консьмеров, не факт что консьюмеры останутся теми же, что и были раньше (может быть какой-то другой консьюмер после ребаланса начнет простаивать).
Два вопроса:
ruclips.net/video/9SWCdRe7mtM/видео.html "хешируете номер партиции исходя из общего числа" - что значит "хешируете"? может "запоминаете номер партиции"? Вообще делать отдельную партицию какой-то особенной звучит странно и по-хакерски, ведь номер партиции это внутренний механизм кафки. Не надо его запоминать, все партиции равны.
ruclips.net/video/9SWCdRe7mtM/видео.html "при добавлении новой партиции есть шанс потерять данные, прочитав их до того как консьюмеры обновят метаданные по этой партиции". Но ведь партиция новая и никаких метаданных по ней не прочитано, следовательно offset не может быть отличным от нуля. Выходит данные из новой партиции всегда будут считаны корректно?
фетчит сообщение... помечая как инфлайт( ну совсем не понятно) , мне бы простым языком
Да бля, че просто книгу орелли пересказываете по кафке
Почему назвали push и pull модели, больше мне кажется подходит polling и notify(watching)
интересно, кафка не имеет единую точку отказа, но зукипер может положить кластер)))
Когда говорит Александр, ничего не понятно))
да, что-то реально не понятно, мало визуализации и подробностей)
Плохая подача информации: слова-паразиты на английском, отсутствие дублирования информации на схемах. Часть, посвящённую алгоритму подтверждения получения сообщений приходится переслушивать по несколько раз, т.к. нужно представить как это происходит. Схема очень бы помогла.
это вы еще тренинги индусов не слушали :) там еще и чужой язык добавляет колороита. вместе с произношением...
они просто читают. если бы поработали с тем о чем вещают, было бы совсем по другому.
Про структуру данных плохо рассказано
json, avro и прочее? ))
так себе подача, лучше бы текстом выложили, раз все равно читаете
не совсем понятно где здесь "отличная подача материала", справа чел в очках сидит по бумажке читает
Какой топик, какая партиция и т.д.? И почему тогда например ключ, а не KEY? Ну говорите по-русски, так делайте это до конца, чтобы в голове у молодежи информация складывалась в четкие образы, а не получалась каша и подмена образов. Я понимаю, что Вы привязываетесь к англоязычной документации, но тогда и пишите: Сообщения отправляются в Темы(Topics), каждая тема состоит 1-го и более Разделов(Pattion). Или вещайте полностью на английском.
Ну вот сервер - это уже установившиеся понятие.
Аналогично:
Производитель(Producer)
Потребитель(Consumer)
и т.д.
Топик, партиция, оффсет уже стали стандартными понятиями в кафке, зачем этот костыльный перевод? Из-за подобной русификации зачастую невозможно читать литературу, потому что ты привыкаешь, что партиции все называют партициями, а потом видя разделы, смещения, темы, потребителей, производителей и прочую самодеятельность, перестаёшь улавливать контекст. По крайней мере это моя личная боль
@@enable4 Не стоит путать "стандартные понятия" со смысловыми образами сложившимися с определённом круге общения. Это проще(но не хорошо) только для Вас и вашего круга общения, но крайне вредно, как для целевой аудитории, так и для Вас. Если вы действительно хотите помочь людям слабо владеющим английским, то topic - это тема, и т.д., и не как иначе! Это болезненно, на первый взгляд для образа мышления сложившегося у Вас, но не отдаляет ваш круг общения от остального общества (почему это плохо и к чему приводит мы начнем понимать чуть позже).
Для понимания, мне вообще не нравится современные языки общения человечества и имеет смысл создания универсального языка без привязки к какому либо из существующих. Но, как программиста, вы можете сами смоделировать последствия замены пары операторов, при создании очередной версии компилятора на, на синтаксис из другого языка, просто потому, что больше коррелирует с текущим образом вашего мышления.
@@3YM я за то чтобы топик остался топиком. тема это бред. раздел еще можно. вот консюмер точно надо на потребителя заменить ))
бла бла бла, где код?
Муть мутная, кроме основ, топик, консюмер, продюсер, все остальное муть и жуть.
Потом такие вот обученные специалисты приходят устраиватся на работу и если к несчастью их возьмут, они начинают писать КОД. 😢
Стрелки на диаграммах указывают направление потока данных (а не запроса). У вас при пулл модели со стороны потребителя стрелка в сторону брокера. Это идиотизм. Вам самим не смешно? Выглядит так что и источник и потребитель пушат в очередь, и она скоро лопнет.
Спасибо!