Перепутанный относительно того, когда Вы использовали бы JMS (или очередь в целом) по сравнению с базой данных
То, когда Вы храните сообщение в очереди, не является этим больше информации о метаданных поэтому, кто бы ни вытягивает от очереди, знает, как обработать данные? фактическая информация в очереди не всегда содержит всю информацию.
Скажите, что у Вас есть приложение как Твиттер, каждый раз, когда кто-то добавляет сообщение, необходимо ли было бы все еще сохранить фактический текст сообщения в корректной базе данных?
Очередь более использовалась бы для широковещательной передачи другим подписчикам, что прибыло новое сообщение, и затем те сервисы могли предпринять дальнейшие меры.
Или Вы могли на самом деле сохранить текст твита в очереди также? (или Вы МОГЛИ, но это будет глупо?)
Сообщение очереди могло иметь поля состояния, которые могут изменить подписчики, поскольку они обрабатывают свою часть потока операций? (или Вы сделали бы это в дб?)
Просто пытаясь получить некоторое разъяснение того, когда Вы использовали бы очередь по сравнению с дб.
6 ответов
Когда процесс хочет передать данные в другой процесс (возможно, на другой хост), существует 2 стратегии:
Запишите все данные в элемент очереди и дайте принимающему приложению позаботиться о том, чтобы они хранились в базе данных, наряду с любой другой обработкой.
Обновите свою базу данных, а затем поставьте в очередь крошечное сообщение другому процессу, чтобы сообщить ему, что есть новые данные, которые нужно массировать.
Существует ряд факторов, которые могут быть использованы для выбора стратегии:
Если ваша база данных полностью ACID (можно надеяться), а ваша система очередей (QS) - нет, то ваши данные будут более безопасны в БД. Даже если сообщение об очереди потеряется при падении сервера, Вы можете запустить скрипт для обработки необработанных данных, найденных в БД. Это было бы справедливо для варианта 2.
Если ваши данные достаточно большие (скажем, 1 MB или более), то может быть жестоко обременять ими ваш QS. Если они настойчивые, то в конечном итоге вы запишете данные дважды, сначала в БД, а затем в QS. Это может привести к снижению производительности и повлиять на то, что вы перейдете к варианту 1.
Если ваша БД медленная или даже недоступна для передней части приложения, то это вариант 1.
Если второй процесс собирается что-то делать с данными, но не хранить их в БД, то вариант 1 может стать предпочтительным.
Не могу больше думать, но надеюсь, вы поняли идею.
Мы широко использовали JMS на моей последней работе, когда мы передавали данные от машины к машине. В конце концов, мы одновременно отправляли и сохраняли данные; однако мы сохранили гораздо меньше данных, чем отправили. У нас было много метаданных, связанных с настоящими ценностями.
Мы использовали JMS просто как службу обмена сообщениями, и это очень хорошо сработало. Но вы не хотите использовать JMS для хранения ваших данных, поскольку у них нет постоянства (кроме, возможно, возможности регистрировать и воспроизводить сообщения).
Одно из основных преимуществ JMS - это возможность отправлять сообщения в правильном и подходящем порядке и гарантировать, что все будут получать их в этом порядке. Это упрощает синхронизацию, поскольку большая часть обработки сообщений выполняется за вас.
Я бы использовал очередь всякий раз, когда можно использовать шаблон "огонь и забытье". В вашем примере в Twitter я бы использовал очередь для отправки сообщения от клиента. Затем процессор очереди может сохранить его в базу данных, когда он доберется до него.
Если вам нужен какой-то статус немедленного успеха/неудачи, то очередь сообщений не для вас.
Обычно очередь используется для «сглаживания» скорости публикации по сравнению со скоростью потребления путем буферизации входящих запросов, которые не могут быть обработаны немедленно. Очередь обычно поддерживается каким-то энергонезависимым хранилищем (например, таблицей базы данных). Так что различие не так однозначно.
Используйте базу данных, если вы хотите выполнить множество поисков в своей «очереди» или предоставить подробные отчеты.
Я думаю, что ваш пример Twitter хорош. Вы хотите базу данных для долгосрочных данных. Не было бы много момента вкладывать твит в сообщении, потому что он должен идти в базу данных. Однако, если у вас запускали чат, то вы можете пойти дальше и поместить сообщение в очередь JMS, потому что вы не храните его в любом месте.
Это не то, что вы не можете поставить Tweet в JMS, это то, что вам нужно в любом случае поставить его в базу данных.
Это специальная ссылка (чтобы отличить его от 0), которая ни на что не указывает.
-121--2440553-Это повлияет только на процесс, вызывающий GC.
-121--4103987-Я рекомендую вам взглянуть на книгу Грегора Хофе Узоров интеграции предприятия , в которой объясняется множество различных узоров для подходов на основе обмена сообщениями.