топ-вопросов по kafka, которые спрашивают на собеседованиях

Чтение в Kafka организовано через консьюмеров — процессы, которые подключаются к брокерам и получают сообщения из топиков. Основной механизм построен на consumer-группах.

Когда консьюмер подключается, он указывает group.id — обязательный параметр. Консьюмеры с одинаковым group.id автоматически объединяются в одну группу. Kafka гарантирует, что каждая партиция топика будет обрабатываться только одним консьюмером внутри группы, что обеспечивает корректное распределение нагрузки.

Например, у нас есть топик my-topic с тремя партициями и consumer-группа test1 с двумя консьюмерами. Kafka распределит партиции между консьюмерами: первый консьюмер получит первую партицию, второй — две оставшиеся.

Если консьюмеров больше, чем партиций, часть консьюмеров будет простаивать. Например, при трех партициях и четырех консьюмерах четвертый консьюмер не получит данных.

Но Kafka динамически перераспределяет партиции: если один из работающих консьюмеров отключается, простаивающий консьюмер автоматически берет его партиции и продолжает обработку.

Топик может обслуживать сколько угодно consumer-групп. Каждая группа получает полный поток сообщений, но внутри группы партиции делятся между консьюмерами.

Это позволяет разным системам использовать один и тот же топик независимо: одна группа может заниматься аналитикой, другая — поиском аномалий, третья — отправкой уведомлений.

В Kafka каждое сообщение внутри партиции имеет порядковый номер — оффсет. Оффсет служит консьюмеру для отслеживания позиции чтения внутри партиции.

Например, представим топик с одной партицией (partition 0), в которой лежат четыре сообщения: A, B, C, D. Их оффсеты будут:

• A → 0
• B → 1
• C → 2
• D → 3

Когда консьюмер из группы test читает топик, он может фиксировать свой прогресс. Если прочитаны сообщения A и B, консьюмер сообщает Kafka, что дошел до оффсета 1.

Kafka сохраняет эту информацию персистентно, так что позиция чтения группы надежно зафиксирована в кластере.

Если консьюмер внезапно падает, новый консьюмер из той же группы при подключении запрашивает у Kafka текущий оффсет группы: «До какого оффсета мы уже дочитали?» Kafka отвечает: «До оффсета 1». Новый консьюмер начинает читать с оффсета 2.

Еще одно ключевое преимущество Kafka — возможность повторного чтения сообщений. Пока данные хранятся в топике (не истек период retention), консьюмер может сдвинуть оффсет назад и перечитать сообщения.

Сдвинуть оффсет можно несколькими способами. Например, стандартная CLI-утилита kafka-consumer-groups позволяет указать:

• брокера Kafka;
• consumer-группу;
• топик;
• конкретную партицию и новый оффсет.

После этого Kafka обновляет сохраненный оффсет, и консьюмер начинает чтение с указанной позиции.

Прежде всего важно понимать, зачем нам нужен гарантированный порядок обработки.

Рассмотрим пример из банковской сферы. Допустим, у нас есть топик, в который поступают операции по счетам: клиент сначала пополняет счет на 500 рублей, а затем оплачивает покупку, например, бургер за 500 рублей. Обе операции записываются в Kafka как два отдельных сообщения.

Сообщения будут прочитаны консьюмерами в произвольном порядке. Если списание произойдет раньше пополнения, система попытается списать средства с пустого счета — это приведет к ошибке и недовольству клиента.

Kafka обеспечивает строгий порядок внутри партиции благодаря двум свойствам:

• внутри consumer-группы одну партицию читает только один консьюмер;
• консьюмер читает сообщения последовательно по оффсетам.

В писателях kafka есть настройка partitioner.class. Если разработчик не указывает ни партицию, ни кастомный partitioner, используется дефолтный алгоритм:

Хэш вычисляет Kafka SDK внутри метода send(), разработчику вручную ничего делать не нужно.

Если в нашем примере ключом сообщения является account_id, все операции по одному счету будут иметь одинаковый ключ. Соответственно, хэш ключа одинаков, и все сообщения с этим ключом попадут в одну и ту же партицию, если количество партиций неизменно. Консьюмер будет читать их строго последовательно, сохраняя порядок операций.

Для таких задач, как сбор логов, телеметрия или аналитические потоки, порядок между событиями не критичен, а важна равномерная нагрузка на партиции.

В этом случае можно использовать:

В коротком итоге, если нужно сохранить строгий порядок, используем один и тот же ключ для связанных сообщений — Kafka гарантирует последовательное чтение внутри одной партиции. Но если важна равномерная нагрузка, применяем round-robin или кастомный partitioner.

На первый взгляд кажется, что всё просто: по умолчанию сообщения удаляются через 7 дней, согласно настройке retention policy. Но на практике механизм немного сложнее. Kafka не отслеживает каждый отдельный message и не удаляет его по отдельности. Для понимания процесса важно разобраться с понятием сегмента.

