Что такое MQ и почему я хочу его использовать?
в моей команде на работе мы часто используем технологию IBM MQ для связи между приложениями. Я видел в последнее время на хакерских новостях и других местах о других технологиях MQ, таких как RabbitMQ. У меня есть базовое понимание того, что это (обычно проверяемая область для размещения и получения сообщений), но что я хочу знать, что именно это хорошо? Как я узнаю, где я хочу использовать его и когда? Почему бы просто не придерживаться более рудиментарных форм обмена сообщениями между процессами?
6 ответов
все объяснения до сих пор являются точными и точными, но могут чего - то не хватать: одно из основных преимуществ очереди сообщений: устойчивость.
представьте себе: вам нужно связаться с двумя или тремя другими системами. Общим подходом в эти дни будут веб-службы, что нормально, если вам нужны ответы сразу.
однако: веб-службы могут быть отключены и недоступны - что вы делаете? Помещение Вашего сообщения в очередь сообщений (которая имеет компонент на вашем компьютере / сервере тоже), как правило, будет работать в этом сценарии - ваше сообщение просто не доставляется и, таким образом, обрабатывается прямо сейчас, но это будет позже, когда другая сторона службы вернется в интернет.
поэтому во многих случаях использование очередей сообщений для подключения разрозненных систем является более надежным и надежным способом отправки сообщений туда и обратно. Это не работает хорошо для всего (если вы хотите знать настоящее цена акций для MSFT, положить этот запрос в очередь может быть не лучшим из идей), но во многих случаях, например, помещая заказ в очередь сообщений вашего поставщика, он работает очень хорошо и может помочь облегчить некоторые проблемы надежности с другими технологиями.
MQ означает очередь обмена сообщениями.
Это уровень абстракции, который позволяет нескольким процессам (вероятно, на разных машинах) взаимодействовать через различные модели (например, Точка-точка, публикация подписки и т. д.). В зависимости от реализации он может быть настроен для таких вещей, как гарантированная надежность, отчеты об ошибках, безопасность, обнаружение, производительность и т. д.
вы можете сделать все это вручную с помощью сокетов, но это очень сложно.
например: Предположим, вы хотите, чтобы процессы общались, но один из них может умереть в середине, а затем снова подключиться. Как вы гарантируете, что промежуточные сообщения не будут потеряны? Решения MQ могут сделать это за вас.
системы queueuing сообщение должны дать вам несколько бонусов. Среди наиболее важных из них-мониторинг и транзакционное поведение.
Транзакционный дизайн важен, если вы хотите быть невосприимчивы к сбоям, таким как сбой питания. Представьте себе, что вы хотите уведомить банковскую систему о выводе денег из банкомата, и это нужно делать ровно один раз за запрос, независимо от того, какие серверы временно отказали посередине. MQ systems позволит вам координировать транзакции через несколько баз данных, MQ и других систем.
Излишне говорить, что такие системы очень медленны по сравнению с именованными каналами, TCP или другими нетранзакционными инструментами. Если требуется высокая производительность, вы не позволите записывать ваши сообщения через диск. Вместо этого, это усложнит ваш дизайн-добиться экзотического надежного и быстрого общения, которое толкает дизайнера на действительно нетривиальные трюки.
системы MQ нормально позволяют потребителям наблюдать содержание очереди, пишут Плагины, четкая queus и т. д.
MQ просто означает очередь сообщений.
вы бы использовали его, когда вам нужно надежно отправить сообщение между процессами / кросс-платформенными / кросс-приложениями, которое не зависит от времени.
очередь сообщений получает сообщение, помещает его в соответствующую очередь и ждет, пока приложение получит сообщение, когда оно будет готово.
очереди сообщений формируют основу для многих шаблонов, описанных в классической книге "Шаблоны интеграции предприятия" и сайт.
ссылка: веб-службы могут быть отключены и недоступны - что вы делаете тогда? Как расширение к этому; что, если ваша локальная сеть и ваш локальный компьютер также не работают?? Пока вы ждете, пока система восстановит зависимые развернутые системы в другом месте, ожидая, что эти данные должны увидеть альтернативный поток данных. В противном случае это может быть недостаточно хорошим ответом "в реальном времени" для сегодняшних и очень скоро в будущих требованиях к Интернету вещей (IOT).
Если вы хотите true параллельное энергонезависимое хранение различных потоков FIFO (по крайней мере, в какой-то момент вдоль сигнальной цепи) использует память FPGA и FRAM. FRAM работает с тактовой частотой, и устройства FPGA могут быть перепрограммированы на лету, добавляя и забирая, сколько независимых параллельных потоков данных необходимо(в пределах установленных ограничений, конечно).