Часть 1. Архитектура RabbitMQ и приложения

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

Глава 1. Основы RabbitMQ

Эта глава обсуждает:

  • Уникальные возможности RabbitMQ

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

    Базовые принципы модели Advanced Messaging Queuing, основы RabbitMQ

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

Функциональность и преимущества RabbitMQ

RabbitMQ имеет вного возможностей и преимуществ, из которых наиболее важными являются:

  • Открытый исходный код: Первоначально разработанный в партнёрстве LShift, LTD и Cohesive FT как RabbitMQ Technologies, RabbitMQ теперь находится в собственности Pivotal Software Inc. и выпускается под лицензией Mozilla Public License. Будучи проектом с открытым исходным кодом, написанным на Erlang, RabbitMQ обладает свободой и гибкостью, одновременно используя мощность Pivotal, стоящую за ним как за продуктом. Разработчики и инженеры из сообщества RabbitMQ могут вносить улучшения и дополнения, а Pivotal может предлагать коммерческую поддержку и стабильный дом для постоянного вызревания продукта.

  • Нейтральность к платформе и производителю: Так как брокер сообщений, который реализует нейтральную к платформам и производителям спецификацию Advanced Message Queuing Protocol (AMQP), имеются клиенты, доступные практически для любого языка прогрммирования и на всех основных платформах.

  • Лёгкий вес: Он является легковесным, требуя менее чем 40 МБ ОЗУ для исполнения центрального ядра приложения RabbitMQ совместно с подключаемыми модулями, такими как UI Управления. Отметим, что добавление сообщений в очередь может увеличить потребление памяти и делает это.

  • Библиотеки клиента для большинства современных языков: Обладая библиотеками клиента, имеющими целью основные современные языки программирования на множестве платформ, RabbitMQ предлагает привлекательный брокер для его программирования. Не существует привязки к какому либо производителю или языку при выборе того на как вы будете разрабатывать программы, которые будут общаться с RabbitMQ. На самом деле не редкость когда RabbitMQ применяется как основная центральная часть между приложениями, написанными на различных языках программирования. RabbitMQ предоставляет полезный мост , который делает возможным для таких языков, как Java, Ruby, Python, PHP, JavaScript и C# совместно использовать данные в различных операционных системах и средах.

  • Гибкость в контроле компромиссов обмена сообщениями: RabbitMQ предоставляет гибкость в контроле необходимых компромиссов надёжности обмена сообщениями с пропускной способностью сообщений и производительностью. Так как нет "одного размера под все" типы приложений, сообщения могут назначать должны ли они сохраняться на диск перед отправкой и, если они настроены в кластере, очереди могут быть настроены на высокую доступность, распространяясь на множество серверов и гарантируя что сообщения не утратятся в случае отказа сервера.

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

  • Подключаемые модули сторонних разработчиков: Как центральный пункт для интеграции приложений, RabbitMQ предоставляет гибкую систему подключаемых модулей (plugin). Например, имеются подключаемые модули сторонних разработчиков для сохранения сообщений непосредственно в базах данных при помощи записей RabbitMQ напрямую в базу данных.

  • Уровни безопасности: В RabbitMQ безопасность предоставляется на множестве уровней. Клиентские соединения могут быть обеспечены безопасностью усилением взаимодействия только через SSL и удостоверением сертификата клиента. Доступ пользователя может управляться на уровне виртуального хоста, предоставляя изоляцию сообщений и ресурсов на высоком уровне. Кроме того, доступ к возможностям настройки, чтение из очередей и запись в обмен управляются соответствиями шаблонов регулярных выражений (regex). Наконец, для интеграции с внешними системами аутентификации, такими как LDAP, могут применяться подключаемые модули.

Мы исследуем все свойства из этого перечня в последующих главах, однако я бы хотел прямо сейчас заострить внимание на фундаментальных свойствах RabbitMQ: том языке, на котором он запрограммирован (Erlang) и основной модели, на которой он основан (модель Advanced Message Queuing), некоторой спецификации, которая определяет большую часть лексикона RabbitMQ и его поведение.

RabbitMQ и Erlang

