Что происходит, когда к одному топику Kafka подключаются несколько consumer'ов из одной consumer group?

Kafka использует модель, в которой единицей параллелизма является не топик, а партиция. Топик делится на N партиций, и внутри одной consumer group каждая партиция закрепляется ровно за одним consumer'ом. Это гарантирует, что сообщения из одной партиции обрабатываются последовательно и одним потребителем, что упрощает работу с offset'ами и порядком сообщений.

Как распределяются партиции

Распределение выполняет Group Coordinator (один из брокеров) с помощью стратегии assignor (Range, RoundRobin, Sticky, CooperativeSticky). Правила простые:

• Одна партиция — максимум один consumer внутри группы.
• Один consumer может держать несколько партиций.
• Если consumer'ов больше, чем партиций, часть consumer'ов останется без работы.

Пример

Топик с 4 партициями и 2 consumer'ами в группе: каждый получит по 2 партиции. Если добавить третьего consumer'а, произойдёт rebalance, и партиции перераспределятся (например, 2-1-1). Если consumer'ов станет 5, один будет простаивать.

// Пример конфигурации consumer'а
Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("group.id", "order-service");
props.put("key.deserializer", StringDeserializer.class);
props.put("value.deserializer", StringDeserializer.class);

KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);
consumer.subscribe(List.of("orders"));

while (true) {
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));
    for (ConsumerRecord<String, String> r : records) {
        process(r); // обработка сообщения
    }
    consumer.commitSync(); // фиксация offset'ов
}

Rebalance и его последствия

Когда consumer присоединяется, выходит или считается мёртвым (по session.timeout.ms), координатор запускает rebalance. Во время rebalance потребление останавливается (в eager-протоколе), что может вызывать задержки. CooperativeSticky assignor минимизирует остановки, перераспределяя только затронутые партиции.

Практические следствия

• Максимальный параллелизм группы ограничен числом партиций топика.
• Порядок сообщений гарантирован только внутри партиции, не по всему топику.
• Ключ сообщения определяет партицию, поэтому для сохранения порядка по сущности используйте стабильный ключ.
• Разные группы читают топик независимо, каждая со своими offset'ами.

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