Kafka в эксплуатации

Consumer lag и его причины, ребаланс и безопасный commit, poison-сообщения, ZooKeeper → KRaft, schema evolution, изменения partitions и ключевые метрики.

Consumer lag

Consumer lag — разница между концом партиции (latest offset на брокере) и текущим закоммиченным offset группы. Это главный сигнал здоровья обработки: лаг должен оставаться в приемлемых границах под нагрузкой.

Растёт лаг из-за медленной обработки, упавшей зависимости (БД/HTTP), слишком больших batch'ей, частых ребалансов, или просто нехватки партиций/консьюмеров — параллелизм группы ограничен числом партиций.

Rebalance в эксплуатации

Ребаланс перераспределяет партиции между consumer'ами группы. В классическом «eager»-протоколе обработка вся группа останавливается на время; cooperative-sticky (Kafka 2.4+) минимизирует движение и не делает полного STW.

Главная опасность — потерять прогресс или сдублировать обработку при отдаче партиции. Через ConsumerRebalanceListener.onPartitionsRevoked коммитят уже обработанное и завершают in-flight работу до того, как партиция уйдёт к другому consumer'у.

consumer.subscribe(List.of("orders"), new ConsumerRebalanceListener() {
    public void onPartitionsRevoked(Collection<TopicPartition> p) {
        commitProcessedOffsets(); // безопасно отдать партиции
    }
    public void onPartitionsAssigned(Collection<TopicPartition> p) { /* warm up */ }
});

Poison messages

Сообщение, которое стабильно ломает обработчик, блокирует партицию: consumer снова и снова падает на одном offset и не двигается дальше — лаг растёт, остальные сообщения этой партиции стоят. Один кривой ключ может остановить целый поток.

Лечат тремя слоями: ретраи с backoff (transient ошибки), ограниченное число попыток и DLQ при исчерпании, плюс обязательный алертинг и владелец DLQ с процедурой redrive. DLQ без владельца — это просто скрытая потеря данных под видом «обработки».

ZooKeeper → KRaft

Исторически Kafka хранила метаданные кластера (контроллер, ACL, конфиги, ISR-состояния) в отдельном ZooKeeper-кластере. Это давало два разных кластера в эксплуатации со своими отказами и медленный failover контроллера.

Современный режим — KRaft (Kafka Raft): метаданные живут внутри самой Kafka через raft-консенсус среди выделенных controller-нод. Меньше компонентов, быстрее failover, проще операции. В Kafka 4.0 (2025) ZooKeeper удалён полностью: KRaft — единственный режим, а старые кластеры перед обновлением мигрируют на него.

Schema evolution

События переживают версии сервисов: продюсер уже обновился, а старые consumer'ы ещё читают. Добавление optional-поля обычно совместимо назад (старые читатели его игнорируют), а удаление поля или смена типа требует плана миграции и согласования с потребителями.

Schema Registry с compatibility rules (BACKWARD/FORWARD/FULL) превращает «договорённость» в проверяемый на лету контракт: попытка опубликовать несовместимую схему отклоняется. Avro/Protobuf со Schema Registry — стандартный набор.

Изменение partitions

Увеличение числа партиций повышает потолок параллелизма группы, но меняет hash(key) % numPartitions: новые сообщения того же ключа могут поехать в другую партицию, тогда как старые остались в прежней. Это разрыв порядка по ключу.

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

Ключевые метрики

Минимальный набор для алертинга. Consumer lag по группам и партициям — рост говорит «обработка не успевает». Under-replicated partitions (URP) — должно быть 0; ненулевое значение значит, что follower'ы отстают и долговечность под угрозой. Request latency producer/consumer, throughput in/out per topic, состояние ISR (схлопывание = алерт).

На стороне брокера — диск (заполнение и iops), сеть, CPU и количество open files; на стороне приложения — длительность обработки сообщения и доля ошибок в DLQ. Без мониторинга всё это превращается в внезапные инциденты.

Как отвечать на собеседовании

Назовите consumer lag главным сигналом здоровья и его причины (обработка/зависимости/число партиций). Объясните безопасный ребаланс через onPartitionsRevoked и важность cooperative-sticky. Разберите poison message и трёхслойную защиту (ретраи+лимит+DLQ с владельцем). Упомяните сдвиг ZooKeeper → KRaft. Покажите понимание schema evolution через Registry compatibility и почему добавление партиций ломает порядок по ключу. В конце — минимальный набор метрик (lag, URP, latency, ISR, диск/сеть).