Это божественно! Именно то, что и я и искал. Супер! Спасибо большое!

Прям очень круто! Спасибо!

Еще, еще, прям надо еще, где взять ? Очень годный контент!

Спасибо!

Отличная подача материала, спасибо за ваши старания!

Толя перестал говорить "тошто", браво! Но стал похожим на робота )

Соглашусь с теми, кто был недоволен подачей материала, хотел уговорить начальство оплатить курс по кафке на слёрме (кстати, интересен генезис наименования), но теперь думаю найти похожий где-то в другом месте. В данный момент являюсь слушателем курса "кубик для разработчиков", вот там все спикеры просто класс, но не здесь!

@caffeinejavacode1475

Жыл бұрын

Есть одно видео на ютуб где все по полочкам

Круто молодцы

а что у вас есть для системных аналитиков ?

10:46 не понял про номера партиций и хеширование(

1. В какую партицию записывается сообщение? 2. зачем читать сервиса из всех портиций, почему бы не читать с одной? 3. Если кафка брокер то внутри ещё брокеры? 7:37 4. Как быть с консистентностью если данные в разных партициях?

@slogic10

Жыл бұрын

1. по хэшу от ключа. но в видео не сказали, что ключа может и не быть. в этом случае применяется round robin алгоритм (последовательно распределяется по всем партициям) 2. сервис читает из топика вообще-то. вопрос некорректный. если сервисов (потребителей) много с одним и тем же group id, то они читают с разных узлов одновременно. 3. не кафка брокер, а в кластере кафки много брокеров. 4. кому быть? это забота брокеров в кластере. вон стрелок куча с репликациями.

Огонь, просто огонь! Я "купил"

Спасибо за полезный материал. Как партиции работают для Cosumer'ов вроде понял. Простите за глупые вопрос джуна) А как партиции работают для Producer'ов? Например, у меня 2 партиции и 3 Продюсера, все аппендится будет в зависимости от ключа по его уникальности Murmur Hash или случайно RoundRobin. И возможность сказать Продюсеру пиши только в эту партицию - это использовать уникальный ключ? Но как тогда "запретить" остальным двум туда писать - ведь они могут туда аппендить "сообщение" со случайным ключем - RoundRobin. Или это лишнее? Не является ли пример, где 3 партиции и 4 потребителя неким "аналогом" резервсного потребителя. Т.е. если один из трех работающих перестал работать. Начинает работать четвертый. Или это плохо, т.к. непонятно откуда этот четвертый начнет, что прочитает и следовательно нарушится последовательность, если она нужна. Спасибо)

@anatoly6446

3 жыл бұрын

> все аппендится будет в зависимости от ключа по его уникальности Murmur Hash или случайно RoundRobin Это можно контролировать на клиенте (можно оба режима использовать). В тч можно настроить продюсеров всегда использовать распределение по ключу если он есть и кидать раундробином если ключ не указан. Если не нравится мурмур, можно написать свой и использовать его для распределения как нужно в вашем кейсе

@anatoly6446

3 жыл бұрын

> Не является ли пример, где 3 партиции и 4 потребителя неким "аналогом" резервсного потребителя. активных консьюмеров в таком кейсе все равно будет три (тк три партиции). Четвертый консьюмер будет просто стоять в сторонке и потреблять ресурсы. "Резервный" здесь не совсем правильное слово, кажется - консьюмеры не содержат стейта и их можно легко терять и поднимать. Те в общем случае нет смысла держать "резервного" консьюмера в холостом режиме на подхвате (легче просто зарестартить упавшего консьюмера или поднять нового когда это будет нужно). И еще один момент - в таком случае если произойдет ребаланс в группе из 4 консьмеров, не факт что консьюмеры останутся теми же, что и были раньше (может быть какой-то другой консьюмер после ребаланса начнет простаивать).

кафка аналог рест апи что ли? также позволяет обмениваться данными между приложениями?

- Чем отличаются различные брокеры сообщений друг от друга? - Смотря какой фабрик, смотря сколько дитейлс. Так шо они юнивёрсал. Кафка же эмейзинг для всех.

