Настройка топиков и партиций Kafka: гид по конфигурации

Настройка топиков и партиций Kafka: гид по конфигурации

Представьте: вы запускаете прод, а consumer lag растёт, партиции перекошены, один брокер перегружен. Типичная ситуация при неправильной конфигурации топиков Kafka. Мы разберём, как спроектировать схему топиков, чтобы избежать таких проблем.

Количество партиций и фактор репликации — два параметра, которые нельзя легко изменить после создания топика. Уменьшить количество партиций невозможно без полного пересоздания топика. Поэтому правильная настройка при создании важна. Мы гарантируем, что при грамотном проектировании вы не столкнётесь с горячими узлами и лишними задержками.

Почему важна правильная конфигурация партиций?

Каждая партиция — единица параллелизма. Один консьюмер в группе обрабатывает одну партицию. Если топик имеет 6 партиций, максимум 6 консьюмеров в группе могут читать параллельно. Лишние консьюмеры простаивают. Плюс запись в партицию строго упорядочена. Глобальный порядок по топику не гарантируется — только внутри партиции. Это критично для событий, которые должны обрабатываться последовательно (например, все действия одного пользователя).

Пример: топик user-events с 6 партициями. События одного пользователя (user:101) могут попасть в разные партиции (0 и 1), что нарушает порядок обработки. Ключ сообщения решает проблему: hash(user_id) % num_partitions всегда даёт одну партицию.

Как создавать и настраивать топики?

Через kafka-topics.sh

# Базовый топик для событий пользователей kafka-topics.sh --bootstrap-server kafka-1:9092 \ --create \ --topic user-events \ --partitions 12 \ --replication-factor 3 \ --config retention.ms=604800000 \ --config retention.bytes=10737418240 \ --config compression.type=lz4 \ --config min.insync.replicas=2 \ --config message.max.bytes=1048576 # Компактный топик — для хранения последнего состояния по ключу kafka-topics.sh --bootstrap-server kafka-1:9092 \ --create \ --topic user-profiles \ --partitions 24 \ --replication-factor 3 \ --config cleanup.policy=compact \ --config min.cleanable.dirty.ratio=0.1 \ --config segment.ms=3600000 \ --config delete.retention.ms=86400000 # Высокоприоритетная очередь с коротким retention kafka-topics.sh --bootstrap-server kafka-1:9092 \ --create \ --topic order-processing-priority \ --partitions 6 \ --replication-factor 3 \ --config retention.ms=3600000 \ --config max.message.bytes=102400 

Программное управление через Admin API (Java/Kotlin) Создание топиков программно — правильно для приложений, которые создают топики динамически:

Properties props = new Properties(); props.put(AdminClientConfig.BOOTSTRAP_SERVERS_CONFIG, "kafka-1:9092,kafka-2:9092,kafka-3:9092"); props.put(AdminClientConfig.REQUEST_TIMEOUT_MS_CONFIG, 5000); props.put(AdminClientConfig.DEFAULT_API_TIMEOUT_MS_CONFIG, 10000); try (AdminClient admin = AdminClient.create(props)) { NewTopic userEvents = new NewTopic("user-events", 12, (short) 3); userEvents.configs(Map.of( "retention.ms", "604800000", "compression.type", "lz4", "min.insync.replicas", "2" )); NewTopic deadLetter = new NewTopic("user-events-dlq", 3, (short) 3); deadLetter.configs(Map.of( "retention.ms", "2592000000", // 30 дней "retention.bytes", "-1" )); CreateTopicsResult result = admin.createTopics(List.of(userEvents, deadLetter)); result.all().get(30, TimeUnit.SECONDS); } 

Изменение конфигурации существующего топика

# Увеличиваем retention kafka-configs.sh --bootstrap-server kafka-1:9092 \ --alter \ --entity-type topics \ --entity-name user-events \ --add-config retention.ms=1209600000 # Добавляем партиции (только увеличение!) kafka-topics.sh --bootstrap-server kafka-1:9092 \ --alter \ --topic user-events \ --partitions 24 # Внимание: добавление партиций нарушает порядок для ключевых сообщений. # Существующие ключи пойдут в те же партиции (hash % 12), # новые ключи будут распределяться по 24 партициям. # Просмотр конфигурации топика kafka-configs.sh --bootstrap-server kafka-1:9092 \ --describe \ --entity-type topics \ --entity-name user-events 

Управление лидерами и борьба с перекосом

Неравномерное распределение лидеров между брокерами приводит к горячим узлам:

# Проверяем распределение лидеров kafka-topics.sh --bootstrap-server kafka-1:9092 \ --describe --topic user-events # Предпочтительные реплики — перебалансировка лидеров kafka-leader-election.sh --bootstrap-server kafka-1:9092 \ --election-type preferred \ --all-topic-partitions # Или для конкретного топика через JSON cat > election.json << 'EOF' { "partitions": [ {"topic": "user-events", "partition": 0}, {"topic": "user-events", "partition": 1} ] } EOF kafka-leader-election.sh --bootstrap-server kafka-1:9092 \ --election-type preferred \ --path-to-json-file election.json 

Если consumer lag по одним партициям больше, чем по другим, проверьте ключи: плохая хэш-функция даёт перекос. Решение — увеличить количество партиций и использовать UniformStickyPartitioner (доступен в Kafka 2.4+). Альтернатива — перейти на RoundRobinPartitioner для логирования. Мониторинг партиций с помощью kafka-consumer-groups.sh:

# Consumer lag — отставание группы kafka-consumer-groups.sh --bootstrap-server kafka-1:9092 \ --describe --group my-consumer-group # Суммарный lag > 10000 для критичных топиков — повод для алерта 

Типовые конфигурации по типу данных

Сравнение: Kafka vs RabbitMQ для потоков данных

Apache Kafka лучше RabbitMQ в 3-5× по пропускной способности при высокой нагрузке (сотни MB/s). RabbitMQ выигрывает в гибкой маршрутизации (exchanges) и поддержке очередей с разными приоритетами. Для event sourcing и CDC Kafka — стандарт де-факто; для микросервисов со сложной маршрутизацией RabbitMQ может быть удобнее.

Процесс настройки и таймлайн

За 5 лет работы мы провели более 50 успешных внедрений Kafka. Наш подход:

• Анализ требований: оцениваем throughput, количество консьюмеров, требования к упорядоченности, retention. Проектируем схему топиков. Срок — 1 день.
• Создание топиков: настраиваем партиции, репликацию, compaction. Настраиваем ACL, если нужна аутентификация. Срок — 1–2 дня.
• Мониторинг: настраиваем consumer lag, алерты, документируем схему для команды. Срок — 1 день.

Мы предлагаем настройку под ключ: от проектирования до документации. Оценим ваш проект за 1 день — напишите нам.

Что входит в работу?

• Архитектурная документация: схема топиков, ключи, retention.
• Конфигурация брокеров и топиков.
• Настройка мониторинга и алертов.
• Обучение команды (2–4 часа).
• Поддержка в течение месяца после запуска.

Таймлайн

Правильная конфигурация партиций снижает задержки на 30% по сравнению с неоптимальной (по нашим данным). Получите консультацию по вашему проекту — свяжитесь с нами.

Подробнее об Apache Kafka.