Ordinary Queue vs SEDA Queue

Question

Будучи новым для Apache Camel, я недавно просмотрел его длинный список компонентов и наткнулся на их поддержку для компонентов SEDA queue.

Эта страница не имеет для меня большого смысла, поэтому я сделал пару онлайн-запросов для термина «SEDA queue» и получил статью о википедии here.

После прочтения этой статьи я не могу сказать, какая разница между очередью SEDA и обычной «обычной» очередью! Оба охватывают понятие систем развязки посредством использования асинхронных очередей.

Из статьи «SEDA» просто звучит как архитектура, состоящая из размещения очереди между каждым компонентом. Это верно?

Но если это просто архитектура, то почему в очереди «SEDA» есть специальный компонент Apache Camel?

Answer 1

Очереди SEDA - это как обычная очередь (и, как сказал Питер выше, в Camel у них есть пул потоков, связанный с ними как часть компонента). SEDA - это архитектура. Компонент SEDA в Camel использует очереди в памяти в вашем процессе и представляет собой отдельный компонент, чтобы отличать их от другого компонента очереди в верблюде Apache, а именно компонента JMS.

Answer 2

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

Answer 3

SEDA является аббревиатурой, которая расшифровывается как Staged Event Управляемая архитектура разработана как механизм для регулирования потока между различными этапами обработки сообщений. Идея состоит в том, чтобы сгладить частоту вывода сообщений из общего процесса, чтобы он соответствовал входу. Он позволяет потребительским потокам enpoint выгружать работу длительных операций в bakground, тем самым освобождая их от потребления сообщений от транспорта. Когда обмен передается в seda: endpoint, он помещается в BlockingQueue. Список существует в контексте верблюда, что означает, что только те маршруты, которые находятся в одном контексте, могут быть соединены этим типом конечной точки. Очередь по умолчанию не ограничена, хотя ее можно изменить, установив атрибут размера в URI потребителя.

По умолчанию один поток, назначенный конечной точке, считывает обмены из списка и обрабатывает их по маршруту. Как видно из примера процедуры, можно увеличить количество concurrenctConsumers, чтобы обеспечить своевременную обработку обменов из этого списка.

Шаблон SEDA лучше всего подходит для обработки сообщений InOnly, где один маршрут завершает обработку и передает руки другому, чтобы иметь дело со следующей фазой. можно запросить ответ от seda: endpoint, вызвав его, когда шаблон обмена сообщениями является InOut

Ссылка. Поваренная книга разработчика Apache Camel