Выступая в роли высокопроизводительного, стабильного и развёртываемого в кластер брокера сообщений, неудивительно, что RabbitMQ нашёл пристанище в таких критически важных средах, как центральная часть крупномасштабных построений обмена сообщениями. Он был написано на языке уровня телефонных корпораций функционального программирования Erlang, разработанном в Лаборатории компьютерных наук Ericsson в середине 1980-х годов. Erlang был разработан как распределённая, отказоустойчивая, мягкая система реального времени для приложений, требующих безотказной работы 99,999%. Как язык и среда выполнения, Erlang сосредотачивается на лёгких процессах, которые передают сообщения друг другу и обеспечивают высокий уровень параллелизма без общего состояния.

[Замечание]Замечание

Система реалтнго времени является аппаратной платформой, платформой програмного обеспечения, или комбинацией обеих, которая имеет требования на то когда она обязана вернуть отклик на некое событие. Мягкая система реального времени (soft real-time system) приносит в жертву менее важные сроки исполнения задач в пользу более важных.

Архитектура Erlang, которая сосредоточена на одновременной обработке и передаче сообщений, сделала его естественным выбором в качестве брокера сообщений типа RabbitMQ. Выступая в роли какого- то приложения, брокер сообщений сопровождает параллельные соединения, маршрутизацию сообщений и управляет их состояниями. Кроме того, архитектура распределённых взаимодейтсвий Erlang делает его естественным как механизма кластеризации RabbitMQ. Серверы в кластере RabbitMQ используют систему IPC (inter-process communication, межпроцессного взаимодействия) Erlang, разгружая ту функциональность, которую многие конкурирующие брокеры обмена сообщениями должны реализовывать дополнительно к возможностям кластеризации (см. Рисунок 1-1).

 

Рисунок 1-1


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

Несмотря на преимущества от применения Erlang, получаемые RabbitMQ, среда Erlang может стать камнем преткновения. Может быть полезным какое- то изучение Erlang с тем, чтобы вы не смущались при управлении файлами настроек RabbitMQ и использовании Erlang для сбора информации о текущем состоянии времени исполнения Erlang.

RabbitMQ и AMQP

RabbitMQ первоначально был выпущен в 2007, причём совместная работа, производительность и надёжность были первичными целями на уме в процессе его разработки. RabbitMQ был одним из самых первых брокеров обмена сообщениями для реализации спецификации AMPQ. Судя по всему, это была эталонная реализация. Расщеплённая на две части, спецификация AMPQ определяет не только протокол общения по проводу для RabbitMQ, но также и логическую модель, которая выводит функциональность ядра RabbitMQ.

[Замечание]Замечание

Существует множество версий самой спецификации AMQP. Для целей данной книги мы сосредоточимся на AMQP 0-9-1. Хотя более новые версии RabbitMQ и поддерживают AMQP 1.0 в виде подключаемого модуля, само ядро архитектуры RabbitMQ более тесно связано с AMQP 0-8 и 0-9-1. Данная спецификация AMQP изначально представлена двумя документами: документом верхнего уровня, который описывает и модель AMQ и протокол AMQ, а также более подробный документ, который предоставляет различные уровни информации о каждом классе, методе, свойстве и поле. Дополнительную информацию об AMQP, включая сами документы спецификации, можно отыскать на сайте http://www.amqp.org.

Существует множество популярных брокеров обмена сообщениями и протоколов обмена сообщениями и важно учитывать то воздействие, которое будут оказывать сами протокол и брокер на ваше приложение. RabbitMQ поддерживает AMQP, однако он также поддерживает и прочие протоколы, например MQTT, Stomp и XMPP. Нейтральность и расширяемость подключаемыми модулями протокола RabbitMQ делает его хорошим выбором для архитектур приложений со множеством протоколов при сопоставлении с прочими распространёнными брокерами обмена сообщениями.

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

