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