Григорий Кошелев - Когда всё пошло по Кафке
Вставка
- Опубліковано 4 сер 2019
- Ближайшая конференция - Joker 2024, 9 октября (Online), 15-16 октября (Санкт-Петербург + трансляция).
Подробности и билеты: jrg.su/Ypf1HW
- -
. . . . Полезный доклад, в котором не только рассказываются грабли в эксплуатации Apache Kafka, но и объяснены трейд-оффы и архитектурные особенности, которые к этим граблям приводят. Если у вас есть Кафка, то доклад стоит послушать.
Погрузимся в архитектуру компонентов Кафки. Вместе пройдёмся по граблям, которые заботливо собраны в одну презентацию. Постараемся понять, откуда в Кафке взялись различные ограничения. Всё по-честному, никакого маркетинга.
Выбранные для доклада грабли помогут ответить на следующие вопросы:
Что не так с настройками (по умолчанию)?
К каким неожиданностям должны быть готовы клиенты?
Зачем Кафке девопс?
Много настроек - это хорошо или плохо?
О чём забыли написать в документации? - Наука та технологія
познавательно и по делу!
Лайк докладчику!
Очень жизненно, к сожалению.
Можно разобрать async...await как мессадж времени жизни по Кафке? Это то, что Бутстрапу нужно от Кафки
а теперь еще помножте все это на разную реализацию в разных либах на разных ЯП. Автору респект, конечно
10:50 Какой смысл считать номер партиции для нового сообщения? Ведь банальный "револьверный подход" будет сохранять новые сообщения равномерно по всем партициям по кругу. А на высчитывание хэша и получение остатка от деления уйдёт какое-то процессорное время...
например, если нужно чтобы данные по одному и тому же клиенту попадали всегда на одну и ту же партицию. Почитайте про шардирование - аналогия 1 к 1.
18:02 не понял противопоставления ОРСУБД и брокера сообщений. Это как бы штуки, предназначенные для разных целей.
Спасибо за доклад!
Очень приятный докладчик, очень хороший доклад
А кто может сказать, как определяется момент удаления сообщения в шине, если она не знает ничего про подписчиков ? Или всё-таки знает ?
В каждом топике настраивается retention - критерий удаления сообщений. Можно настроить по времени (от момента получения сообщения, это включено по умолчанию с временем жизни в одну неделю) или по размеру данных топика на диске. Про подписчиков топик ничего не знает, ему всё равно есть ли они, сколько их, кто из них что прочитал и т.п. - это их дело.
@@hrensgoryable
Спасибо за пояснение, возникает ощущение, что Кафка не годится для систем где сообщения принципиально не должны теряться и дублироваться например, банковских или платежных. А вот для всяких логов/статистики - пойдет.
@@derzimstroy чтобы не терялись можно добиться относительно просто, а вот к повторному появлению того же сообщения в обработке надо быть готовым.
@@hrensgoryable
На клиентах надо тщательно кодить и сохранять id последних обработанных собщениий, нет воокфлоу обработки и обогащения сообщений, а в чем тогда преимущества ? Типа бесплатный сыр ?
@@derzimstroy на клиенте надо всегда быть готовым к тому, что прилетит уже обработанное сообщение (либо быть готовым к потерям) - гарантии доставки уровня exactly once это скорее теоретическая возможность такой доставки, чем практическая гарантия. Преимущества - имеется в виду перед чем? Если вам не нужно обрабатывать миллионы/миллиарды сообщений в день, то JMS как по мне удобнее. Если надо - то Кафка выглядит интереснее, т.к. она изначально спроектирована так, чтобы её легко было горизонтально масштабировать, когда возможностей вертикального масштабирования уже не хватает.
Хороший доклад. Люди заново изобретают велосипед. Смотрю на все это и думаю чем JMS не устраивает? В лучшей его реализации. С 2008 года использую Sonic MQ. Все там было о чем сейчас хайп поднимают.
На 4 минуте ответ уже.
И это все? Но увы, тоже есть в JMS.
@@12zxqwas1
Есть чем дальше парировать Вячеслава Белова?🤔
@@12zxqwas1
????
Кафка это распределённый высоконадежный и высокопроизводительный лог. Этот проект был спроектирован как лог. Его можно использовать как massage broker, но это вариант использования 😊