Кто применяет RabbitMQ и как?

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

  • Reddit, очень популярное в интернете сообщество, интенсивно применяет RabbitMQ в основном ядре своей прикладной платформы, которая обслуживает миллиарды веб страниц за месяц. Когда некий пользователь регистрируется на таком сайте, представляет на рассмотрение некий новый пост или выставляет голос по какой- то ссылке, в RabbitMQ публикуется сообщение для асинхронной обработки потребляющими их приложениями.

  • NASA выбрало в качестве брокера обмена сообщениями для своей платформы Nebula, централизованной платформы управления серверами для своей серверной инфраструктуры, которая произросла из платформы OpenStack, очень популярной платформы для построения частных и общедоступных облачных служб.

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

  • Для Ocean Observations Initiative RabbitMQ выполняет маршрутизацию жизненно необходимых физических, химических, геологических и биологических данных в распределённых сетевых средах исследовательских компьютеров. Все собираемые из Южного, Тихого и Атлантического океанов интегрируются в проекте National Science Foundation, который вовлечён в построение крупномасштабной сетевой среды датчиков в океане и на его поверхности.

  • Rapportive, некое добавочное приложение Gmail, которое помещает подробную контактную информацию непосредственно внутри почтового ящика, использует RabbitMQ в качестве клея для своих систем обработки данных. Миллиарды сообщений проходят через RabbitMQ ежемесячно с тем, чтобы предоставлять данные расползающемуся в веб механизму и аналитической системе Rapportive, а также выгрузить операции длительного с их веб серверов.

  • MercadoLibre, самая большая экосистема электронной коммерции в Латинской Америке, использует RabbitMQ в самом сердце своей архитектуры ESB (Enterprise Service Bus, корпоративной шины службы), отвязывая их данные от тесно связанных приложений, что делает возможной гибкую интеграцию с различными компонентами в их прикладной архитектуре.

  • Мобильная рекламная сеть GoogleAdMob применяет RabbitMQ в самой сердцевине своего проекта RockSteady для осуществления анализа показаний и обнаружения неисправностей в реальном масштабе времени и направлении пожарного брандспойта сообщений через RabbitMQ в Esper, систему обработки сложных событий.

  • Индийская система биометрической базы данных Aandhaar: использует RabbitMQ для обработки данных на различных этапах в своём рабочем потоке, доставляя данные к своим инструментам мониторинга, хранилищам данных и системам обработки данных на основе Hadoop. Aandhaar разработана для предоставления переносимой системы идентификации в реальном масштабе времени для каждого персонального резидента Индии, охватывающей 1.2 миллиарда людей.

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

Преимущества архитектур со слабыми связями

Когда я впервые приступил к реализации архитектуры на основе обмена сообщениями, я искал как отцепить обновления базы данных связанные с тем когда некий участник регистрируется в вебсайте. рассматриваемый вебсайт рос стремительно и из- за того способа, которым мы его создали, он не был изначально спроектирован под надлежащее масштабирование. При регистрации пользователей на этом вебсайте определённые серверы базы данных имели таблицы, которые необходимо было обновлять штампами времени регистрации (см. Рисунок 1-2). Этот штамп времени необходимо обновлять в реальном масштабе времени, так как большинство привлекательных действий на данном сайте частично управляются таким значением временного штампа. После входа в систему участники получали более привилегированный статус в социальных играх по сравнению с теми пользователями, которые были активны в интернете в данный момент.

 

Рисунок 1-2


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

Поскольку эта площадка продолжала расти, продолжительность времени, требуемого для регистрации участником также увеличивалась. Основная причина для этого была достаточно очевидной: При добавлении некоего нового приложения, которое применяло самый последний штамп времени регистрации участника, его таблицы базы данных выполняли эту запись настолько быстро, насколько это возможно за счёт удаления связей (join) между базами данных. Для сохранения актуальности и точности данных также должны были обновляться при регистрации участника и все новые таблицы базы данных. Ранее было всего несколько таблиц, которые сопровождались таким образом. Проблема с производительностью начала подкрадываться по той причине, что обновления такой базы данных выполнялись последовательно. Всякий запрос на обновление конкретного временного штампа последней регистрации участника должно было завершиться до того как начнётся следующее. Десять подлежащих исполнению запросов с временем завершения каждого в пределах 50мс добавили бы собой до полсекунды в обновления базы данных. Все эти запросы должны завершиться до отправки отклика авторизации и перенаправления обратно этому пользователю. Кроме того, любые проблемы в сервере базы данных осложняли рассматриваемую проблему. Если один из серверов баз данных начинал отвечать медленно или становился не реагирующим, участники не могли бы более выполнять регистрацию на этой площадке.

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

