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

Tarantool Queue Enterprise, функциональность MQ (далее — 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 — предоставляет интерфейс для публикации сообщений.
  • Consumer — предоставляет интерфейс для чтения сообщений.
• Узел TQE Ядро. Ядро поддерживает следующие компоненты (логические роли):
  • roles.tqe-router — хранит конфигурации шардирования.
  • roles.tqe-storage — хранит сообщения и управляет очередями.
  • roles.tqe-orchestrator - управление группами потребителей.

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

При запуске TQE(MQ), API запрашивает конфигурацию шардирования у компонента roles.tqe-router.

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

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

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

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

На уровне gRPC API сервис Producer отвечает за публикацию сообщений в наборы реплик, а Consumer — за получение сообщений из них.

На уровне 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. Чтение - из Consumer в мастер или реплику roles.tqe-storage.
4. Запросы, связанные с группами потребителей - из Consumer в мастер roles.tqe-orchestrator.
5. Запросы о распределении бакетов - из roles.tqe-orchestrator в мастер или реплику roles.tqe-router.
6. Запросы о состоянии подписок партиций - из roles.tqe-orchestrator в мастер набора реплик roles.tqe-storage.

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