Очереди к таблицам в системах обмена сообщениями [закрыты]

Question

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

1. Данные постоянно хранятся в таблице.Я видел так много приложений java (jms), которые теряют или исчезают сообщения на своем пути из-за неперехваченных исключений или других ошибок.
2. Очереди, как правило, заполняются.Вместо этого хранилище базы данных практически бесконечно.
3. Таблицы легко доступны, в то время как для чтения из очереди приходится использовать специальные инструменты.

Каково ваше мнение по каждому подходу?

Answer 1

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

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

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

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

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

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

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

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

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

Answer 2

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

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

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

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

Answer 3

<Ол>

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

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

Очереди, как правило, заполняются. Вместо этого хранилище БД практически бесконечно.

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

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

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

Answer 4

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

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

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

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

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

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

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

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

Answer 5

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

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