JMS Queue Split. Интеграция предприятий. Apache Camel

Question

У меня есть стороннее приложение, которое помещает некоторые сообщения в очередь JMS. Также у меня есть приложение, которое считывает сообщения из этой очереди. В зависимости от типа сообщения я сохраняю это сообщение в БД или отправляю его в стороннюю службу. Кроме того, мы не должны превышать ограничение фиксированных вызовов в секунду, чтобы не перегружать стороннюю сторону.

В настоящее время для моего использования используются два решения.

Первый - попросить третью сторону отправить некоторые пользовательские заголовки, чтобы потребитель JMS мог фильтровать сообщения с помощью JMS Selectors. Таким образом, в этом случае мы сможем создать двух потребителей, первый из них сможет читать сообщения и сохранять их в БД, а второй будет использовать механизм дросселирования/опроса для отправки сообщений третьей стороне при определенной нагрузке , Но этот подход не будет работать для меня, потому что для добавления этих пользовательских заголовков потребуется третье лицо. Нечто подобное в Camel:

from("jms:queue?selector=firstSelector") 
    .bean(dbSaver); 

from("jms:queue?selector=secondSelector") 
    .throttle(10) 
    .bean(httpClient); 

Второй заключается в создании еще двух JMS Очереди и процессор, который будет разделить сообщения между этими очередями. Затем идет та же логика, что и в первом решении. Однако это означает, что необходимо добавить 2 дополнительных JMS-очереди. In Camel:

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.

Answer 1

1. Вам действительно нужна очередь для потока в БД? Вы могли бы использовать bean (dbSaver) на первом маршруте или абстрагировать его на «прямой» маршрут вместо маршрута, использующего jms. Таким образом, у вас есть две очереди вместо трех.

2. Второй подход. Если у вас есть контроль над БД, вы можете написать второй тип сообщения в другую таблицу. Затем sql-потребитель может опросить записи и удалить их, поскольку он их потребляет, и передает их на http-службу. Тем не менее, таблица действует как «сворачивает свой собственный Q». Вероятно, больше работы для небольшой окупаемости, так что, может быть, вторая очередь лучше.

3. Наконец, мне интересно, можете ли вы повторно использовать одну и ту же очередь. Я вижу вариант, который позволит вам записать обратно в ту же очередь. Вы можете добавить заголовок и написать определенное сообщение. Это может показаться запутанным, и ошибка может создать бесконечный цикл.

Если вы уже используете JPA, это можно сделать немного проще с помощью компонента camel-jpa. Как потребитель, он действует, читает и удаляет записи (поведение по умолчанию). Я не думаю, что компоненты SQL/JDBC имеют что-то подобное из коробки.