Имеет ли смысл использовать очереди сообщений в нераспределенном приложении

Поэтому я планирую написать приложение, которое хорошо подходит для шаблона производитель/потребитель. Я думал о создании собственной структуры производителя/потребителя, но затем подумал об очередях сообщений, которые я широко использую в работе. Я не уверен на 100%, что очередь сообщений будет правильным подходом, учитывая, что несколько модулей приложения, которое я пишу, должны работать на одном сервере, поскольку это своего рода клиент/контроллер для этого конкретного хоста.

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

Спасибо, дайте мне знать, если вам нужна дополнительная информация.


person Chinmay Samant    schedule 04.09.2013    source источник
comment
Очереди сообщений обеспечивают постоянство в случае сбоя. Это важно?   -  person Thorbjørn Ravn Andersen    schedule 04.09.2013


Ответы (1)


Под «очередями сообщений» вы подразумеваете внешний сервер сообщений? Мой ответ ниже предполагает, что это то, о чем вы говорили. Если вы просто спрашиваете о более общем архитектурном подходе, когда модули взаимодействуют частично или полностью через сообщения в памяти вместо вызовов методов - да, иногда это может быть очень приятно. Такие классы, как EvenBus в guava, прекрасно упрощают такой дизайн: https://code.google.com/p/guava-libraries/wiki/EventBusExplained

С одной стороны, я обычно стараюсь отговаривать людей от использования очередей сообщений JMS, когда достаточно простой структуры данных очереди. Иногда мне кажется, что JMS — это инструмент межпроцессного взаимодействия, в котором есть каналы связи «один-ко-многим» (темы) и «один-к-одному», которые называются очередями. Да, их схема доступа аналогична схеме очереди, но мне кажется, что более важной характеристикой является их возможность обмена сообщениями точка-точка. Так что неудачное имя, которое, я думаю, иногда заставляет людей использовать отбойный молоток (JMS), когда все, что им нужно, это отвертка (java.lang.Queue).

С другой стороны, из любого правила есть исключения. Я не могу сразу порекомендовать реализацию java.lang.Queue, которая является потокобезопасной и сохраняется во время перезапуска сервера (часто необходимая функция, когда люди рассматривают JMS). Я уверен, что есть. Найдите несколько и сравните их с JMS. Взвесьте бизнес-потребности, временные ограничения, возможный будущий дизайн/требования и т. д. Я реализовал один из них раньше, и он оказался довольно хорошим (и был быстрее, чем отправка сообщений по сети на удаленный сервер JMS) - но только вы можете сказать если это подходит для вашей ситуации.

Я полагаю, что вы всегда можете отложить принятие решения, заставив модули вашего приложения обмениваться данными через собственный интерфейс, похожий на обмен сообщениями, который пока использует java.lang.Queues внутри, но JMS позже, если вы обнаружите, что вам нужно это. Хотя и здесь будьте осторожны — раннее добавление ненужной абстракции иногда оказывается бременем, которое того не стоит.

person Keith    schedule 04.09.2013
comment
Спасибо за подробный ответ. Я больше думал об архитектурном подходе модулей, обменивающихся сообщениями в памяти. Полностью согласен с тем, что JMS будет отбойным молотком, и я взглянул на EventBus и думаю, что его стоит изучить. - person Chinmay Samant; 05.09.2013