Одним из популярных брокеров сообщений является Apache Kafka. Kafka первоначально разрабатывалась в LinkedIn. В 2011 году код был опубликован, а с 2012 года разработку ведет Apache.
Название брокер получил в честь писателя Франц Кафка, который, как известно, не дописывал свои произведения
Брокер Kafka обладает рядом преимуществ:
Без брокера сообщений возникают следующие сложности в общении между производителями и потребителями:
Поэтому появляется прослойка в виде брокера сообщений
Брокер принимает сообщения, хранит и выдает их. Чтобы система была более отказоустойчивой, брокеров делают несколько и их объединяют в кластер. Таким образом, появляется возможность масштабирование и репликации сообщений
Другая сущность, Zookeeper, управляет кластером брокеров. Zookeeper следит за состоянием кластера, конфигурацией и решает, что делать, если упал какой-то узел. Zookeeper выбирает какого-то брокера и назначает его контроллером, который следит за консистентность. В последних версиях в Kafka реализован алгоритм Raft: брокеры сами знают о своей конфигурации и решают, что делать, если мастер-узел перестал работать
Само сообщение содержит:
При приеме сообщения брокер кладет его в топик. Топик хранит в себе очередь (поток) сообщений. Эта очередь может быть разделена на части (партиции) для параллелизации. Эти партиции для удобства могут располагаться на разных брокера внутри кластера
Сами сообщения хранятся на диске так:
/.../kafka-logs/
├── my-topic-0/ # Партиция 0 топика "my-topic"
│ ├── 00000000000000000000.log # Сегмент лога (сами сообщения)
│ ├── 00000000000000000000.index # Индекс для быстрого поиска
│ ├── 00000000000000000000.timeindex # Индекс по времени
│ ├── 00000000000000012345.log # Следующий сегмент
│ └── ...
├── my-topic-1/ # Партиция 1 топика "my-topic"
│ └── ...
└── __consumer_offsets/ # Служебный топик для хранения оффсетов потребителей
.log – бинарный файл, содержащий сами сообщения (ключ, значение, метаданные).
.index – индекс для быстрого поиска сообщений по оффсетам (смещениям).
.timeindex – индекс для поиска по временным меткам.
Если .log-файл превышает максимальный размер файла в системе, то создается новый файл с названием <id нового сообщения>.log
При этом Kafka отдельные сообщения удалить не может, однако поддерживается автоматическое удаление по time-to-live (время, которые сегменты хранятся на диске), тогда удаляются целиком сегменты партиций
Если какой-то брокер падает, то его партиции в топике становится недоступной. Поэтому партиции реплицируют на другие брокеры. Какая-то из партиций назначается лидером, и все операции записи и чтения производятся через нее. Далее она копирует данные на другие партиции-реплики. Если брокер с партицией-лидером падает, то другая партиция становится лидером
Проблема может возникнуть в распределении лидерских партиций по брокерам. Если все лидерские партиции окажутся на одном брокере, то он станет узким горлышком в системе
Оптимально ставить количество реплик равное числу узлов-брокеров, уменьшенному на 1
Партиции-реплики обычно сами периодически посылают запросу брокеру с лидерской партицией (pull-модель), чтобы обновить свои данные. Однако, если лидер упадет, то данные на репликах могут быть не полными. Для решения этого вводятся синхронизированные реплики (in-sync replicas), запись в которых производится лидерской партицией (push-модель), таким образом данные в них актуальные, а сами они могут быть приоритетными кандитатами при падении лидера
При отправке сообщения через продюсер можно установить степень осведомленности о его обработке:
acks = 0 означает, что продюсер не ждет подтверждение отправки сообщенияacks = 1 означает, что продюсер ждет подтверждение только от лидерской репликиacks = -1 означает, что продюсер ждет подтверждение от всех синхронизированных репликПотребитель же принимает сообщения из лидерских партиций какого-либо топика. Для дополнительной параллелизации может быть несколько потребителей, каждый из которых принимает сообщения из какой-либо партиции и которые объединены в группу потребителей
Чтобы отслеживать, какие сообщения были обработаны потребителями, существует специальный топик __consumer_offsets. При обработке сообщений потребителем потребитель отправляет сообщение с именем топика, номером партиции, идентификатором группы потребителей и номером последнего сообщения. Таким образом, при падении потребителя, другим потребителями внутри группы не придут уже обработанные сообщения
Почему Kafka быстрая:
Apache Kafka популярное и надежное решение, однако для работы с ней нужно понимать все нюансы и тонкости