Почему я должен использовать JMS, а не RMI + Queue?
В настоящее время я использую библиотеку RMI или гессиана для связи между моим сервером и клиентами (через LinkedBlockingQueue). Сейчас я читаю о JMS , который можно использовать и в этой области. Это правильно? Если да, не могли бы вы дать мне простой список преимуществ / недостатков, потому что это, кажется, довольно сложное и «полноценное предприятие».
Каковы преимущества? А как насчет производительности по сравнению с RMI + Queue? Может ли JMS превзойти очередь RMI +?
PS: Я знаю, что есть подобные вопросы , но я хотел бы иметь JMS по сравнению с RMI + Queue.
4 ответа
Упрощенное сравнение (не только для JMS, больше похоже на сравнение с MQ в целом) ...
Автоматическая повторная попытка
Если вы являетесь клиентом, выполняющим RMI для сервера, и по какой-то причине RMI не работает, вам придется попробовать еще раз самостоятельно. Если вы будете использовать JMS и являетесь клиентом, вы просто отправите сообщение JMS. Когда сервер недоступен, ваше сообщение будет сохранено, а затем доставлено, когда сервер снова заработает.Постоянная очередь
Поскольку вы используете LinkedBlockingQueue, у вас может быть либо ограниченная очередь, либо неограниченная очередь в памяти. Первый начнет перехватывать потоки после заполнения очереди и, в конечном итоге, выйдет из строя при высокой нагрузке. Последний в конечном итоге вместо этого выбрасывал OutOfMemoryError. Однако, если вы будете использовать JMS, он может автоматически начать «сохранять» сообщения в «постоянном хранилище». Обычно «постоянное хранилище» - это БД, которая обычно имеет гораздо большую емкость, чем очередь в памяти. Конечно, содержимое очереди в памяти теряется, когда сервер выходит из строя и т. Д., Тогда как в JMS вы можете выбрать устойчивое сообщение / постоянное сообщение, которое переживает такое событие. Это также позволяет использовать кластеризацию, что также очень важно для корпоративных программ ...Абстракция
Вы будете использовать стандартизированный API (хорошо, у вас тоже есть протоколы в RMI, но если вы хотите передавать сообщения, MQ обеспечивает гораздо более высокоуровневую абстракцию, чем очередь RMI + в памяти). Это означает, что вы сможете использовать будущие реализации JMS. стоячие. По сути, более высокая абстракция может дать вам гибкость, в отличие от очереди в памяти RMI +.
Некоторое время назад я работал с большой компанией, которая хотела использовать свою внутреннюю структуру для интеграции наших материалов. В то время мы не использовали MQ. Мы попросили их использовать наш собственный асинхронный протокол на основе RMI.Поверьте, мы очень и очень сожалели об этом решении ...
Другие ответы охватывают многие аспекты JMS, но я чувствую, что один очень важный аспект требует большего внимания, а именно тот факт, что JMS поддерживает множество одновременных потребителей транзакционным способом. Для меня это главная особенность.
- Вы можете легко построить систему с одним потребителем и производителем, которая не является транзакционной.
- Вы также можете сделать ее (более или менее) транзакционной, приложив немного больше усилий.
- Аналогично, вы можете добавить поддержку нескольких производителей и одного потребителя относительно легко, например, если вы используете транзакционную базу данных для хранения сообщения.
- Но становится очень трудно иметь несколько одновременных потребителей и добиться того, чтобы потребление сообщений было транзакционным. Для этого в основном требуется нетривиальная схема блокировки, и даже при использовании транзакционной базы данных эта задача не является простой.
Когда мы говорим о масштабируемости JMS, мы, однако, имеем в виду следующее: способность сервера приложений добавлять/удалять потребителей/производителей для управления нагрузкой.
Другие преимущества JMS - качество обслуживания и управление, например, попытка повторной доставки, мертвая очередь сообщений, мониторинг и т.д.
Если вам это не очень нужно, может подойти несколько более простое решение. Вы также можете посмотреть другой мой ответ, где я рассматриваю похожий вопрос: Почему стоит выбрать JMS для асинхронного решения?
Что вы используете для части «Очередь» вашего решения? Ваш собственный код?
JMS - это просто API над системой очередей какого-то поставщика, но тот, который включает аспекты удаленного взаимодействия. Таким образом, с точки зрения клиента вы просто помещаете сообщение в очередь (или тему, если вы выполняете подписку на публикацию) и забываете об этом. Инфраструктура доставляет его слушателям.
Я вижу большую силу JMS в качестве реализации инфраструктуры очередей, а не в самом API, это довольно просто.
Простой RMI плохо масштабируется и не решает проблем с надежностью, хорошая система очередей может быть как масштабируемой, так и отказоустойчивой.
Я думаю, будет справедливо сказать, что JMS и остальная часть Java EE предназначены для того, чтобы ваше приложение было корпоративного качества. Изначально я думал, что Java EE в целом была сложной, хотя я думал, что JMS - один из самых простых вариантов. Сегодня я не уверен, что написать RMI + собственную очередь проще, чем просто использовать JMS.
Возможно, существенная разница в том, что использование JMS в значительной степени предполагает наличие некоторой инфраструктуры, такой как сервер приложений.
JMS является транзакционным, может быть скоординирован с транзакциями базы данных.
JMS разделяет производителей и потребителей, то есть они не должны работать одновременно.
JMS имеет гарантированную доставку, то есть сообщения гарантированно дойдут до адресата в случае сбоя (в зависимости от типа сбоя может потребоваться кластеризация).
JMS может выполнять синхронную, асинхронную передачу от точки к точке, а также публикацию/подписку.
Большинство реализаций JMS используют систему очередей, которая может работать с другими языками и ОС.