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