Очереди сообщений: как ускорить взаимодействие в системе, не потеряв в надежности

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

Разбираемся, что такое очереди сообщений и знакомимся с принципом их работы на примере Tarantool Queue Enterprise.

Что такое очереди сообщений

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

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

Хороший бытовой пример применения очередей — покупка билетов на премьеру в кинотеатре. Один человек хочет купить билет на 10 место в 5 ряду через официальный сайт кинотеатра, другой пытается сделать это же через сторонний сервис, третий — лично пришел к кассе кинотеатра. Поскольку кинотеатр не может продать несколько билетов на одно и то же место, он организует виртуальную очередь людей. И билет достается тому, кто первым обратился с подобным запросом. Остальные получат отказ. Похожие истории можно встретить при записи к врачу, при покупке в интернет-магазине, других ситуациях.

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

Алгоритм работы очередей

Общий алгоритм выглядит следующим образом:

• система‑источник добавляет сообщение в очередь, как в буфер;
• брокер хранит сообщение и гарантирует, что оно не будет утеряно;
• брокер осуществляет доставку сообщения до микросервиса‑получателя.

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

В концепции очередей важно несколько моментов.

• Очереди — идеальный инструмент для асинхронных задач: отправитель загружает сообщение в очередь и может продолжать работу без ожидания обработки сообщения получателем.
• Доставка сообщений может быть реализована двумя методами: - Pull — получатель сам периодически запрашивает информацию о новых сообщениях; - Push — сообщение поступает получателю без запроса, сразу после получения сообщения очередью.

Польза очередей сообщений

Очереди сообщений решают ряд важных задач.

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

Tarantool Queue Enterprise

У Tarantool есть свой продукт на рынке очередей сообщений — Tarantool Queue Enterprise. Это распределенная in‑memory система очередей сообщений, с помощью которой можно создавать очереди с разной архитектурой под разные сценарии использования в зависимости от задач бизнеса.

Tarantool Queue Enterprise дает возможность выбрать одну из двух архитектур.

Первая — архитектура SQ

Это очередь с возможностями отправки отложенных сообщений и настройки приоритетов. SQ предполагает уровень гарантий at least once (способ, при котором сообщение находится в очереди до тех пор, пока адресат не подтвердит получение и не изменит статус сообщения в очереди).

В SQ взаимодействие с очередью осуществляется по модели Put / Take (Pull) — сообщение попадает в очередь и хотя бы один раз доставляется получателю. Архитектура поддерживает шардирование, что повышает надежность хранения сообщений и равномерность распределения нагрузки.

Архитектура шардированной очереди с приоритетами (SQ) хорошо подходит для:

• обработки заказов внутри веб-сервисов;
• систем обмена сообщениями;
• маршрутизации и балансировки нагрузки;
• систем управления задачами.

Вторая — архитектура MQ

Функциональность MQ — это FIFO-очередь (first-in, first-out) со строгим порядком обработки сообщений.

В MQ взаимодействие с очередью осуществляется по модели Publish / Subscribe (Push) - потребители получают только те сообщения, на которые подписаны. Вместе с фильтрацией, это сокращает лишний трафик данных и повышает эффективность обработки.

Также в MQ реализована функция дедупликации, которая позволяет достичь гарантий доставки на уровне effectively once.

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

Сценарии применения очередей сообщений

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

• Обработка фоновых операций. К таким, например, можно отнести обработку изображений на сайтах, конвертирование видео в разные форматы, индексирование страниц после внесения изменений и другие. Очереди позволяют разгрузить основное приложение для выполнения основных задач.
• Буферизация для пакетной обработки. В некоторых сценариях приоритетным вариантом является массовая обработка данных — например, в случае пакетной вставки информации в базу данных. Логика проста — лучше отправить один запрос на сто записей, чем сто запросов по одной записи. В этом случае очередь может выступать в качестве буфера-накопителя для пакетов данных.
• Отложенные задачи. Многие брокеры очередей позволяют настроить отложенную доставку сообщений. Функционал полезен, например, интернет-магазинам, которые позволяют отказаться от заказа в течение 10 минут — в таком случае доставка и обработка сообщения заведомо задерживается на 10 минут.
• Аналитика данных. Сообщения, скапливающиеся в очереди, можно анализировать и использовать для сбора статистики. Таким образом, механизмы очередей в отдельных кейсах можно рассматривать в качестве дополнительного узла аналитики данных.
• Извещение сразу нескольких систем. Разные получатели могут получать все сообщения из одной и той же очереди. Это позволяет один раз положить в очередь событие, которое должно быть обработано разными системами, каждая со своей скоростью.

