Я нашел его, и он использовался для отправки сообщений между двумя системами.
Но почему? Почему бы вам просто не использовать Database
?
Должна быть какая-то функция, ActiveMQ
у которой Databases
нет?
Я нашел его, и он использовался для отправки сообщений между двумя системами.
Но почему? Почему бы вам просто не использовать Database
?
Должна быть какая-то функция, ActiveMQ
у которой Databases
нет?
Ответы:
Он используется для надежной связи между двумя распределенными процессами.
Да, вы можете хранить сообщения в базе данных для связи между двумя процессами, но, как только сообщение будет получено, вы должны будете перейти DELETE
к сообщению, это означает строку INSERT
и DELETE
для каждого сообщения.
Когда вы пытаетесь увеличить это, передавая тысячи сообщений в секунду, базы данных имеют тенденцию падать .
С ActiveMQ
другой стороны, ориентированное на сообщения промежуточное программное обеспечение [MOM] создано для обработки таких случаев использования.
Они предполагают, что сообщения в работоспособной системе будут удаляться очень быстро, и могут выполнять оптимизацию, чтобы избежать накладных расходов .
Он также может отправлять сообщения потребителям, вместо того, чтобы потребителю приходилось опрашивать новое сообщение, выполняя SQL-запрос.
Это дополнительно сокращает время ожидания, связанное с обработкой новых сообщений, отправляемых в систему.
ActiveMQ
или вообще все реализации ориентированного на сообщения промежуточного программного обеспечения (MOM) предназначены для отправки сообщений между двумя приложениями или двумя компонентами внутри одного приложения.
По сути, MOM и базы данных имеют общую основу в том смысле, что они обеспечивают транзакционное и постоянное хранилище данных, из которого можно читать и писать.
Большое различие заключается в шаблоне использования - где базы данных очень общие и оптимизированы для сложного поиска по множеству таблиц, MOM оптимизирован для чтения сообщений по одному в стиле FIFO [Queue].
JMS
, который реализует API ActiveMQ, является важным краеугольным камнем в приложениях Java Enterprise. Благодаря этому сообщения имеют довольно общий формат и семантику, что упрощает интеграцию между различными приложениями.
Конечно, есть много более подробно функции, которые только в ActiveMQ, проволочных протоколов , таких как OpenWire
, STOMP
и MQTT
, JMS
, EIP
вместе с Apache Camel, шаблоны сообщений , как «запрос / ответ» и «публикация / подписка», JMS Bridging, кластеризация (» сеть брокеров »), которые позволяют масштабировать и распространять и т. д.
Вы должны немного почитать эти темы, если вам интересно, поскольку они довольно большие.
ActiveMQ
имеет отличную поддержку планировщика , что означает, что вы можете запланировать отправку своего сообщения в определенное время .
Мы использовали эту функцию для отправки напоминаний о приеме лекарств пациентам, загружающим сведения о лекарствах в сценарии здравоохранения.
Scheduled Jobs
для тех же целей.
В РСУБД при обработке строки данных обычно обновляется флаг, указывающий, что строка обработана, чтобы обработка не повторялась.
Однако в случае очереди сообщений вам нужно только подтвердить сообщение, и следующий потребитель обработает следующее.
Разница в том, что состояние UPDATE
в РСУБД - это очень медленная операция по сравнению с acknowledge
операцией в activmeq.
Хочу подчеркнуть следующее:
Развязка : системы могут обмениваться данными без подключения. Очередь лежит между системами, сбой одной системы никогда не повлияет на другую, поскольку связь осуществляется через очередь. Системы продолжают работать, когда они включены.
Поддержка восстановления : сообщения в самих очередях сохранялись. Сообщения могут быть восстановлены позже в случае сбоя очереди.
Надежная связь : рассмотрим систему, обрабатывающую запросы клиентов. В нормальных случаях система получает 100 запросов в минуту. Эта система ненадежна, когда количество запросов превышает среднее. В таком случае Queue может управлять запросами и периодически отправлять сообщения в зависимости от пропускной способности системы, не нарушая ее.
Асинхронный : обмен данными между клиентом и сервером не блокируется. После того, как клиент отправил запрос на сервер, он может выполнять другие операции, не дожидаясь ответа. Получив ответ, клиент может обработать его в любое время.
Из Википедии
Apache ActiveMQ - это брокер сообщений с открытым исходным кодом, написанный на Java вместе с полным клиентом службы сообщений Java (JMS). Он предоставляет «Корпоративные функции», что в данном случае означает содействие взаимодействию более чем одного клиента или сервера.
Относительно ваших запросов:
Почему бы вам не использовать базу данных?
Вы должны использовать базу данных для постоянных данных, а не для временных данных. Предположим, вам нужно отправить сообщение от отправителя получателю. Получив сообщение, Получатель выполняет одну операцию (получить, обработать и забыть). После обработки этого сообщения оно вам вообще не понадобится. В этом случае сохранение сообщения в постоянной базе данных не является правильным решением.
Я полностью согласен с ответом @Hiram Chirino относительно вставки и удаления сообщения в базе данных, если вы используете базу данных вместо системы обмена сообщениями.
Преимущества этой статьи и этой статьи
Должна быть функция ActiveMQ, которой нет в базах данных?
Много. См. Дополнительную информацию на странице документации . Также обратите внимание на варианты использования .
Взгляните на эту презентацию, чтобы понять, что такое ActiveMQ.
Предположим, у вас есть приложение, которое используется одновременно в нескольких местах. Также предположим, что ваше приложение должно обрабатывать 1000 запросов в минуту или что-то в этом роде, поэтому обычные операции с базой данных не могут обрабатывать такие операции, Activemq действует как обработка сообщений, она помещает все сообщения в очередь, поэтому даже если одно из ваших приложений выйдет из строя в одном месте другое место не будет затронуто.