Встроенный ActiveMQ в мультиэкземплярном сервисе с использованием KahaDB для надежного обмена сообщениями
Это странный вопрос, и я бы даже не предложил его, если бы работа делала это "правильным образом" (ТМ). У меня есть служба, которая, скорее всего, будет развернута с несколькими экземплярами, которая очень хорошо подходит и должна иметь свои данные, подаваемые через какую-то очередь сообщений.
Мне нужны надежные сообщения, поскольку данные должны использоваться, и любой конкретный экземпляр может быть перезапущен во время обработки рабочей нагрузки. Так как мне мешают поставить правильный экземпляр RabbitMQ или что-то подобное, мне было интересно, что делать. Тогда я столкнулся со встроенным ActiveMQ.
Это, кажется, соответствует потребности. Из-за того факта, что "полномочия" не позволяют мне выставить правильный MQ для этого, я подумал, что это хороший подход, а не копирование вещей, стоящих в очереди и длительных сообщений. Они не будут такими хорошими, как я предполагаю. Дело в том, что запросы, которые будут публиковаться во встроенной очереди, поступают через набор циклических перегрузок с балансировкой нагрузки. Итак, я не знаю, какой экземпляр получит запрос на публикацию в любой момент, хотя это не похоже на экземпляр, который запускается, поскольку ведомый получит какие-либо сообщения, все еще пытаясь это выяснить.
Я выбрал KahaDB для настойчивости, так как реализация JDBC все еще говорит "Экспериментально", и я продолжаю видеть сообщения о низкой производительности.
Вопрос в том, как с этим справиться? Если я запускаю несколько экземпляров сервиса с использованием Kaha, первый запускается и начинает обрабатывать все ожидающие сообщения, но запуск другого переводит его в "подчиненный режим". Это приложение с весенней загрузкой, и запуск приостанавливается, как только новый экземпляр обнаруживает наличие файла блокировки. Я еще не пробовал, но не похоже, чтобы он регистрировался в Eureka как клиент, так как запуск останавливается рано, приостанавливая снятие блокировки.
Идеальным сценарием было использование нескольких экземпляров, которые могли бы принимать запросы и направлять их через встроенного брокера и обрабатывать их, как могут. Блокировка создает проблему там. Есть ли способ справиться с этим по-другому?
Одна потенциальная работа вокруг, которую я предложил, которая работала бы, но я не знаю, нравится ли мне это, это. При запуске у меня конфигурация ActiveMQ проверяет удаленное хранилище в каталоге. Если этот каталог имеет блокировку, я ищу любые каталоги, в которых есть данные KahaDB, которые не заблокированы, и назначаю их в качестве места сохранения. Если их нет, я создаю новый и начинаю там. Это позволило бы получать сообщения в любом предыдущем хранилище, которое было закрыто активной очередью, но я беспокоюсь, что со временем это может привести к потере данных.
Есть ли лучший способ использовать встроенный Active MQ, а также иметь надежные сообщения в переходной облачной среде? Я как бы подумал, смогу ли я выставить очередь одного экземпляра через TCP, тогда все получится из этого, но мне кажется, что было бы сложно указать моему весеннему загрузочному приложению, что если оно находит очередь, чтобы не запускать свою собственную встроенную очередь,