Объяснения, примеры, анимации и сама структура этого и остальных видео дают четкое понимание темы Мне кажется посмотрев ваши видео нужно очень сильно постараться, чтоб не разобраться в данном направлении
Я не очень понял, как exchange знает что надо сообщение отправить по сути в две очереди (как пример error и all)? Или тут в примере указано что шлем сообщения по ключу, потом их кто-то (а их может быть бесконечногое количетсво) приходит и забирает, а когда у очереди нет подключенных consumer то очередь умирает вместе с сообщениями?
дада, всё верно шлём сообщенеи по ключу по поводу "Я не очень понял, как exchange знает..." - обменник имеет привязку (binding), посмотрите ещё раз с таймлайна 6:40
@@DevStoriesAndTutorials спасибо, можно еще пару вопросов: 1. Когда мы объявляем консьюмер мы обязательно должны ему через модель указать с какими именно exchange мы работаем и с какими очередями, я правильно понимаю? 2. Создал exchange с типом fanout, создаю очередь и привязываю ее к нему, отправляю в него сообщение без указания routingKey, сообщение попадает в эту очередь, но почему то не попадает в EventingBasicConsumer.. спасибо!
Да, когда объявляется Consumer - мы должны ему сказать, какую очередь он будет "слушать". Касаемо объявления очереди, а тем более обменника - такого нет в реальном мире. Consumer обычно ничего не знает о существовании Excange. Очередь он обычно так же не создаёт, а только получает её имя из переменных окружения. К моменту разработки функционала Consumera все остальные участники системы уже созданы и настроены (я про Exchange и Queue). В реальном приложении, если Consumer не смог подключиться к очереди, одним из правильных решений будет бросить Exception с сообщением о том, что не удалось связаться с очередью. В данном примере я делаю оговорку о том, что мы точно не знаем, какое приложение сейчас стартанёт первым, для этого создаём и обменник, и очереди внутри Consumer'a. Иначе будет падать через раз)
@@DevStoriesAndTutorials спасибо за развернутый ответ, обнаружил интересную особенность, если мы в consumer объявляем очередь через QueueDeclare (или несколько очередей подряд), то при вызове model.BasicConsume можем не указывать очередь, а просто передать пустую строку, возмется последняя объявленная. А вот если не объявляем очередь и передаем пустую строку в BasicConsume тут уже возникает исключение. Интересно, методы получается асинхронные и ни как не блокируют основой поток, а если необходимо подписаться на успех отправки или получения? Типа как observable.send().subscribe(() => { ... });
Очень крутой контент! Спасибо за проделанную работу!
За примеры на C# вообще отдельная благодарность!
Отличные видео по RabbitMQ! Спасибо!
Доку читать дело полезное, но объяснения от опытного пользователя брокера - бесценны)
Спасибо!
Очень понятное объяснение и особенно анимации, мы примерно, так логику себе и представляем, но тут это хорошо визуализированно. Спасибо
Спасибо за отзыв! Приятно!)
Спасибо! Пришлось читать все на английском и разбираться. Жаль, что раньше не нашла этот канал
Объяснения, примеры, анимации и сама структура этого и остальных видео дают четкое понимание темы
Мне кажется посмотрев ваши видео нужно очень сильно постараться, чтоб не разобраться в данном направлении
Спасибо!)
Дякую, дуже круто❤️❤️❤️
Прям так вовремя... Спасибо! :D
Вот только недавно началась практика по этой теме
Рад помочь)
Все мега понятно, спасибо!
Спасибо за понятный материал
Спасибо за отзыв! Приятно!)
Привет, спасибо за уроки !
А как могу как администратор узнать ip publisher?
Отличное объяснение!
Спасибо, приятно!
Спасибо!
🤟
👍👍👍
Спасибо
🤝
красавчик) всё круто
Я таки недогнал зачем мы в консьюмере опять объявляем обменик если по логике он должен быть уже настроен и нам надо читать сообщения из очереди.
Я не очень понял, как exchange знает что надо сообщение отправить по сути в две очереди (как пример error и all)?
Или тут в примере указано что шлем сообщения по ключу, потом их кто-то (а их может быть бесконечногое количетсво) приходит и забирает, а когда у очереди нет подключенных consumer то очередь умирает вместе с сообщениями?
дада, всё верно
шлём сообщенеи по ключу
по поводу "Я не очень понял, как exchange знает..." - обменник имеет привязку (binding), посмотрите ещё раз с таймлайна 6:40
@@DevStoriesAndTutorials отдельно спасибо за тайминг, теперь понятнее
при вызове QueueDeclare без указания имени у нас автоматически создается какая то очередь что ли? с каким то дефолтным названием?
Да, создается очередь с параметрами по умолчанию. Имя очереди сгенерирует для нас сервер.
@@DevStoriesAndTutorials спасибо, можно еще пару вопросов: 1. Когда мы объявляем консьюмер мы обязательно должны ему через модель указать с какими именно exchange мы работаем и с какими очередями, я правильно понимаю?
2. Создал exchange с типом fanout, создаю очередь и привязываю ее к нему, отправляю в него сообщение без указания routingKey, сообщение попадает в эту очередь, но почему то не попадает в EventingBasicConsumer..
спасибо!
Да, когда объявляется Consumer - мы должны ему сказать, какую очередь он будет "слушать".
Касаемо объявления очереди, а тем более обменника - такого нет в реальном мире. Consumer обычно ничего не знает о существовании Excange. Очередь он обычно так же не создаёт, а только получает её имя из переменных окружения. К моменту разработки функционала Consumera все остальные участники системы уже созданы и настроены (я про Exchange и Queue). В реальном приложении, если Consumer не смог подключиться к очереди, одним из правильных решений будет бросить Exception с сообщением о том, что не удалось связаться с очередью.
В данном примере я делаю оговорку о том, что мы точно не знаем, какое приложение сейчас стартанёт первым, для этого создаём и обменник, и очереди внутри Consumer'a. Иначе будет падать через раз)
@@DevStoriesAndTutorials спасибо за развернутый ответ, обнаружил интересную особенность, если мы в consumer объявляем очередь через QueueDeclare (или несколько очередей подряд), то при вызове model.BasicConsume можем не указывать очередь, а просто передать пустую строку, возмется последняя объявленная. А вот если не объявляем очередь и передаем пустую строку в BasicConsume тут уже возникает исключение. Интересно, методы получается асинхронные и ни как не блокируют основой поток, а если необходимо подписаться на успех отправки или получения? Типа как observable.send().subscribe(() => { ... });