Компоненты архитектуры для обработки больших данных

Лямбда-архитектура

Каппа-архитектура

​

Архитектура обработки сообщений

https://www.enterpriseintegrationpatterns.com/patterns/messaging/index.html

Система обмена сообщениями

Плюсы MQ

Особенности такого решения:

• Service discovery - сервисам не нужно знать где и кто находится, достаточно просто бросить сообщение в очередь
• Выше доступность – если сервис упал, то он просто не берет запросы из очереди
• Ниже вероятность каскадных падений
• Горизонтальное масштабирование до некоторых пределов

Минусы MQ

Минусы message bus

• Latency увеличивается
• Debug становится сложнее
• Single Point Of Failure в виде брокера сообщений

Особенности MQ

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

​

• Для синхронного взаимодействия крайне неудобно использование асинхронного протокола (пробрасывание correlation-id и т.д и т.п)
• Оркестратора(типа Kubernetes-а) закрывает потребность в service discovery, горизонтальном масштабировании, доступности

Поэтому в чистом виде message bus в современном мире встречается редко.

Организация взаимодействия через MQ

Что в теле?

• JSON
• XML
• Protobuf
• Thrift
• Avro

Брокеры сообщений

• RabbitMQ
• Kafka
• ActiveMQ
• Mosquitto

• ...

RabbitMQ

Схема работы

• Отправитель шлет сообщение в exchange
• Exchange пересылает сообщения в очереди и другие exchange-и
• Rabbitmq шлет ack сообщение отправителю, как только сообщение принято

​

• Получатели поддерживают постоянное TCP соединение с Rabbitmq и описывают из каких очередей они читают сообщения
• Rabbitmq отправляет сообщение всем получателям
• Получатели шлют ack-и
• Сообщение удаляется из очередей, как только все получатели успешно прочли сообщение

Схема работы

• Можно добавлять как получателей, так и отправителей

Схема работы

• Можно добавлять как получателей, так и отправителей

Схема работы

• Можно добавлять как получателей, так и отправителей

Роутинг сообщений

В rabbitmq используется понятие exchange – фактически это правила маршрутизации.

Роутинг сообщений

Типов exchange-ей в rabbitmq – много, они предоставляют разные варианты маршрутизации:

• Direct
• Fanout
• Topic

и т.д.

Гарантии доставки

• At least once – хотя бы один раз. Сообщение гарантированно будет доставлено, но при этом может быть доставлено несколько раз
• At most once – максимум один раз. Сообщение будет доставлено максимум один раз, но при этом может быть и не доставлено совсем.

Push-модель для отправки сообщений

Rabbitmq использует push модель. Особенности такой модели:

• Низкий latency
• Легко добавлять новых получателей и распределять нагрузку

•

•

•

Легко может заддосить консьюмера (чтобы избежать есть QoS настройки) Широкие возможности для роутинга сообщений

Порядок сообщений не гарантирован

Kafka

Kafka

Kafka – это система, реализующая распределенный реплицируемый лог сообщений

• Распределенный – лог (топик) не целиком хранится на одной машине, а разбит на несколько секций (партиций), которые лежат на разных машинах
• Реплицируемый -- логи хранятся в нескольких копиях, на случай отказов оборудования
• Лог – это упорядоченная последовательность сообщений

Топик

Топик – это некоторый аналог таблички в БД.

​

• Топик – это чащего всего набор событий одного типа (customerCreated, notificationSent и т.д)
• Если вам нужно получить гарантии порядка, относящиеся к одному бизнес процессу, то в топик можно записывать сообщения (события) разных типов: customerCreated, customerInvoicePaid и т.д

​

Слишком большое количество (больше 1000) топиков (и партиций) в одном брокере приводит к снижению производительности. Поэтому сильно дробить на топики не стоит.

Топик

Топик – это набор неструктурированных сообщений (без схемы).

​

Для кафки – сообщение – это просто набор байт. Поверх которых можно использовать разные протоколы – JSON, Avro, Protobuf и т.д.

​

Чтобы появилась схема, используют внешние инструменты типа SchemaRegistry и StreamProcessing (KTable, KStream)

Топик

Kafka не имеет понятия очереди.

• Отправитель добавляет сообщение в распределенный лог сообщений
• Получатель (подписчик) читает из этого лога не прочтенные с прошлого раза записи

Offset

Каждый получатель (consumer) хранит у себя offset – указатель на сообщение, которое он прочитал последним.

Партиции

Топик разделен на несколько партиций.

Ключ

