Григорий Кошелев - Когда всё пошло по Кафке

Ближайшая конференция - Joker 2024, 9 октября (Online), 15-16 октября, Санкт-Петербург
- -
. . . . Полезный доклад, в котором не только рассказываются грабли в эксплуатации Apache Kafka, но и объяснены трейд-оффы и архитектурные особенности, которые к этим граблям приводят. Если у вас есть Кафка, то доклад стоит послушать.
Погрузимся в архитектуру компонентов Кафки. Вместе пройдёмся по граблям, которые заботливо собраны в одну презентацию. Постараемся понять, откуда в Кафке взялись различные ограничения. Всё по-честному, никакого маркетинга.
Выбранные для доклада грабли помогут ответить на следующие вопросы:
Что не так с настройками (по умолчанию)?
К каким неожиданностям должны быть готовы клиенты?
Зачем Кафке девопс?
Много настроек - это хорошо или плохо?
О чём забыли написать в документации?

[@illiailliaa8846]

познавательно и по делу!

[@simplechannel7859]

Лайк докладчику!

[@alexanderten9540]

Можно разобрать async...await как мессадж времени жизни по Кафке? Это то, что Бутстрапу нужно от Кафки

[@mfe_]

Очень жизненно, к сожалению.

[@johngraham8220]

18:02 не понял противопоставления ОРСУБД и брокера сообщений. Это как бы штуки, предназначенные для разных целей.

[@olegmaslov2057]

10:50 Какой смысл считать номер партиции для нового сообщения? Ведь банальный "револьверный подход" будет сохранять новые сообщения равномерно по всем партициям по кругу. А на высчитывание хэша и получение остатка от деления уйдёт какое-то процессорное время...

[@avchitov]

например, если нужно чтобы данные по одному и тому же клиенту попадали всегда на одну и ту же партицию. Почитайте про шардирование - аналогия 1 к 1.

[@pvinnie3827]

а теперь еще помножте все это на разную реализацию в разных либах на разных ЯП. Автору респект, конечно

[@TaranovskiAlex]

Спасибо за доклад!

[@antNecrom]

Очень приятный докладчик, очень хороший доклад

[@derzimstroy]

А кто может сказать, как определяется момент удаления сообщения в шине, если она не знает ничего про подписчиков ? Или всё-таки знает ?

[@hrensgoryable]

В каждом топике настраивается retention - критерий удаления сообщений. Можно настроить по времени (от момента получения сообщения, это включено по умолчанию с временем жизни в одну неделю) или по размеру данных топика на диске. Про подписчиков топик ничего не знает, ему всё равно есть ли они, сколько их, кто из них что прочитал и т.п. - это их дело.

[@derzimstroy]

@@hrensgoryable Спасибо за пояснение, возникает ощущение, что Кафка не годится для систем где сообщения принципиально не должны теряться и дублироваться например, банковских или платежных. А вот для всяких логов/статистики - пойдет.

[@hrensgoryable]

@@derzimstroy чтобы не терялись можно добиться относительно просто, а вот к повторному появлению того же сообщения в обработке надо быть готовым.

[@derzimstroy]

@@hrensgoryable На клиентах надо тщательно кодить и сохранять id последних обработанных собщениий, нет воокфлоу обработки и обогащения сообщений, а в чем тогда преимущества ? Типа бесплатный сыр ?

[@hrensgoryable]

@@derzimstroy на клиенте надо всегда быть готовым к тому, что прилетит уже обработанное сообщение (либо быть готовым к потерям) - гарантии доставки уровня exactly once это скорее теоретическая возможность такой доставки, чем практическая гарантия. Преимущества - имеется в виду перед чем? Если вам не нужно обрабатывать миллионы/миллиарды сообщений в день, то JMS как по мне удобнее. Если надо - то Кафка выглядит интереснее, т.к. она изначально спроектирована так, чтобы её легко было горизонтально масштабировать, когда возможностей вертикального масштабирования уже не хватает.

[@vyacheslavbelov4320]

Хороший доклад. Люди заново изобретают велосипед. Смотрю на все это и думаю чем JMS не устраивает? В лучшей его реализации. С 2008 года использую Sonic MQ. Все там было о чем сейчас хайп поднимают.

[@12zxqwas1]

На 4 минуте ответ уже.

[@vyacheslavbelov4320]

И это все? Но увы, тоже есть в JMS.

[@manOfPlanetEarth]

@@12zxqwas1 Есть чем дальше парировать Вячеслава Белова?🤔

[@manOfPlanetEarth]

@@12zxqwas1 ????

[@ildarvalitov2568]

Кафка это распределённый высоконадежный и высокопроизводительный лог. Этот проект был спроектирован как лог. Его можно использовать как massage broker, но это вариант использования 😊