Выбор доставки сообщений с использованием очередей

8 мин

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

Хранилище очередей Azure
Служебная шина Azure

Что такое Хранилище очередей Azure?

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

Что такое очереди Служебной шины Azure

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

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

Что такое разделы Служебной шины Azure

Разделы Служебной шины Azure похожи на очереди, однако могут иметь нескольких подписчиков. Когда сообщение вместо очереди отправляется в раздел, для выполнения задач могут быть активированы несколько компонентов. Представьте, что пользователь слушает песню в приложении для обмена музыкой. Мобильное приложение может отправить сообщение в раздел "Прослушано". Этот раздел будет иметь подписку для UpdateUserListenHistory и другую подписку для UpdateArtistsFanList. Каждая из этих функций обрабатывается разным компонентом, который получает собственную копию сообщения.

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

Преимущества очередей

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

Повышенная надежность

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

Гарантии доставки сообщения

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

По крайней мере один раз доставка: в этом подходе каждое сообщение гарантирует доставку по крайней мере одному из компонентов, извлекающих сообщения из очереди. Обратите внимание, что в определенных обстоятельствах возможно, что одно и то же сообщение может быть доставлено несколько раз. Например, если два экземпляра веб-приложения получают сообщения из очереди, обычно каждое сообщение передается только одному из них. Однако если один экземпляр занимает много времени для обработки сообщения и истечения времени ожидания, сообщение может быть отправлено другому экземпляру, а также. Это следует учитывать при написании кода веб-приложения.
По крайней мере доставки: в этом подходе каждое сообщение не гарантируется для доставки, и есть небольшая вероятность того, что она не может прибыть. Однако, в отличие от доставки по крайней мере один раз, нет шансов, что сообщение будет доставлено дважды. Иногда это называется автоматическим поиском повторяющихся данных.
First-In-First-Out (FIFO): в большинстве систем обмена сообщениями сообщения обычно покидают очередь в том же порядке, в котором они были добавлены, но следует учитывать, гарантируется ли эта доставка. Если ваше распределенное приложение требует, чтобы сообщения обрабатывались именно в таком порядке, следует выбрать систему очередей, дающую гарантию обработки FIFO.

Поддержка транзакций

Некоторые тесно связанные группы сообщений могут вызвать проблемы при сбое доставки одного сообщения в группе.

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

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

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

Какую службу следует использовать?

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

Выберите очереди Служебной шины, если:

Требуется гарантия доставки не более одного раза.
Требуется гарантия доставки в порядке FIFO.
Требуется объединить сообщения в транзакции.
Требуется получать сообщения без опроса очереди.
Требуется указать модель доступа на основе ролей для очередей.
Требуется обрабатывать сообщения, размер которых больше 64 КБ, но меньше 100 МБ. Максимальный размер сообщения, поддерживаемый уровнем "Стандартный", составляет 256 КБ, а уровень "Премиум" поддерживает 100 МБ.
Размер очереди не будет превышать 1 ТБ. Максимальный размер очереди для уровня "Стандартный" составляет 80 ГБ, а для уровня "Премиум" — 1 ТБ.
Требуется возможность пакетной публикации и потребления сообщений.

Выберите разделы Служебной шины, если выполняются следующие условия:

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

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

Выберите хранилище очередей, если:

Требуются журналы всех сообщений, проходящих через очередь.
Размер очереди может превышать 1 ТБ.
Необходимо отслеживать ход обработки сообщения внутри очереди.

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

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

Продолжить