Как масштабировать Kafka при высокой нагрузке

Что проверяют

Понимаете ли вы, где у Kafka узкое место: в брокерах, в партициях или в ваших потребителях. Следом обычно спрашивают, что будет с порядком сообщений, если увеличить число партиций у живого топика.

Как отвечать

Сначала диагностика, потом действия. Главная метрика это consumer lag: если он растёт, а брокеры не нагружены, проблема в потребителях, и новые брокеры не помогут. Lag, недореплицированные партиции и задержки запросов снимают через Prometheus (kafka_exporter, JMX exporter) и смотрят в Grafana.

Дальше рычаги по слоям:

• партиции: это единица параллелизма. В группе активно читают не больше потребителей, чем партиций в топике, лишние простаивают. Партиции можно только добавить, уменьшить нельзя;
• брокеры: новый брокер сам ничего не забирает. Существующие партиции переносят через kafka-reassign-partitions.sh или Cruise Control, иначе он получит только новые топики;
• продюсер: батчинг через linger.ms и batch.size, сжатие compression.type=zstd или lz4. Часто это даёт больше, чем новое железо;
• потребитель на Go: раздача сообщений из партиции в пул горутин ускоряет обработку, но ломает порядок и усложняет коммит. Коммитить можно только оффсет, до которого обработано всё;
• надёжность: replication.factor=3, min.insync.replicas=2, acks=all. Реплики повышают устойчивость, но не пропускную способность, они её тратят.

Упомяните, что в Kafka 4.0 ZooKeeper удалён, кластер работает на KRaft, а утилиты подключаются через --bootstrap-server.

Где спотыкаются

Добавляют партиции топику с ключами и не думают о последствиях. Раскладка hash(key) % partitions меняется, сообщения одного ключа начинают попадать в другую партицию, и порядок по ключу на время ломается.

Считают, что новые брокеры сразу разгрузят кластер. Без переназначения партиций старые брокеры держат прежнюю нагрузку.

Заводят тысячи партиций «с запасом». Это больше открытых файлов и памяти на брокерах, дольше выборы лидеров после сбоя и дольше перебалансировки группы потребителей.