Пользователь
0,0
рейтинг
17 января 2013 в 08:19

Администрирование → Очередь сообщений (Message Queue)

Очередь сообщений (Message Queue)



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

Почему очереди сообщений?

Сообщения, наряду с блоками вычисления и хранения, составляют три основных блока почти в каждой блок-схеме системы. Очереди сообщений, по существу, являются связующим звеном между различными процессами в ваших приложениях и обеспечивают надежный и масштабируемый интерфейс взаимодействия с другими подключенными системами и устройствами.
О́чередь — структура данных с дисциплиной доступа к элементам «первый пришёл — первый вышел». Добавление элемента возможно лишь в конец очереди, выборка — только из начала очереди, при этом выбранный элемент из очереди удаляется.

Использование очереди сообщений

Десять причин, почему очереди сообщений являются жизненно важным компонентом для любой архитектуры или приложения:
  • Слабое связывание — очереди сообщений создают неявные интерфейсы обмена данными, которые позволяют процессам быть независимыми друг от друга т.е вы просто определяете формат сообщений отправляемых от одного процесса другому.
  • Избыточность — Очереди позволяют избежать случаев неэкономного использования ресурсов процесса(например памяти) в результате хранения необработанной (лишней информации) информации.
  • Масштабируемость — очереди сообщений позволяют распределить процессы обработки информации. Таким образом, они позволяют легко наращивать скорость, с которой сообщения добавляются в очередь и обрабатываются.
  • Эластичность и возможность выдерживать пиковые нагрузки — очереди сообщений могут выполнять роль своего рода буфера для накопления данных в случае пиковой нагрузки, смягчая тем самым нагрузку на систему обработки информации и не допуская ее отказа.
  • Отказоустойчивость — очереди сообщений позволяют отделить процессы друг от друга, так что если процесс, который обрабатывает сообщения из очереди падает, то сообщения могут быть добавлены в очередь на обработку позднее, когда система восстановится.
  • Гарантированная доставка — использование очереди сообщений гарантирует, что сообщение будет доставлено и обработано в любом случае (пока есть хотя бы один обработчик).
  • Гарантированный порядок доставки — большая часть систем очередей сообщений способны обеспечить гарантии того, что данные будут обрабатываться в определённом порядке (чаще всего в том порядке в котором они поступили).
  • Буферизация — очереди сообщений позволяет отправлять и получать сообщения при этом работая с максимальной эффективностью, предлагая буферный слой — процесс записи в очередь может происходить настолько быстро, насколько быстро это в состоянии выполнить очередь сообщений, а не обработчик сообщения.
  • Понимание потоков данных — очереди сообщений позволяют выявлять узкие места в потоках данных приложения, легко можно определить какая из очередей забивается, какая простаивает и определить что необходимо делать — добавлять новых обработчиков сообщений или оптимизировать текущую архитектуру.
  • Асинхронная связь — очереди сообщений предоставляют возможность асинхронной обработки данных, которая позволяет поместить сообщение в очередь без обработки, позволяя системе обработать сообщение позднее, когда появится возможность.

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

  • Обработку данных
  • Буферизацию потоков данных
  • Управление процессами
  • Интеграцию и взаимодействие систем

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

Почему SaaS?

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

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

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

Преимущества перехода на облачные очереди сообщений включают в себя:

  • Увеличение скорости выхода на рынок: приложения и системы могут быть построены гораздо быстрее.
  • Уменьшение сложности: снижение рисков и накладных расходов в стратегическом потенциале. Например вам сейчас кажется что свой собственный сервер с поднятым и сконфигурированным RabbitMQ кажется лучшим решением, то в долгосрочной перспективе при росте нагрузки, требованиях к HA(high availability) ранняя интеграция сторонних сервисов может сыграть свою положительную роль.
  • Увеличение масштабируемости: возможность легко масштабировать производительность и функциональность


С чего начать?

Различных сервисов предоставляющих услуги очередей сообщений не так много:
  • Amazon SQS
  • IronMQ
  • StormMQ
  • Windows Azure Queues

