Очереди против таблиц в системах обмена сообщениями

Ответ 1

Фраза ударов каждый раз полностью зависит от ваших требований. Конечно, он не будет бить каждый раз для всех.

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

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

Если очередь сообщений светится, когда

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

Для простых систем с единой базой данных, командой и достаточно скромными требованиями к производительности - обязательно используйте базу данных. Используйте правильный инструмент для задания и т.д.

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

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

Аналогичным образом, вы никогда не использовали бы базу данных для балансировки нагрузки HTTP-запросов на своих веб-серверах, поскольку это было бы слишком медленно - если у вас есть высокие требования к производительности для вашего балансировщика нагрузки, вы не будете использовать базу данных либо.

Ответ 2

Сначала я использовал таблицы, а затем реорганизовал полноценную очередь сообщений, когда (и если) есть причина - тривиально, если ваш дизайн разумный.

Самые большие преимущества - это.) Это проще, (б) это лучший контрольный журнал, потому что у вас есть другие таблицы для присоединения к, c.), если вы хорошо знаете инструменты базы данных, они проще в использовании, чем Message Queue tools, d.), Как правило, немного проще настроить среду test/dev в контексте, который уже существует для вашего приложения (если такое же знакомство применяется).

Oh и e.), возможно, вы и другие, это не другой продукт для изучения, установки, настройки, администрирования и поддержки.

IMPE, он так же надежен, отключается, и вы можете конвертировать, если ему требуется более масштабируемое.

Ответ 3

• Данные постоянно хранятся в таблице. Я видел так много приложений java (jms), которые теряют или исчезают сообщения на своем пути для неперехваченных исключений или других ошибок.

  Какая реализация JMS? Sun продает надежную очередь, которая не может потерять сообщения. Возможно, вы только что купили дрянной JMS-совместимый продукт. IBM MQ чрезвычайно надежна, и есть библиотеки JMS для доступа к ней.

• Очереди, как правило, заполняются. Db-хранилище практически бесконечно.

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

• Таблицы легко доступны, в то время как вам нужно использовать эзотические инструменты для чтения из очереди.

  Это не соответствует моему опыту. Доступ к таблицам осуществляется через этот особый "другой язык" (SQL) и требует, чтобы я был в курсе структурных сопоставлений от таблиц к объектам и сопоставлениям типов данных от VARCHAR2 до String. Кроме того, я должен использовать какой-то уровень доступа (JDBC или ORM, который использует JDBC). Это кажется очень, очень сложным. Доступ к очереди осуществляется через MessageConsumers и MessageProducer с помощью простых отправлений и получения.

Ответ 4

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

• Потеря сообщений для неперехваченных исключений? Это едва ли ошибка очереди сообщений. Приложения, которые вы используете, плохо спроектированы. Они удаляют сообщения из очереди до завершения обработки. Они не используют транзакции или журналируют.
• Очереди сообщений заполняются, а хранилище БД "практически бесконечно"? Вы говорите так, как будто управление дисковым пространством было чем-то, чего не требовали базы данных. Серверы очереди сообщений требуют администрирования, как и серверы баз данных.
• Эзотерические инструменты для чтения из очереди? Возможно, если вы найдете асинхронные методы эзотерическими. Возможно, если вы найдете сериализацию и десериализацию эзотерической. (По крайней мере, это те вещи, которые я нашел эзотерическими, когда я изучал обмен сообщениями. Как и многие, казалось бы, эзотерические технологии, они на самом деле довольно обыденны, как только вы их понимаете, и понимание их является важной частью опытного образования разработчиков.)

Аспекты обмена сообщениями, которые делают его выше баз данных:

• Асинхронная обработка. Очереди сообщений уведомляют процессы ожидания при поступлении новых сообщений. Чтобы выполнить эту функцию в базе данных, процессы ожидания должны опросить базу данных.
• Разделение проблем. Канал связи отделен от деталей реализации содержимого сообщения. Только отправитель и получатель должны знать что-либо о формате потока данных в рамках данного сообщения.
• отказоутойчивости.. Сообщения могут работать, когда соединения между серверами прерывисты. Очереди сообщений могут сохранять сообщения локально и перенаправлять их только на удаленные серверы, когда соединение находится в режиме реального времени.
• Системная интеграция. В мире Windows, по крайней мере, обмен сообщениями встроен в операционную систему. Он использует модель безопасности ОС, она управляется с помощью инструментов ОС и т.д.

Если вам не нужны эти вещи, вам, вероятно, не нужна передача сообщений.

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

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

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

Ответ 5

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

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