Описание архитектуры

Tarantool Queue Enterprise (Message Queue) (TQE(MQ)) - это система для построения распределенной очереди сообщений для выполнения различных бизнес-задач:

• Обработка запросов к базе данных;
• Синхронизация различных сервисов;
• Проведение транзакций в финансовых системах и т.п.

На уровне набора реплик (шарда) TQE(MQ) гарантирует строгий порядок обработки сообщений (First in first out (FIFO)), а потребители получают только те сообщения, на которые подписаны. Это снижает избыточный трафик и повышает эффективность обработки.

Благодаря in-memory технологиям система способна справляться с пиковыми нагрузками без потери производительности, обеспечивая минимальные задержки и высокую пропускную способность.

TQE(MQ) представляет из себя набор микросервисов, которые отвечают за маршрутизацию и хранение сообщений. Такая архитектура обеспечивает горизонтальное масштабирование за счет шардирования и отказоустойчивость благодаря автоматическому переключению лидера (failover).

Данная статья описывает функции как TQE(MQ) в целом, так и функции микросервисов во взаимодействии с клиентом.

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

Как простая очередь TQE(MQ) работает по принципу FIFO, гарантируя строгую последовательность обработки. Как шина данных — позволяет одному отправителю доставлять сообщения множеству подписчиков и группам.

Брокер TQE(MQ) состоит из двух компонентов:

• модуль API – предоставляет интерфейс для взаимодействия с очередью посредством gRPC-протокола;
• ядро – выполняет функцию хранилища и представляет собой кластерное приложение на Tarantool.

Потребитель — внешний клиент (сервис или человек), инициирует запросы на публикацию или чтение сообщений по протоколу gRPC. Система принимает запросы, выполняет маршрутизацию и возвращает ответ. Внутри системы общение происходит по протоколу IPROTO.

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

Логическая инфраструктура TQE(MQ) содержит следующие узлы:

• Узел TQE gRPC API. Он принимает все входящие запросы и включает в себя 2 сервиса:
  • Producer — отвечает за публикацию сообщений;
  • ConsumerService — отвечает за чтение сообщений.
• Узел TQE Ядро. Ядро поддерживает следующие компоненты (логические роли):
  • roles.tqe-router — хранение конфигурации шардирования;
  • roles.tqe-storage — хранение сообщений и управление очередями;
  • roles.tqe-orchestrator - управление группами потребителей.

Такое разделение позволяет независимо масштабировать обработку запросов (API) и хранение данных (ядро), а также обеспечивает гибкость при развёртывании.

Обработка запроса от клиента включает следующие этапы:

• Запрос на чтение или публикацию сообщения поступает в gRPC API от потребителя.
• API отправляет запрос конфигураций шардирования в компонент roles.tqe-router для вычисления целевого набора реплик.
• API отправляет запрос в компонент roles.tqe-storage соответствующего набора реплик.
• Для запросов, относящихся к группам потребителей, API дополнительно обращается к roles.tqe-orchestrator, чтобы через него получить информацию:
  • Обо всех бакетах. При создании группы roles.tqe-orchestrator запрашивает информацию об этом у roles.tqe-router.
  • О состоянии подписок партиций. При создании группы потребителей roles.tqe-orchestrator запрашивает информацию об этом у roles.tqe-storage

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

Роли могут быть развернуты как на одном узле, так и на разных.

На уровне gRPC API сервис Producer направляет сообщения в наборы реплик, тогда как ConsumerService отвечает за запросы на получение сообщений из наборов реплик.

На уровне TQE Router (компонент roles.tqe-router) обеспечивается хранение конфигурации шардирования. Кластер строится по схеме мастер-реплика:

• Мастер — обработка изменений конфигурации;
• Реплика — обработка запросов чтения, резерв.

На уровне TQE Storage (компонент roles.tqe-storage) обеспечивается хранение сообщений. Данные распределяются по наборам реплик. Каждый набор содержит:

• Мастер, обеспечивающий запись и чтение сообщений.
• Реплики, ответственные за чтение сообщений и синхронизацию с мастером.

На уровне TQE Orchestrator (компонент roles.tqe-orchestrator) обеспечивается хранение состояния групп потребителей, их участников и распределения партиций. Кластер строится по схеме мастер-реплика:

• Мастер — обработка изменений состава групп, обновление данных синхронизации, запуск ребалансировки;
• Реплика — резерв.

В кластере TQE(MQ) можно выделить следующие типы взаимодействия:

1. Получение маршрутов: из gRPC API на мастер или реплику roles.tqe-router.
2. Публикация: из Producer в мастер набора реплик roles.tqe-storage.
3. Чтение: из ConsumerService в мастер или реплику roles.tqe-storage.
4. Запросы, связанные с группами потребителей: из ConsumerService в мастер roles.tqe-orchestrator.
5. Запросы о распределении бакетов: из roles.tqe-orchestrator в мастер или реплику roles.tqe-router.
6. Запросы о состоянии подписок партиций из roles.tqe-orchestrator в мастер набора реплик roles.tqe-storage.

Благодаря автоматическому переключению лидера (leader failover) система остаётся доступной при отказе мастера — реплика берет на себя его функции без потери сообщений. Такая архитектура гарантирует, что сообщения не теряются даже при сбоях, и обеспечивает максимальную пропускную способность за счёт параллельной обработки независимых наборов реплик. Более подробную информацию о сценариях взаимодействия с системой см. в руководстве по администрированию.