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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обмены

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

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

Очереди

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

Связывания

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

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

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

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

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

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

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