Автор харизматичный, рассказывает хорошо. Вопросы из зала повторяет в микрофон, редко кто из докладчиков додумывается до такой, казалось бы, очевидной мысли. Пожелаю ему удачи! Теперь вопрос. На 79м слайде Андрей предлагает сделать длину буфера равной 1, при этом утверждает, что AMQ возбуждается на половину буфера. При таком решении всегда кто-то будет ждать: либо получатель, либо отправитель. Если же сделать длину равной 2, то пока получатель читает вторую ячейку, отправитель сможет заполнять первую. Может я что-то не понял, или у нас задача замедлить слишком быструю систему?
Спасибо за видео. Получается, что при таком горизонтальном масштабировании всю нагрузку(кол-во сообщений) распределяет все равно лишь один узел брокера, скидывая сообщения в такую же очередь другого брокера. Нет такого компонента, который был выполнял функции балансировщика, распределяя сообщения между экземплярами брокеров ActiveMQ по определенным правилам, в зависимости, например, от доступности/загрузки? Или все же есть такие решения, и про них просто не говорилось здесь?
Про такие решения говорилось ;) ровно одно предложение. Он сказал, что некоторые разработчики переходят на kafka. Activemq не предназначен для горизонтального масштабирования. Производительность снижается с каждым новым клиентом, т.к. для всех очередей используется один общий журнал, разделяемый всеми пишущими и читающими потоками. Если сообщения персистентные, то в момент получения брокером каждое сообщение должно быть записано на энергонезависимый диск.
Сервис A передает данные в сервис Б. В сервисе Б нельзя организовать подписку(некое облачное решение сторонних производителей которое не программируется). Однако имеет REST API на входящие запросы. Можно ли используя данный брокер сообщений за ставить его передавать сообщения на этот RESP API? Или же обязательно использовать подписку?
Заставить ActiveMQ самостоятельно выгружать сообщений из очереди/топика, передавая их сервису REST API, не получится. Но можно, например, использовать промежуточный компонент, например, Apache Camel или несложное Spring Boot приложение на базе camel-spring-boot-starter, в котором будет производиться вычитывание сообщения из очереди и отправка его на нужный сервис из REST API.
Шикарная лекция, большое спасибо.
Особенно доставила тема презентации и футболка в тему презентации :-)
Супер полезная лекция. Спасибо!
Крутая презентация, спасибо!)
С душой сделал, супер). Спасибо ❤️
Автор харизматичный, рассказывает хорошо. Вопросы из зала повторяет в микрофон, редко кто из докладчиков додумывается до такой, казалось бы, очевидной мысли. Пожелаю ему удачи!
Теперь вопрос. На 79м слайде Андрей предлагает сделать длину буфера равной 1, при этом утверждает, что AMQ возбуждается на половину буфера. При таком решении всегда кто-то будет ждать: либо получатель, либо отправитель. Если же сделать длину равной 2, то пока получатель читает вторую ячейку, отправитель сможет заполнять первую. Может я что-то не понял, или у нас задача замедлить слишком быструю систему?
Просто топ
Спасибо за видео. Получается, что при таком горизонтальном масштабировании всю нагрузку(кол-во сообщений) распределяет все равно лишь один узел брокера, скидывая сообщения в такую же очередь другого брокера. Нет такого компонента, который был выполнял функции балансировщика, распределяя сообщения между экземплярами брокеров ActiveMQ по определенным правилам, в зависимости, например, от доступности/загрузки? Или все же есть такие решения, и про них просто не говорилось здесь?
Про такие решения говорилось ;) ровно одно предложение. Он сказал, что некоторые разработчики переходят на kafka. Activemq не предназначен для горизонтального масштабирования. Производительность снижается с каждым новым клиентом, т.к. для всех очередей используется один общий журнал, разделяемый всеми пишущими и читающими потоками. Если сообщения персистентные, то в момент получения брокером каждое сообщение должно быть записано на энергонезависимый диск.
@@Pan-ux3bq спасибо за ответ.
Сервис A передает данные в сервис Б. В сервисе Б нельзя организовать подписку(некое облачное решение сторонних производителей которое не программируется). Однако имеет REST API на входящие запросы. Можно ли используя данный брокер сообщений за ставить его передавать сообщения на этот RESP API? Или же обязательно использовать подписку?
Заставить ActiveMQ самостоятельно выгружать сообщений из очереди/топика, передавая их сервису REST API, не получится. Но можно, например, использовать промежуточный компонент, например, Apache Camel или несложное Spring Boot приложение на базе camel-spring-boot-starter, в котором будет производиться вычитывание сообщения из очереди и отправка его на нужный сервис из REST API.
@@peneksglazami Спасибо за ответ, очень помогли)
@@user-hy8kc7ht7v Вот пример подобного Spring Boot приложения github.com/peneksglazami/activemq-camel-rest-example