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).

Почему?
Представьте: вы поставили replication.factor=3, а min.insync.replicas=3. Это значит, что все 3 брокера должны подтвердить запись. Если упадет всего 1 брокер, условие (3) перестанет выполняться, и топик заблокируется на запись. Это слишком строгое требование, которое убивает отказоустойчивость. Поэтому классическая рекомендация для production: replication.factor=3, min.insync.replicas=2.
🧠 Итоговое резюме

    min.insync.replicas — это ваш "предохранитель" от молчаливой потери данных.

    Если для вас каждое сообщение бесценно (финансовые транзакции, заказы), ставьте 2 (при 3 репликах) и настройте продюсеров на acks=all. Это даст гарантию, что сообщение записано минимум на 2 сервера.

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

Этот параметр задается на уровне топика при создании, но также может быть переопределен для конкретного топика через kafka-configs.sh даже после его создания.

Мы углубились в настройки надежности. Хотите, чтобы я рассказал про replication.factor или про то, как настраивать продюсеров (acks, retries), чтобы полностью закрыть тему гарантий доставки?