Вместе с тем, очереди сообщений — не «серебряная пуля» и не всегда способны решить поставленные задачи. Например, интеграцию механизма очередей не стоит рассматривать в трех случаях.

• У приложения простая архитектура. Очередь — дополнительный элемент, который усложняет архитектуру и нередко требует перестройки всей логики взаимодействия компонентов внутри приложения. Более того, очередь нужно администрировать и контролировать, что также требует ресурсов. Поэтому, если затраты на внедрение очереди выше, чем эффект от такой интеграции, от идеи лучше отказаться.
• Приложение имеет монолитную архитектуру, которую нельзя «развязать». Встраивание очереди в ПО, в котором отсутствуют выделенные, независимые компоненты, отвечающие за разные задачи — нередко избыточная мера. Если в монолите нужно реализовать асинхронную обработку, лучше применять стандартную многопоточную модель.
• Очередь не подходит там, где нельзя или нецелесообразно использовать асинхронное взаимодействие, потому что очереди всегда асинхронны.

Кейсы применения Tarantool Queue Enterprise

Обмен данными между микросервисами

Один из классических вариантов применения любой системы очередей сообщений (и Tarantool Queue Enterprise в том числе) — микросервисы.

Ключевым требованием при разработке микросервисной архитектуры является обеспечение асинхронной коммуникации, разграничения нагрузки, устойчивости к сбоям и гибкого масштабирования.

Интеграция Tarantool Queue Enterprise в приложение на основе микросервисной архитектуры позволяет организовать шину данных, который связывает разные части приложения, гарантирует консистентность данных и позволяет распределять нагрузку между читающими микросервисами.

Для наглядности рассмотрим небольшой фрагмент микросервисной архитектуры с очередью.

Обмен сообщениями между микросервисом-отправителем (продюсером) и микросервисами-получателями (консьюмерами) происходит через очередь Tarantool Queue Enterprise. В данном случае каждый консьюмер обращается к своей очереди и обрабатывает сообщение только от нее. В реальности архитектуры могут сильно отличаться, как и взаимодействие между самими микросервисами.

TQE как основной движок электронных торгов

Еще один из сценариев применения очередей — системы электронных торгов.

В таких системах критически важны несколько параметров:

• Скорость — когда для клиента важны секунды, для работы самой системы важны микросекунды.
• Упорядоченность — все транзакции должны идти строго в том порядке, в котором поступили, и ни в коем случае не сдвигаться.
• Надежность — система должна быть устойчива к сбоям, критическим нагрузкам и другим рискам.
• Отсутствие дублирования данных — в финансовых потоках недопустимо, чтобы одна транзакция обрабатывалась несколько раз.

Tarantool Queue Enterprise:

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

При этом на уровне архитектуры сервис электронных торгов с Tarantool Queue Enterprise может работать следующим образом:

• инвесторы через свои личные кабинеты подают заявки на покупку или продажу каких-либо акций;
• все заявки упорядочено собираются в Tarantool Queue Enterprise;
• заявки из очереди строго последовательно передаются одному или сразу нескольким обработчикам, каждый из которых обрабатывает свой рынок.

Что в итоге

Очереди упрощают построение распределенной архитектуры — именно они являются связующим звеном, которое отвечает за стабильность и корректность взаимодействия отдельных компонентов. Коробочный продукт Tarantool Queue Enterprise подходит для создания очередей с различной архитектурой в зависимости от потребностей бизнеса.