У сообщения в kafka может быть ключ - key. Если есть ключ, то тогда партиционирование происходит таким образом, чтобы сообщения с одним ключом попадали в одну партицию

Consumer groups

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

Для каждой consumer group, которая читает топик выделяется

• Group coordinator – это один из брокеров кафки назначает себя координатором группы consumerов и отвечает за состав группы и живость членов группы.
• Group leader – это один из консьюмеров в группе, назначается случайным образом group coordinator-ом, и потом group leader распределяет consumer-ов по партициям

Consumer и partition

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

Offset и Commit offset

offset – метка сообщения, которое консьюмер прочитал. Для того, чтобы понимать, какие сообщения сonsumer (получатель) обработал, используются

commit offset – последняя обработанная запись

Commit offset

Commited offsets хранятся в топике consumer_offsets, который находится у координатора группы (и реплицируется на остальные брокеры). При этом для разных consumer group и одного топика координатор может быть разным.

Перебалансировка

Иногда хочется добавить или удалить нового consumer-а в группу, или один из консьюмеров падает. В этом случае, consumer group переходит в состояние перебалансировки, во время которого ни один из консьюмеров не читает сообщения из топиков.

Репликация

В Kafka поддерживается репликация. Каждая партиция в топике может иметь несколько реплик.

​

В рамках каждого брокера (инстанса Кафки) может быть до тысячи реплик, относящихся к разных топикам.

Репликация

Авторы Kafka советуют

• фактор репликации 1, если вы ок, с тем, что можете эти данные потерять,
• фактор репликации 3, если хотите, чтобы данные остались в сохранности.

Фактор репликации 2 не советуют использовать из-за того, что в этом случае могут быть проблемы с тем, что кластер Kafka может развалится в некоторых ситуациях на старых версиях

Гарантии в Kafka

• Если producer отправил сообщение B после сообщения A в тот же самый топик, в той же самой партиции, то offset B будет больше A.
• Если producer отправил сообщение и все in sync replica-и подтвердили, что они сохранили у себя, то тогда сообщение можно считать закоммиченными.

• Закоммиченные сообщения не будут потеряны, пока хотя бы одна реплика жива
• Consumer-ы могут читать только закоммиченные сообщения.

Надежная отправка

При отправка сообщения producer может его отправить с параметром acks.

• acks = 0 означает, что если произошла отправка по сети, то отправка считается успешной (например, сообщение может быть потеряно во время выборов)
• acks = 1 означает, что отправка считается успешной, если лидер записал это сообщение на диск
• acks = all означает, что отправка считается успешной, если лидер и все in-sync-replica-и подтвердили приемку сообщения

Надежная отправка

Пусть будет topic с фактором репликации 3. В случае, если producer отправляет сообщения с параметром acks=1, то это может привести к потери сообщения.

Например, если лидер получил это сообщение, ответил producer-у, что все ок, но в этот момент упал, не успев отправить сообщение репликам. Тогда из оставшихся реплик будет выбран лидер, в котором этого сообщения не будет.

Надежная отправка

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

Для того, чтобы такого дублирования не было, Kafka умеет в идемпотентные сообщения, и рекламирует это как exactly once delivery гарантии.

Надежное получение

Есть разница между commited сообщениями и __commited_offset

• Commited – сообщения, которые были записаны на всех in sync replicaх
• Commited offset – это сообщения, которые были обработаны в рамках consumer group на каждой из партиций

Надежное получение

В случае если стоит опция auto_commit=true, то тогда консьюмеры коммитят последний полученный из poll offset раз в 5 секунд (интервал настраивается). Это означает, что если консьюмер упадет между двумя вызовами коммита, он успеет обработать какие-то сообщения, и при перебалансировке они снова будут обработаны.

Чтобы такого не случилось, можно синхронно коммитить после того, как сообщения были обработаны.

Pull - модель

Особенности push модели в реализации Kafka:

• Чуть хуже latency за счет ожидания перед каждым запросом данных
• Лучше сразу думать про масштабирование: добавление партиций приводит к ребалансингу
• Гарантированный порядок сообщений в рамках партиции

• Масштабирование из коробки
• Отказоустойчивость из коробки

Kafka vs RabbitMq

• Kafka
• Высокая пропускная способность (позволяет отправлять большие объемы данных достаточно быстро)
• Хранит сообщения даже после чтения - можно перечитать

• Репликация из коробки
• Сложнее в настройке и запуске
• RabbitMq
• Лучше Latency (быстрее проходят отдельные сообщения)
• Значительно гибче роутинг (exchange / bind / queue)