Retention и log compaction

Партиция на диске — не один файл, а последовательность сегментов: брокер пишет активный сегмент, а когда он вырастает до segment.bytes или стареет до segment.ms, закрывает его и открывает следующий. Это устройство важно, потому что чистка работает целыми сегментами, а не сообщениями: удалять середину файла невозможно, поэтому ретеншен действует с гранулярностью сегмента, и мелкие сегменты означают аккуратную чистку ценой большего числа открытых файлов. Настройки ретеншена ставятся на топик через ConfigEntries, знакомые по прошлому уроку. retention.ms — максимальный возраст сегмента: классические значения — сутки 86400000 или неделя 604800000; значение минус единица отключает чистку по времени, а дефолт брокера задаётся настройкой log.retention.hours и равен семи суткам. retention.bytes — максимальный суммарный размер партиции; по умолчанию минус единица, то есть безлимит. Как только лимит превышен, брокер начинает удалять старейшие закрытые сегменты, пока партиция не влезет, — запись при этом не останавливается ни на мгновение. Читатели старых оффсетов в этот момент получают ошибку OffsetOutOfRange: сегмент, где жил их позиция, уже удалён, и читать придётся с kafka.FirstOffset — самого раннего живого сегмента, а не с нуля.

Log compaction — второй режим чистки, включаемый брокерской настройкой топика cleanup.policy со значением compact. Правило простое: для каждого ключа в журнале должно остаться как минимум последнее значение, всё более старое компактор имеет право вычистить. Журнал после компакции ведёт себя как таблица key→value: перечитав его целиком, вы получаете актуальное состояние — последнюю цену по каждому тикеру, свежий конфиг каждого сервиса, текущий статус каждого заказа. Две гарантии отличают компакцию от обычной чистки. Первая: оффсеты никогда не меняются — компактор удаляет записи, но не переписывает журнал заново, поэтому порядок и позиции сохраняются, и коммиты групп из восьмого урока остаются валидными. Вторая: компакция не мгновенна — она выполняется фоновым потоком, когда «грязная» доля журнала дожимает min.cleanable.dirty.ratio, а свежие записи защищены min.compaction.lag.ms. Отсюда и обязательное условие: ключ. В компактед-топике запись без ключа не имеет смысла — чистить нечего, и продюсеру с балансировщиком Hash из пятого урока здесь самое место. Компакция выполняется фоновым потоком брокера: он сравнивает «грязную» долю журнала с min.cleanable.dirty.ratio и решает, пора ли запускать проход по сегментам, поэтому наблюдать результат моментально не приходится — это нормально и на локальном стенде тоже.

В таблице из лога нужен способ удалять строки, и он есть: tombstone — сообщение с ключом и пустым значением, nil в kafka-go. Это приказ «ключа больше нет»: компакция вычищает все значения ключа, а сам маркер с исчезновением delete.retention.ms — суток по умолчанию — удаляется и из топика. Итог: после маркера и достаточно долгого ожидания ключ исчезает целиком. Для консьюмера это и есть операция удаления из таблицы: не новый конфиг, а именно исчезновение строки, и обрабатывать её нужно в коде кеша, а не надеяться, что маркер как-то сам расскажет о себе. Тонкость, которая ломает наивных консьюмеров: tombstone — полноценное сообщение, оно доезжает до читателя с обычным ключом и nil-значением, и консьюмер обязан обрабатывать этот случай явно — удалить запись из локального кеша, а не пытаться декодировать пустоту. Вторая тонкость — время: между записью маркера и фактическим исчезновением ключа проходит delete.retention.ms, поэтому читать компактед-топик и наблюдать отсутствие ключа можно только с запасом. Третья — nil легален только для значения: ключ nil в Kafka равнозначен ключу-пустышке, и компакция для таких записей бесполезна, что делает ключ обязательным контрактом компактед-топика.

Оба механизма удаляют данные, но живут в разных измерениях, и сводить их в одну таблицу полезно перед выбором конфигурации. Ретеншен меряет время и байты: ему всё равно, какие у вас ключи, он честно стирает прошлое за горизонтом и превращает топик в окно событий. Компакция меряет ключи: она стирает прошлые версии каждого ключа, сохраняя настоящее, и превращает топик в снимок состояния. Практическое следствие — ключи нужны только во втором случае, а история значений сохраняется только в первом. Настройки чистки при этом ортогональны дефолтам брокера: топиковые значения перекрывают брокерские, как и min.insync.replicas в прошлом уроке. Выбор режима — это вопрос о читателе: если читателю нужен поток событий, берите ретеншен, если срез состояния — компакцию, и не переезжайте между режимами на живом топике, потому что компакция необратимо удалит историю, которая понадобится завтра. И ещё: cleanup.policy может нести оба значения сразу — compact,delete — компакция плюс окно времени, когда и последнее значение ключа нужно, и совсем старые ключи должны умереть. Такой гибрид типичен для конфигурационных топиков с обязательным временем жизни записей.

Компакция — про настоящее, и её первый предел — потребность в прошлом. История котировок для графика, аудит действий пользователя, ретроспективный разбор инцидента: всё это требует видеть значения, которые компактор уже вычистил, и компактед-топик здесь не поможет по построению. Рецепт — либо обычный топик с ретеншеном, либо база данных, где прошлое — первоклассный гражданин, а компактед-топик в паре хранит лишь текущее состояние. Второй предел — точные временные срезы: «как выглядела таблица в полдень» компакция не гарантирует, потому что чистка фоновая и её границы не совпадают с вашим вопросом. Третий — таблицы без естественного ключа: попытка скомпактировать поток событий без ключей превращает компакцию в бесполезный режим, а случайные ключи вроде идентификатора события делают журнал неотличимым от обычного, но с лишними обязательствами. Наконец, компакция не заменяет ретеншен по размеру: если ключей бесконечно много — сессии, заказы, чаты — журнал растёт с каждым новым ключом, и без retention.bytes или явного удаления tombstone'ами он взорвётся.