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