[Определение]Определение

Обеспечение промежуточного уровня, ориентированное на обработку сообщений (MOM, Message-oriented middleware) определяется как инфраструктура программного обеспечения или аппаратных средств, которая делает возможными отправку и приём сообщений в распределённых системах. RabbitMQ эффективно выполняет обслуживание этой роли с помощью функциональности, которая предоставляет расширенную маршрутизацию и распространение сообщений, причём даже в глобальных сетях (WAN, wide area network) оставаясь толерантным при сопровождении надёжных распределённых систем, которые легко взаимодействуют с другими системами.

После отцепления самого процесса регистрации от необходимых обновлений базы данных я обнаружил некий новый уровень свободы. Участники получили возможность быстрой регистрации, так как больше не были вынуждены обновлять имеющиеся базы данных как часть своего процесса аутентификации. Вместо этого публиковалось некое сообщение о регистрации участника, которое содержало всю необходимую информацию, подлежащую обновлению во всех базах данных, а также потребляющие их приложения, в которых независимо записывались такие обновления в каждой базе данных (Рисунок 1-3). Такое сообщение регистрации не содержало аутентификационной информации для данного участника, а вместо этого только ту информацию, которая была необходима для сопровождения состояния последней регистрации участника в наших различных базах данных и приложениях. Это делало для нас возможной горизонтальное масштабирование записей в базу данных при наличии большего контроля. За счёт контроля за общим числом потребляющих приложений, выполняющих запись в некий конкретный сервер базы данных мы получали возможность дросселирования записи в серверы, которые начинали испытывать осложнения нагрузки, вызываемые новым ростом площадки, в то время как мы обрабатывали её собственные уникальные проблемы масщтабирования.

 

Рисунок 1-3


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

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

Отцепление ваших приложений

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

 

Рисунок 1-4


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

Отделение записи в базу данных

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

Отвязывая свою базу данных от конкретного приложения мы создаём архитектуру со свободной связью. В этой архитектуре RabbitMQ, обеспечение промежуточного уровня ориентированное на обмен сообщениями (MOM, messaging-oriented middleware), выступает в роли посредника для ваших данных прежде чем будет предпринято некоторое действие с выбранной базой данных. Некое потребляющее приложение (consumer application) подхватывает эти данные у сервера RabbitMQ и выполняет необходимое действие с базой данных (Рисунок 1-5).

 

Рисунок 1-5


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

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

Бесшовное добавление новой функциональности

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

 

Рисунок 1-6


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

Репликация данных и событий

Расширяя данную модель, RabbitMQ предоставляет встроенный инструментарий для распространения данных по центрам обработки данных, что делает возможной федеративную доставку и синхронизацию приложений. Федерализация позволяет RabbitMQ выполнять активную доставку в удалённые экземпляры RabbitMQ, принимая во внимание толерантность WAN и расщепление сетевых сред. Применение подключаемого модуля федерализации RabitMQ делает простым добавление сервера или кластера RabbitMQ в каком- то втором центре обработки данных. Это проиллюстрировано на Рисунке 1-7, где данные из вашего первоначального приложения могут теперь обрабатываться в двух различных местоположениях во Всемирной сети интернет.

 

Рисунок 1-7


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

Федерализация данных и событий со множеством хозяев

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

 

Рисунок 1-8


Двунаправленная федерализация данных позволяет получение и обработку одних и тех же событий данных в обоих центрах обработки данных.

[Замечание]Замечание

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

Модель расширенных очередей обмена сообщениями

