# Topics

**Тема**

Сообщение:

- значение (value) - данные, обязательное
- (partition number)
- ключ (key) -

**Создание темы (topic)**

[![image.png](http://bobrobotirk.ru/uploads/images/gallery/2026-09/scaled-1680-/image.png)](http://bobrobotirk.ru/uploads/images/gallery/2026-09/image.png)

<table border="1" id="bkmrk-%D0%9F%D0%BE%D0%BB%D0%B5-%D0%A2%D0%B8%D0%BF-%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85-%D0%9E%D0%BF%D0%B8%D1%81" style="border-collapse: collapse; width: 100%; height: 1897.08px;"><colgroup><col style="width: 24.3147%;"></col><col style="width: 16.9337%;"></col><col style="width: 58.7516%;"></col></colgroup><thead><tr style="height: 29.7969px;"><td class="align-center" style="height: 29.7969px;">Поле</td><td class="align-center" style="height: 29.7969px;">Тип данных</td><td class="align-center" style="height: 29.7969px;">Описание</td></tr></thead><tbody><tr style="height: 29.7969px;"><td style="height: 29.7969px;">Topic Name </td><td style="height: 29.7969px;">Строка</td><td style="height: 29.7969px;">Название темы.</td></tr><tr style="height: 855.969px;"><td style="height: 855.969px;">Number of partitions</td><td style="height: 855.969px;">Целое число</td><td style="height: 855.969px;">Количество разделов — управление производительностью и масштабируемостью кластера. Единицы параллелизма в Kafka. Разделы определяют скорость и масштабирование.

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

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

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

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

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

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

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

</td></tr><tr style="height: 832.531px;"><td style="height: 832.531px;">Cleanup policy</td><td style="height: 832.531px;">Список.

- Delete
- Compact
- Compact, Delete

</td><td style="height: 832.531px;">Политика управления сроком жизни данных. По умолчанию delete.

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

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

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

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

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

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

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

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

Например:

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

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

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

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

**Как выбрать?**

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

</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">Min in sync replicas</td><td style="height: 29.7969px;">Целое число</td><td style="height: 29.7969px;">Минимальное количество брокеров-подписчиков, которые должны подтвердить запись, чтобы она считалась успешной.

Иначе — это порог, защищающий от потери данных при сбое брокеров.  
**Как это работает (в связке с 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).

</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">Replication factor</td><td style="height: 29.7969px;">Целое число</td><td style="height: 29.7969px;">Фундамент отказоустойчивости. Определяет, сколько всего копий каждого раздела будет храниться в кластере 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

<table border="1" style="border-collapse: collapse; width: 100.224%; height: 199.375px;"><colgroup><col style="width: 34.9853%;"></col><col style="width: 64.8173%;"></col></colgroup><tbody><tr style="height: 80.1875px;"><td style="height: 80.1875px;">Отказоустойчивость</td><td style="height: 80.1875px;">Чем выше фактор, тем больше брокеров может выйти из строя без потери данных. RF=3 переживает падение 2 брокеров (при min.insync.replicas=2).</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">Доступность на чтение</td><td style="height: 29.7969px;">При падении лидера новый выбирается из ISR. Чем больше реплик, тем выше шанс, что хотя бы одна синхронизирована.</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">Дисковое пространство</td><td style="height: 29.7969px;">RF=3 означает, что каждый байт данных хранится трижды. Это напрямую увеличивает требования к диску в 3 раза.</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">Сетевой трафик</td><td style="height: 29.7969px;">Каждая репликация — это дополнительный трафик между брокерами. Чем выше RF, тем больше нагрузка на сеть.</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">Скорость записи</td><td style="height: 29.7969px;">Запись успешна после подтверждения от min.insync.replicas. Больше реплик — дольше ожидание, выше latency.</td></tr></tbody></table>

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

- 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 — про параллелизм.

</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">Time to retain data</td><td style="height: 29.7969px;">Целое число, ms</td><td style="height: 29.7969px;">определяет время хранения сообщения в топике перед удалением. По умолчанию 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 позволяет комбинировать два независимых ограничения:

<table border="1" style="border-collapse: collapse; width: 100.224%;"><colgroup><col style="width: 33.1933%;"></col><col style="width: 33.1933%;"></col><col style="width: 33.1933%;"></col></colgroup><tbody><tr><td>Параметр</td><td>Ограничивает</td><td>Когда срабатывает</td></tr><tr><td>retention.ms</td><td>время хранения</td><td>Сегмент старше указанного времени</td></tr><tr><td>retention.bytes</td><td>размер раздела</td><td>Суммарный размер сегментов превышает лимит</td></tr></tbody></table>

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

</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">Maximum message size in bytes</td><td style="height: 29.7969px;">Целое число, bytes</td><td style="height: 29.7969px;">Потолок одного пакета. Но пакеты могут объединяться, так что потолок может быть превышен.</td></tr><tr style="height: 29.7969px;"><td style="height: 29.7969px;">Custom parameters</td><td style="height: 29.7969px;">Разные</td><td style="height: 29.7969px;">Дополнительные параметры для тонкой настройки.</td></tr></tbody></table>