Не понятно, когда вы будете использовать JMS (или очередь в целом) в сравнении с базой данных

Question

Когда вы сохраняете сообщение в очереди, разве это не больше метаданных, поэтому тот, кто извлекает данные из очереди, знает, как обрабатывать данные? фактическая информация в очереди не всегда содержит всю информацию.

Скажем, у вас есть такое приложение, как Twitter, и всякий раз, когда кто-то публикует сообщение, вам все равно нужно правильно сохранять текст сообщения в базе данных?

Очередь будет больше использоваться для оповещения других абонентов о том, что пришло новое сообщение, и тогда эти службы могут предпринять дальнейшие действия.

Или вы могли бы также сохранить текст твита в очереди? (или вы МОЖЕТЕ, но это было бы глупо?)

Может ли сообщение очереди иметь поля состояния, которые подписчики могут изменять при обработке своей части рабочего процесса? ( или вы сделали бы это в БД? )

Просто пытаюсь получить некоторые пояснения о том, когда вы будете использовать очередь вместо базы данных.

Answer 1

Когда процесс хочет обработать данные и обработать эти данные другому процессу (возможно, на другом хосте), существует 2 стратегии:

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

2. Обновите базу данных, а затем поставьте в крошечное сообщение другой процесс, просто чтобы уведомить его о необходимости массирования новых данных.

Существует ряд факторов, которые могут быть использованы для выбора стратегии:

• Если ваша база данных полностью ACID (можно надеяться), а ваша система массового обслуживания (QS) - нет, ваши данные будут в БД более безопасными. Даже если сообщение очереди теряется при сбое сервера, вы можете запустить сценарий для обработки необработанных данных, найденных в БД. Это будет вариант для варианта 2.

• Если ваши данные достаточно велики (скажем, 1 МБ или более), то может быть жестоко обременять их вашей QS. Если он постоянен, вы в конечном итоге будете записывать данные дважды: сначала в персистент QS, а затем в БД. Это может повлиять на производительность и повлиять на вас, чтобы перейти к варианту 1.

• Если ваша БД медленная или даже недоступна для внешнего интерфейса вашего приложения, то для варианта 1 это так.

• Если ваш второй процесс собирается что-то делать с данными, но не сохраняет их в БД, то вариант 1 может быть подходящим.

Не могу больше думать, но я надеюсь, что вы поняли.

Answer 2

Как правило, очередь используется для «сглаживания» скорости публикации по сравнению с потреблением путем буферизации входящих запросов, которые не могут быть обработаны немедленно. Очередь обычно поддерживается каким-то энергонезависимым хранилищем (например, таблицей базы данных). Так что различие не такое четкое.

Используйте базу данных, если вы хотите выполнить много поисков по «очереди», или предоставить расширенные отчеты.

Answer 3

Насколько я понимаю, Twitter будет использовать и БД, и JMS одновременно. Сначала, когда твиты написаны, они будут храниться в базе данных, и именно так они будут отображаться на доске объявлений. Однако, поскольку это модель издателя / подписчика, когда публикуются твиты, она будет отправлена ​​подписчикам. Так что оба предмета будут использованы.

Answer 4

Мы широко использовали JMS на моей последней работе, когда мы передавали данные с компьютера на компьютер. В итоге мы одновременно отправляли и хранили данные; однако мы сохранили гораздо меньше данных, чем отправили. У нас было много метаданных, окружающих реальные значения.

Мы использовали JMS как просто службу обмена сообщениями, и она отлично сработала. Но вы не хотите использовать JMS для хранения ваших данных, поскольку они не сохраняются (за исключением возможности регистрировать и воспроизводить сообщения, возможно).

Одним из основных преимуществ, которые дает вам JMS, является возможность отправлять ваши сообщения в правильном и соответствующем порядке и гарантировать, что все получат их в этом порядке. Это упрощает синхронизацию, поскольку большая часть обработки сообщений выполняется за вас.

Answer 5

Я рекомендую вам взглянуть на книгу Грегора Хофе Шаблоны корпоративной интеграции , в которой объясняется множество различных шаблонов для подходов, основанных на обмене сообщениями.

Answer 6

Я бы использовал очередь всякий раз, когда вы можете использовать шаблон «запусти и забудь». В вашем примере с Twitter я бы использовал очередь для отправки сообщения от клиента. Затем обработчик очереди может сохранить его в базе данных при получении.

Если вам требуется какой-то статус немедленного успеха / сбоя, очередь сообщений не для вас.

Answer 7

Я думаю, что ваш пример в твиттере хорош. Вы хотите базу данных для долгосрочных данных. Не будет особого смысла помещать твит в сообщение, потому что оно должно быть в базе данных. Однако, если вы работаете в чате, вы можете поместить сообщение в очередь JMS, потому что вы нигде не сохраняете его.

Дело не в том, что вы не можете поместить твит в JMS, а в том, что вам все равно нужно поместить его в базу данных.