Мы подготовили гайд для тех, кто только начинает знакомиться с Kafka и хочет понять, как она работает и чем отличается от традиционных систем обмена сообщениями.
Что такое Apache Kafka?
Apache Kafka —
это система, которая помогает приложениям обмениваться данным в реальном времени. Она способна собирать, хранить и передавать большие объёмы информации между программами. Kafka полезна, когда речь идет о быстрой обработке данных, например сообщения от клиентов.
Простыми словами: это группа серверов, которые работают вместе, чтобы обрабатывать непрерывный поток данных в реальном времени.
Kafka называют распредёленной потоковой платформой. Это означает, что инструмент работает не на одном компьютере, а одновременно на нескольких, объединенных в один кластер. Каждый узел (отдельный компьютер или, как принято называть, нода) в кластере называется Broker.
Простыми словами: брокеры — это серверы с запущенной Apache Kafka, а Kafka — это набор машин, работающих вместе, чтобы обрабатывать большой объем бесконечных данных в реальном времени.
Kafka популярна распределенной архитектурой, что позволяет ей быть надёжной, масштабируемой, отказоустойчивой и производительной.
Перед тем как разобраться, как работает Kafka, важно понять основы традиционного обмена сообщениями, чтобы наглядно увидеть ее уникальность.
Традиционный обмен сообщениями
Производитель (Producer)
Очередь
Потребитель (Consumer)
Архитектура Kafkа
Топик — это тип потока данных, напоминающий очередь: он также принимает и отправляет сообщения, но имеет несколько особенностей, таких как:
Разделы (или партиции) — это части топика, на которые он разбивается
Ключ сообщения
Каждое сообщение сохраняется на диске брокера и получает уникальный идентификатор — offset (смещение)
Offset — это уникальный идентификатор сообщения внутри конкретной партиции, который позволяет отслеживать его положение в потоке данных. Каждое новое сообщение добавляется в конец партиции и получает свой собственный offset.
К примеру:
- Первое сообщение получит offset = 0
- Второе сообщение получит offset = 1
- Третье сообщение получит offset = 2
Консьюмеры используют offset, чтобы отслеживать, какие сообщения они уже прочитали и обработали
Удаление сообщений в Kafka управляется двумя основными параметрами:
01
02
Структура Apache Kafka. Понятие кластера. Что такое Брокер?
Кафка Кластер (Kafka Cluster) —
это группа серверов (брокеров), которые работают совместно и обеспечивают надёжную и масштабируемую обработку и передачу данных. Объединяя несколько брокеров, кластер распределяет нагрузку, что обеспечивает отказоустойчивость системы.
Брокер (Broker) —
это сервер, который принимает и хранит данные, а также обрабатывает запросы от клиентов, например данные о заказах и платежах, поступающих от мобильного приложения и веб-сайта магазина. В кластере Kafka может быть один или несколько брокеров, что обеспечивает надёжность и масштабируемость системы. Если один брокер выйдет из строя, остальные продолжат работу, не теряя данных.
Слева изображена примерная схема Kafka Cluster.
ZooKeeper (Зукипер) —
это служба, которая следит за состоянием всего Kafka Кластера. Она отслеживает, какие брокеры активны и какую информацию они хранят. ZooKeeper можно сравнить с дирижером в оркестре: он координирует взаимодействие между компонентами, обеспечивая синхронизацию и согласованность данных. Перевод ZooKeeper с английского в прямом смысле означает «Смотритель зоопарка». Подразумевается, что он отслеживает все, что в нашем «зоопарке» происходит.
Хранение информации
Выбор лидера
Мониторинг состояния
Управление конфигурацией
В кластере Kafka каждый брокер имеет уникальный ID и хранит хотя бы одну партицию для каждого топика, а также копии других партиций для обеспечения отказоустойчивости.
На схеме изображен топик «Топик 1» с тремя партициями, распределенными между тремя брокерами: каждая партиция имеет основную копию (Leader) на одном из брокеров и две резервные копии (Followers) на других. Параметр Replication Factor в данном случае равен 3, то есть каждая партиция хранится на трех брокерах. Такой подход обеспечивает надёжность: при сбое одного из брокеров данные останутся доступными благодаря репликам на других брокерах.
Важно, чтобы количество партиций соответствовало количеству брокеров — так каждый брокер будет управлять одной партицией.
Для надёжности Kafka использует концепцию лидера партиции. Лидер — это основной брокер для каждой партиции, и только он принимает новые сообщения, синхронизируя их с репликами на других брокерах. Если лидер выходит из строя, ZooKeeper автоматически назначает новым лидером одну из его реплик, чтобы данные оставались доступными.
Для более простого примера, упростим схему нашего Kafka Cluster.
Далее определим лидера и фолловера партиции.
В таком случае репликация будет выглядеть следующим образом:
Consumer, Producer и их особенности
Продюсеры в Kafka —
это программы, которые создают и отправляют сообщения в темы (топики), как и в других системах обмена сообщениями.
По умолчанию сообщения распределяются по партициям топика с помощью метода round-robin, чтобы равномерно распределить нагрузку. Например, сообщение 01 может попасть в партицию 0, а сообщение 02 — в партицию 1. Это означает, что сообщения одного продюсера могут быть распределены по разным партициям, и порядок их доставки не гарантируется.
Чтобы гарантировать, что все сообщения с определённой логикой попадут в одну и ту же партицию, можно использовать ключ. Kafka создаст хеш этого ключа и отправит все сообщения с одинаковым ключом в один и тот же раздел, сохраняя порядок.
Важно учитывать, что этот механизм зависит от количества разделов. После создания топика количество разделов изменить нельзя, чтобы не нарушить порядок сообщений.
Что такое ACKS?
Acks = 0
Acks = 1
Acks = all
ISR (In-Sync Replicas) — это группа реплик, синхронизированных с лидером. Давайте рассмотрим подробнее, как это работает:
Продюсер отправляет сообщение лидеру партиции
Лидер передает данные фолловерам
Фолловеры подтверждают синхронизацию
Лидер отправляет финальное подтверждение продюсеру
Потребители и потребительские группы
Порядок чтения сообщений выглядит следующим образом:
Один потребитель — одна партиция
Один потребитель — несколько партиций
Потребители и потребительские группы
Принципы работы потребительских групп:
Распределение партиций
Масштабируемость
Отказоустойчивость
Параметр Retries
Retries —
это параметр, который указывает, сколько раз продюсер будет пытаться повторно отправить сообщение, если первая попытка не удалась.
Если продюсер не получил подтверждение в соответствии с настройками acks, он попытается отправить сообщение заново. Число повторных попыток ограничивается значением retries. Например, если retries = 3, продюсер попробует отправить сообщение до трех раз, если предыдущие попытки не удались. Это помогает компенсировать временные проблемы с сетью или перегрузку брокеров.
Важно:
Повторные отправки увеличивают нагрузку на сеть и могут привести к дублированию сообщений. Поэтому retries лучше всего использовать вместе с acks = all, чтобы гарантировать надёжность доставки и избежать дублирования данных.
Как правильно настроить acks и retries для минимизации потерь сообщений?
Acks и retries — лишь малая часть параметров, влияющих на надёжность Kafka. Разобрать их все в одной статье невозможно.
Но есть еще одна важная тема, о которой стоит поговорить — семантика доставки сообщений. Она напрямую связана со всем, что мы обсудили выше, и играет ключевую роль в гарантии корректности передачи данных.
Семантика доставки сообщений в Apache Kafka
At-most-once (не более одного раза)
At-least-once (как минимум один раз)
Exactly-once (ровно один раз)
Транзакции —
это механизм, позволяющий продюсеру гарантировать, что несколько операций записи (например, запись нескольких сообщений в один или несколько топиков) будут либо полностью зафиксированы, либо полностью отменены.
Вывод
Этот материал — фундамент для работы с Apache Kafka. Понимание этих концепций поможет вам эффективно настраивать систему для обработки данных в реальном времени, обеспечивая ее надёжность и производительность. Однако это лишь отправная точка: чтобы глубже погрузиться в возможности инструмента, важно продолжать изучение и экспериментировать с настройками в реальных проектах.