При этом SQS предоставляет 100 000 бесплатных сообщений (я так понял что за весь период использования), IronMQ — 10 000 000 бесплатных сообщений в месяц (при условии если вы введете данные кредитной карточки), а StormMQ на данный момент в закрытой бете. Вплане наличия примеров использования и библиотек в лидерах SQS, хотя IronMQ тоже поддерживает наиболее популярные языки (Ruby,Python,C#,Java...) и примеров использования уже достаточно.

PS Я надеюсь мне удалось заронить каплю сомнения в выбор «поставить свой сервер MQ или использовать сторонний сервис» и заинтересовать в существующих SaaS решениях в области очередей сообщений.

upd: добавил Windows Azure Queues
Продолжение?

Проголосовало 347 человек. Воздержалось 59 человек.

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

Роман Кононов @rkononov
карма
21,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (17)

  • +1
    Все выше написанное настоль пространственное, что я не понял о чем речь.

    std::queue my_queue; тоже очередь и хорошо работает, но читая дальше и дальше я понял это какие то сервисы межпрограммного взаимодействия.

    Если возможно уточните о чем именно вы желаете поведать миру.
    • +1
      std::queue — это тупо двухсвязный список. А очереди сообщений, это отдельная инфраструктура, которая позволяет общаться как между процессами в пределах одного сервера, так и между серверами, да и между датацентрами. Позволяют организовать полноценную асинхронную работу сложнейших IT систем.
      • +1
        Не отдельная инфраструктура, а механизм интеграции в инфраструктуре.
  • +1
    Пожалуй, я приложу картинку.


    Как видно из изображения есть часть приложения, процесс, отдельное приложение которому требуется обработать сообщение (к примеру отослать email клиенту), второй компонент это непосредственно очередь сообщений в которую помещается сообщение (например запрос на отправку email), и в правой части изображения расположены обработчики сообщений (например email отправщики). В данном случае очередь сообщений позволяет связать различные компоненты системы, внеся при этом асинхронность и возможность сгладить нагрузку (например теперь отправить 1000 email стало гораздо проще)
  • +2
    Различных сервисов предоставляющих услуги очередей сообщений не так много

    Про Azure вы не слышали?
    • 0
      Добавил, спасибо. К сожалению не приходилось использовать.
      • +1
        В Windows Azure огромная подсистема сообщений под общим названием Windows Azure Service Bus, это более верное название

        Узнать больше можно тут
        msdn.microsoft.com/ru-ru/jj663113
  • +2
    Да, побольше бы больше конкретики. Например почему сказали только об облачных решениях. Если приложение не использует какую-либо облачную платформу, но нужны очереди. Только ради этого не всегда стоит менять серверную инфраструктуру.
    Я так понял пост задумывался как мотиватор к использованию очередей сообщений в проектах. Тогда наверное стоило больше рассказать о подходах к построению архитектуры, основанной на очередях.
    • –1
      Я сделал упор именно на облачные варианты, так как об остальных топики уже есть (хотя бы просто упоминания) а облачные в основном не затронуты
  • +2
    Самые простые в использовании/установке/настройке очереди, как по мне, это gearman и rabbitmq, причем последняя имеет плюшки вроде persistent queue, message ttl etc.
    • 0
      В первом тоже есть persistent storage. И я бы еще добавил Redis.
  • +1
    Хоть бы классификацию свойств очередей привели — транзакции, coхранение на диск, пересылка по сети, использование координирующего сервера, формат сообщений, дерево топиков, запрос/ответ — или у всех реализаций одни и те же свойства?

    • 0
      Посмотрим на результат опроса, возможно в следующем топике я приведу технические подробности «облачных» систем очередей сообщений
  • +3
    А как же всякие MSMQ, RabbitMQ, etc?
    • –1
      К сожалению здесь упомянуты только SaaS
  • 0
    pusher.com еще забыли.
    • 0
      InterSystems Ensemble тоже предназначена в том числе для построения интеграционных решений с использованием очередей сообщений.

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