Разбираем основы Kafka и RabbitMQ

Подписаться 372

Просмотров 7 тыс.

50% 1

Разберем основные компоненты архитектуры Kafka и RabbitMQ
Посмотрим use case в индустрии и примеры использования
Telegram: t.me/digital_train
Boosty: boosty.to/digital_train
Таймкоды:
00:00 Немного обо мне
01:23 RabbitMQ Архитектура и особенности
10:15 Kafka Архитектура и особенности
18:56 Push vs Pulll подходы и примеры использования
25:20 Доп. материал

Опубликовано:

7 май 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 16

@tihon4979 22 часа назад

Доступно. Понятно. Без воды. Лайк. Подписка.

@ivanstrelka3448 2 дня назад

Топ контент! Спасибо

@user-zs3tk1gn2x День назад

спасибо!!!

@prostoprosa 14 дней назад

Большое спасибо за видео. Понятно и доступно)

@nikolaykozlov4888 22 дня назад

Отличное представление информации. Просто огонь! Спасибо

@vladimir_v_it 11 дней назад

Классное видео! Спасибо!

@serb1146 11 дней назад

Спасибо.

@novmicha 8 дней назад

Про multi stage pipeline очень вскользь сказано, хотелось бы на конкретном примере. Например как организовать транзакцию когда идет целый ряд событий как результат одного. К примеру типовая ситуация: заказ от пользователя (оплата-пересчет остатков-информирование).

@digital_train 7 дней назад

Отличный вопрос, как раз разбирали его на теме про паттерны микросервисной архитектуры. Если коротко - транзакционность между микросервисами это дорого и сложно, но есть подходы к организации Тут пример ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-ViCD4ERj578.htmlsi=M7WRUakxvd6PIYtH 1. Event sourcing 2. Saga pattern

@jonkarmok1840 14 дней назад

Я правильно понимаю что у Rabbit должны быть ниже задержки, чем у Kafka?

@digital_train 13 дней назад

Если мы говорим на задержку на чтение и обработку сообщения то за счет структуры Kafka сообщение будет проходить быстрее, т.к. там по сути отсутствует умный роутинг и т.д. Но если наша задача выглядит как в зависимости от сложной логики раскидать сообщение по группам, с какими-нибудь полиси. То тут RabbitMQ будет быстрее так как в Kafka нет внутренних механизмов и все прийдется делать во внешнем сервисе, следовательно только передача сообщения между очередью и сервисом съест львиную долю времени Если суммировать, смотрите на ваш кейс_

@paemox 2 дня назад

Очереди сообщений не нужны практически никогда! Для этого есть обратный прокси и балансировщик nginx/Apache.

@digital_train День назад

Действительно в самых простых случая очередь можно заменить на реверс + LB Но это только часть функциональности, очереди так же: - Автоматически масштабируются при добавлении и удалении нод из кластера - Могут гарантировать транзакционность и использовать различные стратегии доставки - Часть из очередей могут использоваться в виде хранилища events в event-driven архитектуре - Так же поверх них удобно строить real-time стримы данных и событий и не переживать за то что какой-то из consumer упадет Важно посмотреть на кейс и уже после решать нужна ли очередь или нет

@paemox День назад

@@digital_train - Балансировщик тоже может добавлять и удалять ноды - Если пользователь не получает ответ в течении 30 секунд, то в большинстве случаев он перестает его ждать и уходит. Поэтому нет смысла накапливать сообщения в надежде когда-то там обработать все. - Событийная архитектура усложняет разработку, если система не помещается на сервер, то лучше использовать шардирование, а не разбиение на подсистемы, что связаны событиями. - После падения консюмеров забивается и падает очередь, что делает ее бессмысленной для спасения. Проще разруливать падение на клиенте путем повторных запросов.