Налаштування топіків та партицій 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.