Topics

Количество разделов — управление производительностью и масштабируемостью кластера. Единицы параллелизма в Kafka. Разделы определяют скорость и масштабирование.

• Для производителей (Producers): несколько разделов позволяет отправлять данные параллельно. Больше разделов — выше общая пропускная способность на запись.
• Для потребителей (Consumers): ключевой момент. В одной группе потребителей (consumer group) каждый раздел может обрабатываться только одним потребителем. Количество разделов определяет максимальное число потребителей в группе, которые могут работать параллельно.

Пример: для 10 разделов можно запустить до 10 потребителей, и каждый будет обрабатывать свой раздел. Если потребителей больше, чем разделов, то лишние потребители будут простаивать и тратить ресурсы впустую .

Дополнительные факторы

• Гарантируется порядок сообщений только внутри одного раздела. Если критичен порядок событий (например, все действия одного пользователя должны обрабатываться последовательно),  используется ключ сообщения (key). Все сообщения с одним ключом всегда попадают в один и тот же раздел, сохраняя порядок.
• Каждый раздел это доп. нагрузка (больше файлов, больше метаданных, больше времени на выборы лидера). Слишком большое количество разделов может привести к нестабильности и деградации производительности .
• Количество разделов можно только увеличить, но не уменьшить. Увеличение числа разделов приводит к перебалансировке потребителей и может изменить способ распределения сообщений по ключам, что нарушит порядок.

Практические рекомендации

• Для большинства новых тем начинать с 6–12 разделов. Это  хороший баланс между производительностью и управляемостью.
• Расчет от потребностей. Если один раздел обрабатывает 10 МБ/с, а нужно 100 МБ/с, то потребуется как минимум 10 разделов .
• Учет роста. Число разделов должно быть с запасом на 2-3 года роста.
• Согласование с потребителями. Количество разделов кратно (или равно) максимальному числу потребителей, которое планируется запускать для параллельной обработки .

Выбор "Number of partitions" — это всегда компромисс между желаемой производительностью, требованиями к порядку данных и операционными затратами на поддержку кластера.

Список. 

• Delete
• Compact
• Compact, Delete

Политика управления сроком жизни данных. По умолчанию delete.

Политика delete (Удаление)

Удаление старых данных по истечении заданного времени или при превышении лимита размера.

Как это работает: удаление когда старше retention.ms (по умолчанию 7 дней), или когда общий размер раздела превышает retention.bytes. Происходит в фоновом режиме с заданным интервалом.

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

Политика compact (Сжатие)

Эта политика работает по принципу "сохранить только последнее известное состояние" для каждого ключа сообщения .

Как это работает: В фоновом режиме для каждого уникального ключа (key) в разделе остается только последнее по времени сообщение, а все промежуточные удаляет. Сообщения обязаны иметь ключ (key), без ключа будут удалены при сжатии.

Когда применять: для хранения состояние или конфигурации.

Например:

•  Таблица с актуальными данными пользователей (адрес, почта)
•  Информация о текущем статусе заказа.
•  Список доступных товаров на складе.
•  Внутренний топик Kafka __consumer_offsets, где хранятся текущие смещения потребителей, по умолчанию использует именно эту политику .

Комбинированная политика delete,compact

Как это работает: сначала удаляются старые данные по времени/размеру, а затем сжимается оставшийся лог. Это полезно, когда нужно ограничить общий объем данных и гарантировать, что для каждого ключа в пределах этого срока хранения сохранится только последнее значение.
Важные нюансы

• Изменяемость: политику можно изменить для уже существующего топика без перезапуска кластера.
• Смена политики: переключение с delete на compact возможно, но требует осторожности. При включении сжатия сообщения без ключа будут потеряны.
• Производительность: сжатие требует дополнительных ресурсов ЦП и ввода-вывода, так как в фоне работает специальный "чистильщик" (Log Cleaner). При неправильной настройке он может повлиять на производительность брокера.

Как выбрать?

Важна ли полная история событий или только их текущее состояние? Если история — выбирайте delete. Если состояние — выбирайте compact.

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

Иначе — это порог, защищающий от потери данных при сбое брокеров.
Как это работает (в связке с ack)

Работает в паре с настройкой продюсера acks (подтверждения). У топика replication.factor = 3 (3 копии данных на разных брокерах), а min.insync.replicas = 2.

• Продюсер отправляет сообщение с настройкой acks=all (или acks=-1), что означает: "Жди подтверждения от всех реплик, которые сейчас в синхронизации".
• Брокер-лидер принимает сообщение и ждет, пока его сохранят у себя как минимум 2 брокера (лидер + 1 реплика-подписчик).
• Только когда эти 2 подтверждения получены, лидер отправляет продюсеру ответ об успешной записи.

Ключевой момент: если в кластере внезапно упадут 2 брокера из 3, и в живых останется только 1 (лидер), то условие min.insync.replicas=2 перестанет выполняться. В этом случае брокер откажется принимать новые сообщения и вернет продюсеру ошибку NotEnoughReplicasException.

Компромисс: Надежность vs Доступность

Это выбор между Consistency (согласованностью) и Availability (доступностью) из теоремы CAP.

