Следует ли делать 1-3 Partition и 10 Consumer

Партиции и консьюмеры в Kafka: оптимальное соотношение

Это классический вопрос при проектировании Kafka систем. Ответ однозначен: это плохая практика и следует избегать. Давайте разберёмся, почему, и как правильно организовать архитектуру.

Основной принцип: Consumer Group Partitioning

В Apache Kafka существует фундаментальное правило:

Максимальное количество активных консьюмеров в группе не должно превышать количество партиций топика.

Если партиций: P
То консьюмеров в группе: C ≤ P

Лучше всего, когда: C = P или C < P

Почему 1-3 партиции и 10 консьюмеров — плохо

1. Неиспользуемые консьюмеры

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

Топик: 3 партиции
Консьюмер группа: 10 консьюмеров

Распределение:
Partition 0 → Consumer 1
Partition 1 → Consumer 2
Partition 2 → Consumer 3
Consumer 4-10 → ❌ IDLE (ничего не делают)

2. Впустую потраченные ресурсы

// Каждый консьюмер требует ресурсов
@KafkaListener(topics = "orders", groupId = "order-group")
public void listen(String message) {
    // Обработка
}

// Результат: 7 из 10 консьюмеров просто сидят и потребляют память/CPU
// без полезной работы — расходуется 70% ресурсов впустую

3. Потеря преимуществ параллелизма

Па́раллелизм в Kafka достигается через партиции, а не через избыток консьюмеров:

❌ Плохо:        ✅ Хорошо:
3 партиции      10 партиций
10 консьюмеров  10 консьюмеров
70% idle        100% active, полный параллелизм

4. Rebalancing сложность

Каждый раз при добавлении/удалении консьюмера происходит rebalancing — процесс перераспределения партиций. С 10 консьюмерами это дороже и вызывает паузу в обработке.

Правильный расчёт количества партиций

Формула:

Требуемые партиции ≥ Максимальное количество консьюмеров

Пример расчёта:

// Требования:
// - 10 консьюмеров для обработки заказов
// - Хотим независимость между инстансами
// - Планируем масштабирование до 15 консьюмеров

// Правильное решение:
Количество партиций = 15 (с запасом на будущее)
Количество консьюмеров = 10 (текущее)
Результат: каждый из 10 получает партицию, 5 свободны для масштабирования

Архитектура: правильный подход

1. Одна консьюмер-группа

@Component
public class OrderConsumer {
    @KafkaListener(
        topics = "orders",
        groupId = "order-processing-group",
        concurrency = "10"  // 10 потоков на одном инстансе
    )
    public void processOrder(String message) {
        // Обработка
    }
}

// Запуск:
// Instance 1: 5 потоков (concurrency=5)
// Instance 2: 5 потоков (concurrency=5)
// Всего 10 потоков, обрабатывают 10 партиций

2. Несколько инстансов с параллелизмом

// application.yml
spring:
  kafka:
    consumer:
      group-id: order-group
      max-poll-records: 100
      session-timeout-ms: 30000
    listener:
      concurrency: 5  // 5 потоков на инстанс

// Развёртывание:
// Pod 1: 5 потоков (автоматически получает партиции 0-4)
// Pod 2: 5 потоков (автоматически получает партиции 5-9)
// Kubernetes масштабирует на 2 пода → 10 потоков обработки

Что если консьюмеров меньше, чем партиций?

Это НОРМА и даже ЖЕЛАТЕЛЬНО:

10 партиций
3 консьюмера

Consumer 1 → Partitions 0, 3, 6, 9
Consumer 2 → Partitions 1, 4, 7
Consumer 3 → Partitions 2, 5, 8

✅ Каждый консьюмер обрабатывает несколько партиций
✅ Полный параллелизм
✅ Эффективное использование ресурсов

Сценарии и рекомендации

Вывод и best practices

1. Никогда не создавайте консьюмеры, если их больше, чем партиций

// ❌ НЕПРАВИЛЬНО
топик: orders (3 партиции)
запустить 10 инстансов приложения с @KafkaListener
// Результат: 7 инстансов ничего не делают

// ✅ ПРАВИЛЬНО
топик: orders (10+ партиций)
запустить 10 инстансов приложения
// Результат: полный параллелизм

2. Планируйте партиции с запасом на будущее

Заранее рассчитайте:
- Текущая нагрузка
- Прогноз на год
- Пиковые нагрузки
- Масштабирование в будущем

Партиции = (планируемые консьюмеры) × 1.5 (буфер)

3. Используйте concurrency для параллелизма на одном инстансе

spring.kafka.listener.concurrency: 10
# Значит один инстанс обрабатывает до 10 партиций параллельно

Итог: Никогда не делайте 1-3 партиции с 10 консьюмерами. Это приведёт к впустую потраченным ресурсам, усложнению архитектуры и невозможности масштабирования. Инверсное соотношение (много партиций, меньше консьюмеров) гораздо предпочтительнее.