для чего нужен JMS?[закрыто]
https://stackoverflow.com/questions/222017
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я ищу (простые) примеры проблем, для которых JMS является хорошим решением, а также причины, по которым JMS является хорошим решением в этих случаях.Раньше я просто использовал базу данных как средство передачи сообщений от A к B, когда сообщение не обязательно было немедленно обработано B.
Гипотетическим примером такой системы является то, что всем вновь зарегистрированным пользователям должно быть отправлено приветственное электронное письмо в течение 24 часов после регистрации.В качестве аргумента предположим, что БД не записывает время регистрации каждого пользователя, а вместо этого ссылка (внешний ключ) на каждого нового пользователя сохраняется в таблице pending_email.Задание отправителя электронной почты запускается раз в 24 часа, отправляет электронное письмо всем пользователям в этой таблице, а затем удаляет все записи pending_email.
Это похоже на проблему, для решения которой следует использовать JMS, но мне неясно, какие преимущества JMS будет иметь по сравнению с описанным мной подходом.Одним из преимуществ подхода БД является то, что сообщения являются постоянными.Я понимаю, что очереди сообщений JMS также могут сохраняться, но в этом случае, похоже, есть небольшая разница между JMS и подходом «база данных как очередь сообщений», который я описал?
Что мне не хватает?- Дон
Решение
JMS и обмен сообщениями — это на самом деле две совершенно разные вещи.
- опубликовать и подписаться (отправка сообщения как можно большему числу заинтересованных потребителей — это немного похоже на отправку электронного письма в список рассылки, отправителю не нужно знать, кто подписан
- высокая производительность и надежная балансировка нагрузки (очереди сообщений)
Дополнительную информацию смотрите на сравнение очереди с темой
Случай, о котором вы говорите, — это второй случай, когда да, вы можете использовать таблицу базы данных для имитации очереди сообщений.
Основное отличие заключается в том, что очередь сообщений JMS представляет собой высокопроизводительный высокопараллельный балансировщик нагрузки, рассчитанный на огромную пропускную способность;обычно вы можете отправлять десятки тысяч сообщений в секунду множеству одновременных потребителей во многих процессах и потоках.Причина этого в том, что очередь сообщений по своей сути очень асинхронна. хороший провайдер JMS заранее будет передавать сообщения каждому потребителю так что в оперативной памяти будут доступны тысячи сообщений для обработки, как только появится потребитель.Это приводит к огромной пропускной способности и очень низкой задержке.
напримерпредставьте себе, что вы пишете балансировщик веб-загрузки с использованием таблицы базы данных :)
При использовании таблицы базы данных обычно один поток имеет тенденцию блокировать всю таблицу, поэтому при попытке реализовать высокопроизводительный балансировщик нагрузки вы, как правило, получаете очень низкую пропускную способность.
Но, как и в случае с большинством промежуточного программного обеспечения, все зависит от того, что вам нужно;если у вас система с низкой пропускной способностью и всего несколькими сообщениями в секунду — не стесняйтесь использовать таблицу базы данных в качестве очереди.Но если вам нужна низкая задержка и высокая пропускная способность — тогда настоятельно рекомендуется использовать очереди JMS.
Другие советы
По моему мнению, JMS и другие системы на основе сообщений предназначены для решения проблем, которые требуют:
- Асинхронный коммуникации:Приложению необходимо уведомить другое о том, что произошло событие, без необходимости ждать ответа.
- Надежность.Обеспечьте однократную доставку сообщений.При использовании вашего подхода к БД вам придется «изобретать велосипед», особенно если у вас есть несколько клиентов, читающих сообщения.
- Слабая связь.Не все системы могут взаимодействовать с использованием базы данных.Таким образом, JMS очень удобен для использования в гетерогенных средах с разделенными системами, которые могут взаимодействовать через границы системы.
Реализация JMS - это «push», в том смысле, что вам не нужно опрашивать очередь, чтобы обнаружить новые сообщения, но вы регистрируете обратный вызов, который вызывается, как только приходит новое сообщение.
для адресации исходного комментария. первоначально было описано суть (точка-точка) JMS. однако преимущества JMS:
<Ол>вам не нужно самим писать код (и, возможно, испортить логику, чтобы он не был столь же постоянным, как вы думаете). Кроме того, сторонний impl может быть более масштабируемым, чем простой подход к базе данных.
jms обрабатывает публикацию / подписку, что немного сложнее, чем приведенный вами пример «точка-точка»
вы не привязаны к конкретной реализации и можете поменять ее, если ваши потребности изменятся в будущем, без проблем с вашим Java-кодом.
Одним из преимуществ JMS является возможность асинхронной обработки, которая также может выполняться с помощью решения для базы данных. Однако ниже приведены некоторые другие преимущества JMS по сравнению с решением для баз данных.
а) Получатель сообщения может находиться в удаленном месте. Разоблачение базы данных для удаленного доступа опасно. Вы можете обойти это, предоставив дополнительный сервис для чтения сообщений из базы данных, который требует больше усилий.
b) В случае базы данных потребитель сообщения должен опросить базу данных на наличие сообщений, когда JMS обеспечивает обратный вызов при получении сообщения (как упоминалось выше)
в) Распределение нагрузки - если поступает много сообщений, легко иметь пул обработчиков сообщений в JMS.
d) В целом реализация через JMS будет проще и потребует меньше усилий, чем маршрут базы данных
JMS - это API, используемый для передачи сообщений между двумя или более клиентами. Его спецификации определены в JSR 914.
Основным преимуществом JMS является разобщенная природа взаимодействующих объектов - отправителю не нужно иметь информацию о получателях. Другие преимущества включают возможность интеграции разнородных платформ, устранения узких мест в системе, повышения масштабируемости и более быстрого реагирования на изменения.
JMS - это просто своего рода интерфейсы / API, и конкретные классы должны быть реализованы. Они уже реализованы различными организациями / провайдерами. они называются провайдерами JMS. Примером может служить WebSphere от IBM или FioranoMQ от Fiorano Softwares или ActiveMQ от Apache, HornetQ, OpenMQ и т. д. Другие используемые термины: объекты администрирования (темы, очереди, ConnectionFactories), производитель / издатель JMS, клиент JMS и само сообщение.
Итак, переходим к вашему вопросу - для чего нужен JMS?
Я хотел бы привести практический пример, чтобы проиллюстрировать его важность.
Дневная торговля
Эта функция называется LVC (кэш последнего значения)
В торгах цены акций публикуются издателем через регулярные промежутки времени. Каждая акция имеет связанную тему, в которой она опубликована. Теперь, если вы знаете, что такое тема, вы должны знать, что сообщения не сохраняются как очереди. Сообщения публикуются подписчикам живыми на момент публикации сообщения (за исключением подписчиков Durables, которые получают все сообщения, опубликованные с момента его создания, но опять же мы не хотим получать слишком старые цены на акции, которые исключают возможность используй это). Поэтому, если клиент хочет узнать цену акций, он создает подписчика, а затем ему приходится ждать публикации следующей цены акций (что опять-таки не то, что мы хотим). Это где LVC входит в картину. Каждое сообщение LVC имеет связанный ключ. Если сообщения отправляются с ключом LVC (для определенного запаса), а затем с другим сообщением об обновлении с тем же ключом, то он переопределяет предыдущее. Когда подписчик подписывается на тему (для которой включен LVC), подписчик получает все сообщения с разными ключами LVC. Если мы сохраняем отдельный ключ для каждой из перечисленных компаний, тогда, когда клиент подписывается на него, он получает самую последнюю цену акций и, в конечном итоге, все обновления.
Конечно, это один из факторов, помимо надежности, безопасности и т. д., который делает JMS такой мощной.
Гвидо имеет полное определение. По моему опыту все это важно для хорошей подгонки.
Я видел одно из применений для распределения заказов на складах. Представьте себе компанию канцелярских товаров, имеющую достаточное количество складов, которые снабжают большие офисы канцелярскими товарами. Эти заказы поступят в центральное место, а затем будут упакованы для правильного распределения. Склады не имеют или не хотят высокоскоростных соединений в большинстве случаев, поэтому заказы передаются к ним через модемы удаленного доступа, и именно здесь происходит асинхронность. Телефонные линии на самом деле не так важны, так что половина заказов может поступить и это где надежность важна.
Ключевым преимуществом является разделение несвязанных систем, а не их совместное использование общих баз данных или создание пользовательских служб для передачи данных.
Банки являются ярким примером, когда внутридневной обмен сообщениями используется для передачи изменений данных в реальном времени по мере их возникновения. Исходной системе очень легко выбросить сообщение «через стену»; недостатком является то, что между этими системами очень мало договоров, и вы, как правило, видите, что госпитализация осуществляется на стороне потребителя. Это слишком слабо связано.
Другие преимущества заключаются в поддержке JMS "из коробки" для многих серверов приложений и т. д., а также во всех инструментах, связанных с этим: долговечность, мониторинг, создание отчетов и регулирование.
Здесь есть хорошая статья с несколькими примерами: http: //www.winslam .com / laramee / JMS / index.html
Решение «база данных как очередь сообщений» может оказаться сложным для выполнения задачи. Решение JMS менее тесно связано с тем, что отправителю сообщения не нужно ничего знать о получателе. Это может быть достигнуто с помощью некоторой дополнительной абстракции в «базе данных как очереди сообщений», так что это не является огромным выигрышем ... Кроме того, вы можете использовать очередь способом «опубликовать и подписаться», что может быть удобно в зависимости от того, что Вы пытаетесь достичь. Это также хороший способ для дальнейшего разделения ваших компонентов. Если все ваше общение происходит внутри одной системы и / или наличие журнала, который сразу же доступен для приложения, очень важно, ваш метод кажется хорошим. Если вы общаетесь между отдельными системами, JMS - хороший выбор.
JMS в сочетании с JTA (Java Transaction API) и JPA (Java персистентный API) может быть очень полезным. С помощью простой аннотации вы можете поместить несколько действий с базой данных + отправку / получение сообщения в одну транзакцию. Таким образом, если один из них не работает, все откатывается с использованием одного и того же механизма транзакций.