Физически Kafka сохраняет данные в сегмент-файлах на диске. Каждая партиция топика состоит из последовательности сегментов. Удаление сообщений привязано именно к удалению сегмента.

Сегмент закрывается в двух случаях:

• когда достигает максимального размера segment. bytes (по умолчанию 1 ГБ);
• когда прошёл заданный период жизни сегмента segment. ms (по умолчанию 7 дней).

Ключевой момент: Kafka удаляет данные целыми сегментами. Сегмент удаляется, когда у последнего сообщения внутри него прошёл ретеншн-период.

Разберем пример: сегмент содержит 7 сообщений, по одному на день: 1, 2, 3, 4, 5, 6, 7, при retention.ms = 7 дней. Когда у первого сообщения пройдут 7 дней, сегмент не удаляется сразу. Удаление произойдет только после того, как ретеншн пройдет у последнего сообщения в сегменте.

Удаление по времени — не единственный механизм. Kafka поддерживает политику компактификации (compaction):

Kafka позволяет гибко управлять компактификацией через min.compaction.lag.ms — минимальное время хранения перед удалением старых сообщений по ключу. Например, можно оставить полную ретеншн-политику на год, а компактификацию по ключу делать раз в неделю.

Таким образом, в Kafka нельзя удалить отдельное сообщение по конкретному оффсету вручную. Данные удаляются либо целыми сегментами после истечения ретеншн-периода, либо постепенно по ключам при компактификации.

Это действительно один из сложных вопросов, потому что однозначного ответа нет. Практически любую задачу можно реализовать и через Kafka-топик, и через очередь RabbitMQ, но особенности технологий влияют на удобство реализации и затраты усилий.

Топики можно распределять на разные брокеры, что позволяет выдерживать значительно большую нагрузку, чем обычная очередь. Поэтому Kafka — хороший выбор для сценариев с высокой нагрузкой, где стандартная очередь может не справиться.

Роутинг сообщений — это процесс распределения сообщений между потребителями таким образом, чтобы разные группы читателей получали разные типы данных.

Например, один потребитель может быть подписан на все события, связанные с банковскими операциями по всей стране, а другой — только на события, которые происходят в Москве.

В случае очередей это обычно реализуется достаточно просто: потребитель задает правило или шаблон, по которому он хочет получать сообщения. Например, в RabbitMQ можно указать шаблон вида card.create и использовать маску, например звездочку, чтобы получать сообщения из всех городов или только из Москвы.

Например, если вы захотели фильтровать сообщения не по городам, а по странам, то сделать это уже не получится, если такого хедера просто нет. Аналогично, если вы хотите фильтровать сообщения по конкретному банковскому клиенту, это также невозможно без соответствующего хедера.

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

В топиках Kafka подход другой. Там чаще всего приходится писать отдельное приложение, которое уже по заданной бизнес-логике распределяет сообщения по разным топикам. Это даёт больше гибкости, потому что вы можете использовать ESQL или любой другой язык программирования и самостоятельно описывать правила маршрутизации сообщений для разных потребителей.

В очередях RabbitMQ сообщения читаются по порядку: первый воркер берет первое сообщение, второй — второе и так далее.

В Kafka консьюмер-группа делит партиции между воркерами, и каждый получает целую партицию.

Однако есть нюансы: если добавить нового консьюмера, он не начнет получать сообщения, пока не добавлены новые партиции. В очередях новый воркер сразу начинает читать сообщения.

Ещё один момент, который нужно учесть — это блокировки в Kafka: если одно сообщение не может быть обработано, последующие ждут.

Оба инструмента подходят. Разница в том, что Kafka лучше масштабируется, а очереди проще настраиваются для фильтрации. Важно проводить нагрузочные тесты, чтобы убедиться, что выбранный инструмент выдержит вашу нагрузку.

Kafka часто используют для телеметрии и логирования: логи приложений отправляются через Kafka в промежуточное хранилище. Существуют готовые фреймворки: Logstash, Fluentd, Telemetry Frameworks.

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

Kafka часто выступает промежуточным слоем для ETL: собирает данные с баз данных, приложений, мобильных устройств и передает их в аналитические хранилища.

Kafka Connect — open-source фреймворк, который позволяет подключить источники данных и публиковать их в Kafka.

Данные можно выгружать в Hadoop, ClickHouse, Greenplum и другие системы.

Очереди обычно для таких задач не применяются, так как не позволяют многократное чтение данных для разных целей.

Мы разобрали пять ключевых вопросов про Kafka: как читаются сообщения через consumer-группы, зачем нужен оффсет, как гарантировать порядок обработки, когда удаляются данные и когда выбирать Kafka вместо обычной очереди. Понимание этих основ дает вам полный контроль над потоками данных и архитектурой системы.

Даже если кажется, что вопросы сложные, не стоит бояться собеседования. Разобрав принципы работы Kafka, вы сможете объяснить всё на примерах и показать, что реально понимаете, как строится надёжная обработка событий.