Одна очередь JMS с несколькими потребителями

Question

У меня есть приложение Oracle Commerce, которое потребляет сообщения в одной очереди JMS. У меня есть десять потребителей с одинаковой очередью назначения. Я хотел бы понять плюсы и минусы этой архитектуры и как ее оптимизировать.

Answer 1

Я просто хочу сказать, что этот вопрос не имеет особого отношения к Oracle Commerce и об общих принципах реализации очередей.

Если у вас одна очередь и много потребителей, помните, что все они будут пытаться обрабатывать сообщения одновременно. Это может быть нежелательным для некоторых ситуаций, если порядок обработки сообщений важен или есть зависимые сообщения, которые необходимо обработать до обработки текущего сообщения. Даже при этом существуют шаблоны, которые могут возвращать сообщения в очередь для последующей обработки для достижения зависимой обработки сообщений.

Обработка исключений - еще один сложный вопрос, когда у вас много потребителей. Убедитесь, что вся обработка сообщений имеет хорошую обработку исключений и откладывает сообщение обратно в очередь (путем исключения исключений) для последующей обработки. Кроме того, если есть сообщение, которое может застрять обработку, потому что оно будет генерировать каждый раз, когда вы захотите поместить их в другую очередь, после стольких исключений. В свое время мы создали платформу обработки исключений, которая помогала во всех этих сценариях.

Если вы действительно хотите просто передать сообщение многим потребителям по теме, используйте архитектуру pub-sub, и это намного проще в обращении.

Опять же, как и в других комментариях, сценарий того, что вы пытаетесь сделать, поможет обеспечить хорошее направление.

Вот дискуссия, которая может дополнительно помочь с вопросом - http://c2.com/cgi/wiki?MessageQueuingArchitectures

Answer 2

когда потребители разделяют нагрузку он является общим, что они разделяют очередь. , иначе было бы лучше создать отдельную очередь для каждого потребителя.

, если вы хотите транслировать bij, помещая сообщение на tippic, чем есть возможность создать мост для каждого потребителя.

под этим я подразумеваю мост от верхнего уровня до потребительской очереди. Про за использование моста состоит в том, что сообщения te остаются в очереди (als long als сообщение не истекает), когда потребительский процесс не работает на короткий период.