Высокое значение (например, 2 или 3):

        ✅ Плюс: Максимальная надежность. Вы гарантированно не потеряете данные, даже если несколько брокеров выйдут из строя.

        ❌ Минус: Риск недоступности. Если выйдет из строя больше брокеров, чем min.insync.replicas, топик станет read-only, пока не починят брокеры или не уменьшите параметр.

Низкое значение (например, 1):

        ✅ Плюс: Максимальная доступность. Топик всегда будет принимать данные, даже если у вас работает всего 1 брокер из 3.

        ❌ Минус: Риск потери данных. Если лидер упадет в момент, когда он единственный хранил новое сообщение (остальные реплики еще не получили его), это сообщение будет потеряно безвозвратно.

Правило настройки (Золотое правило)

При настройке топика нужно строго соблюдать соотношение:

    min.insync.replicas ≤ replication.factor

И, что важнее, для реальной отказоустойчивости min.insync.replicas должно быть ≤ (replication.factor - 1).

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

Есть топик с replication.factor = 3. Это значит, что каждый раздел этого топика будет физически скопирован на 3 разных брокера.

Для каждого раздела Kafka выбирает:

• 1 Лидера (Leader) — брокер, который обрабатывает все чтения и записи для этого раздела.
• N-1 Подписчиков (Followers) — брокеры, которые просто копируют данные у лидера и ждут своего часа.

Репликация происходит на уровне разделов, а не топиков целиком. Если в топике 10 разделов и replication.factor=3, то в кластере будет храниться 30 копий этих разделов (10 разделов × 3 реплики).
Как это работает: 

• Продюсер пишет данные → они попадают к лидеру раздела.
• Лидер сохраняет данные у себя и реплицирует их на всех подписчиков.
• Подписчики копируют данные и отправляют лидеру подтверждение.
• Лидер ждет нужное количество подтверждений (то самое min.insync.replicas) и отвечает продюсеру.

Что происходит при сбое:

• Если лидер падает, Kafka выбирает нового лидера из числа синхронизированных подписчиков (In-Sync Replicas, ISR).
• Если падает подписчик, он просто выпадает из ISR, но данные не теряются, пока жив лидер и хотя бы min.insync.replicas реплик.

На что влияет replication.factor

Правила настройки

• replication.factor должен быть ≥ 3 для production

    RF=1 — любая потеря брокера = потеря данных. Только для dev/test.

    RF=2 — переживает падение 1 брокера. Но при обслуживании кластера (rolling restart) вы остаетесь без запаса.

    RF=3 — стандарт индустрии. Переживает падение 2 брокеров, позволяет обслуживать кластер без простоя.

• replication.factor ≤ количество брокеров в кластере

Если у вас 3 брокера, вы не можете поставить RF=5 — Kafka не сможет разместить все реплики. Максимум = число брокеров.

• Связка с min.insync.replicas

Классическая production-конфигурация:
text

replication.factor = 3
min.insync.replicas = 2
acks = all

Это дает: данные записаны минимум на 2 брокера, и кластер переживает падение 1 брокера без потери доступности на запись.
Важные нюансы

• replication.factor задается при создании топика и может быть увеличен позже (через kafka-reassign-partitions.sh), но не может быть уменьшен без пересоздания топика.
• Реплики распределяются автоматически по брокерам с учетом rack awareness (если настроено). Kafka старается разместить реплики на разных стойках/зонах доступности.
• ISR (In-Sync Replicas) — это динамический список реплик, которые полностью синхронизированы с лидером. Только они могут стать новым лидером. Если подписчик отстает (например, из-за сети), он исключается из ISR.
• replication.factor не влияет на количество партиций — это независимые параметры. RF — про копии, partitions — про параллелизм.

определяет время хранения сообщения в топике перед удалением. По умолчанию 7 дней (168 часов). Есть два уровня настройки: на уровне брокера и на уровне конкретного топика.

Удаление происходит по сегментам, а не по сообщениям

Kafka не удаляет отдельные сообщения. Лог раздела разбит на сегменты (segments). Параметр retention.ms определяет, когда закрытый (неактивный) сегмент становится кандидатом на удаление.

Что это значит на практике:

    Активный сегмент (тот, в который сейчас пишутся данные) никогда не удаляется, даже если его сообщения «просрочены».

    Проверка на удаление запускается периодически (по умолчанию каждые 5 минут), а не мгновенно.

    Дополнительная задержка в 1 минуту (file.delete.delay.ms) перед физическим удалением файла.

Пример из практики (низкая нагрузка)

Вы хотите хранить данные 1 день, но у вас мало сообщений. Активный сегмент не «закрывается» (не достигает лимита по размеру segment.bytes или времени segment.ms), поэтому он живет долго.

Результат: сообщения могут храниться до 2 дней (1 активный сегмент + 1 неактивный), хотя вы задали retention.ms=1 день.
Сравнение с retention.bytes

Kafka позволяет комбинировать два независимых ограничения:

Практические рекомендации
Логи приложений    3–7 дней (достаточно для отладки)
Метрики и мониторинг    1–3 дня
События для аналитики    7–30 дней
Комплаенс/аудит    90+ дней