Два вопроса: kzread.info/dash/bejne/a4eLpcaLlZrTpLA.html "хешируете номер партиции исходя из общего числа" - что значит "хешируете"? может "запоминаете номер партиции"? Вообще делать отдельную партицию какой-то особенной звучит странно и по-хакерски, ведь номер партиции это внутренний механизм кафки. Не надо его запоминать, все партиции равны. kzread.info/dash/bejne/a4eLpcaLlZrTpLA.html "при добавлении новой партиции есть шанс потерять данные, прочитав их до того как консьюмеры обновят метаданные по этой партиции". Но ведь партиция новая и никаких метаданных по ней не прочитано, следовательно offset не может быть отличным от нуля. Выходит данные из новой партиции всегда будут считаны корректно?

Почему назвали push и pull модели, больше мне кажется подходит polling и notify(watching)

фетчит сообщение... помечая как инфлайт( ну совсем не понятно) , мне бы простым языком

Да бля, че просто книгу орелли пересказываете по кафке

интересно, кафка не имеет единую точку отказа, но зукипер может положить кластер)))

Плохая подача информации: слова-паразиты на английском, отсутствие дублирования информации на схемах. Часть, посвящённую алгоритму подтверждения получения сообщений приходится переслушивать по несколько раз, т.к. нужно представить как это происходит. Схема очень бы помогла.

@maximareschenko

2 жыл бұрын

это вы еще тренинги индусов не слушали :) там еще и чужой язык добавляет колороита. вместе с произношением...

@slogic10

Жыл бұрын

они просто читают. если бы поработали с тем о чем вещают, было бы совсем по другому.

Когда говорит Александр, ничего не понятно))

Про структуру данных плохо рассказано

@slogic10

Жыл бұрын

json, avro и прочее? ))

да, что-то реально не понятно, мало визуализации и подробностей)

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

не совсем понятно где здесь "отличная подача материала", справа чел в очках сидит по бумажке читает

Какой топик, какая партиция и т.д.? И почему тогда например ключ, а не KEY? Ну говорите по-русски, так делайте это до конца, чтобы в голове у молодежи информация складывалась в четкие образы, а не получалась каша и подмена образов. Я понимаю, что Вы привязываетесь к англоязычной документации, но тогда и пишите: Сообщения отправляются в Темы(Topics), каждая тема состоит 1-го и более Разделов(Pattion). Или вещайте полностью на английском. Ну вот сервер - это уже установившиеся понятие. Аналогично: Производитель(Producer) Потребитель(Consumer) и т.д.

@enable4

Жыл бұрын

Топик, партиция, оффсет уже стали стандартными понятиями в кафке, зачем этот костыльный перевод? Из-за подобной русификации зачастую невозможно читать литературу, потому что ты привыкаешь, что партиции все называют партициями, а потом видя разделы, смещения, темы, потребителей, производителей и прочую самодеятельность, перестаёшь улавливать контекст. По крайней мере это моя личная боль

@3YM

Жыл бұрын

@@enable4 Не стоит путать "стандартные понятия" со смысловыми образами сложившимися с определённом круге общения. Это проще(но не хорошо) только для Вас и вашего круга общения, но крайне вредно, как для целевой аудитории, так и для Вас. Если вы действительно хотите помочь людям слабо владеющим английским, то topic - это тема, и т.д., и не как иначе! Это болезненно, на первый взгляд для образа мышления сложившегося у Вас, но не отдаляет ваш круг общения от остального общества (почему это плохо и к чему приводит мы начнем понимать чуть позже). Для понимания, мне вообще не нравится современные языки общения человечества и имеет смысл создания универсального языка без привязки к какому либо из существующих. Но, как программиста, вы можете сами смоделировать последствия замены пары операторов, при создании очередной версии компилятора на, на синтаксис из другого языка, просто потому, что больше коррелирует с текущим образом вашего мышления.

@slogic10

Жыл бұрын

@@3YM я за то чтобы топик остался топиком. тема это бред. раздел еще можно. вот консюмер точно надо на потребителя заменить ))

бла бла бла, где код?

Муть мутная, кроме основ, топик, консюмер, продюсер, все остальное муть и жуть. Потом такие вот обученные специалисты приходят устраиватся на работу и если к несчастью их возьмут, они начинают писать КОД. 😢

Стрелки на диаграммах указывают направление потока данных (а не запроса). У вас при пулл модели со стороны потребителя стрелка в сторону брокера. Это идиотизм. Вам самим не смешно? Выглядит так что и источник и потребитель пушат в очередь, и она скоро лопнет.

Спасибо!