Многие достоинства RabbitMQ, включая его гибкость, проистекают из спецификации AMQP. В отличии от таких протоколов как HTTP и SMTP, спецификация AMQP определяет не только некий сетевой протокол, но также и службы и поведение стороны сервера. Я буду называть эту информацию моделью AMQ (Advanced Message Queuing, расширенных очередей обмена сообщениями). Эта модель AMQ логически определяет три абстрактных компонента в программном обеспечении брокера, которые определяют поведение маршрутизации сообщений:

  • Exchange (Обмен): Этот компонент брокера обмена сообщениями осуществляет маршрутизацию сообщений в очереди.

  • Queue (очередь): структура данных на диске или в оперативной памяти, которая сохраняет сообщения.

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

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

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

Обмены

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

RabbitMQ имеет множество типов обмена, причём каждое с различными реакциями маршрутизации. Помимо этого он предлагает основанную на подключаемых модулях архитектуру для индивидуализации обменов. Рисунок 1-9 демонстрирует логику обзора отправку издателем какого- то сообщения в RabbitMQ с маршрутизацией сообщения через некий обмен.

 

Рисунок 1-9


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

Очереди

Очередь (queue) отвечает за хранение полученных сообщений и может содержать информацию настроек,которая определяет что можно делать с этим сообщением. Неаая очередь может держать сообщения только в оперативной памяти, либо может сохранять их на диск, прежде чем доставлять их в порядке первый- пришедший первым- и уходит (FIFO, first-in, first-out).

Связывания

Для определения взаимодействия между очередями и обменами модель AMQ определяет binding (связывания). В RabbitMQ связывания, или binding keys (ключи связывания) сообщают некоторому обмену в какую из очередей доставлять сообщение. Для некоторых типов обмена определяемое связывание также указывает обмену фильтрацию того какие сообщения оно может доставлять в некую очередь.

При публикации некоторого сообщения в каком- то обмене приложения применяют атрибут routing-key (ключ маршрутизации). Это может быть название очереди либо это может быть строка, которая семантически описывает подходящее сообщение. Когда обмен сообщение для определения маршруизации необходимых очередей, такой ключ маршрутизации сообщения вычисляется для ключа связывания (Рисунок 1-10). Другими словами, получаемый ключ связывания является тем клеем, который связывает некую очередь с обменом, а ключ маршрутизации является вычисляемым для него критерием.

 

Рисунок 1-10


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

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

Помимо связывания очередей с обменами,как это определяется в модели AMQ, RabbitMQ расширяет имеющуюся спецификацию AMQ, допуская связывание одного обмена с другим. Это свойство доставляет большую гибкость при создании различных шаблонов маршрутизации сообщений. Помимо различных шаблонов маршрутизации, доступных при применении обменов, вы получите дополнительную информацию о связывании обмена- с- обменом в Главе 6.

Выводы

RabbitMQ в качестве обеспечением промежуточного уровня, ориентированного на обмен сообщениями, (MOM, messaging-oriented middleware), является захватывающей воображение технологией, делающей возможной операционную гибкость, которую невозможно достичь без архитектуры слабо связанных приложений, которая это и допускает. Углубляясь и далее в основы и поведение RabbitMQ AMQP, данная книга призвана доказать свою ценность в качестве справочной информации, которая позволит вам понять как ваши приложения могут применять её надёжные и мощные функции. В частности, в скором времени вы узнаете как осуществлять публикацию сообщений и применять функции динамической маршрутизации в RabbitMQ для выборочного вытаскивания из пожарного брандспойта данные, которые может отправлять ваше приложение, те данные, которые могли быть глубоко похоронены в жёстко связанном коде и в процессах вашей среды.

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

Поскольку эта книга будет практическим рководством, имеющим целью предоставление необходимых для использования RabbitMQ в самых сложных средах знаний, в следующей главе вы начнёте работать с кодом. Изучив "как говорить с кроликом", вы будете применять основные понятия AMQP, писать код для отправки и получения сообщений с помощью RabbitMQ. Для общения с "Кроликjv", вы будете ghbvtyznm библиотеку на основе Python c названием rabbitpy, ту библиотеку, которая написана специально для примеров кода в этой книге; я расскажу вам об этом в следующей главе. Даже если вы опытный разработчик, который уже писал приложения, которые общаются с RabbitMQ, вы должны хотя бы просмотреть следующую главу, чтобы понять что происходит на уровне протокола когда вы применяете RabbitMQ через AMQP-протокол.