У меня есть стороннее приложение, которое помещает некоторые сообщения в очередь JMS. Также у меня есть приложение, которое читает сообщения из этой очереди. В зависимости от типа сообщения я сохраняю это сообщение в БД или отправляю в сторонний сервис. Также мы не должны превышать фиксированный лимит звонков в секунду, чтобы не перегружать сторонних.
В настоящее время мне пришло в голову два решения для этого варианта использования.
Первый - попросить третью сторону отправить некоторые настраиваемые заголовки, чтобы потребитель JMS мог фильтровать сообщения с помощью селекторов JMS. Итак, в этом случае мы сможем создать двух потребителей, первый сможет читать сообщения и сохранять их в БД, а второй будет использовать некоторый механизм дросселирования / опроса для отправки сообщений третьей стороне при определенной нагрузке. . Но этот подход не сработает для меня, потому что третьим лицам потребуется много времени, чтобы добавить эти настраиваемые заголовки. Что-то вроде этого в Camel:
from("jms:queue?selector=firstSelector")
.bean(dbSaver);
from("jms:queue?selector=secondSelector")
.throttle(10)
.bean(httpClient);
Второй - создать еще две очереди JMS и процессор, который будет разделять сообщения между этими очередями. Далее следует та же логика, что и в первом решении. Однако это означает, что необходимо добавить 2 дополнительные очереди JMS. В верблюде:
from("jms:parentQueue")
.choice()
.when(body().contains(...))
.to("jms:fistChildQueue")
.otherwise()
.to("jms:secondChildQueue")
.end()
from("jms:fistChildQueue")
.bean(dbSaver);
from("jms:secondChildQueue")
.throttle(10)
.bean(httpClient);
Кроме того, я думал об использовании двух очередей в памяти вместо очередей JMS. Однако в этом случае при большом количестве сообщений в очереди JMS легко могут возникнуть проблемы с памятью.
Может ли кто-нибудь предложить архитектурный дизайн для этого варианта использования? Было бы здорово увидеть его в стиле Camel Route.
