Почему разные консьюмер-группы не конфликтуют за одно сообщение?

Почему разные консьюмер-группы не конфликтуют за одно сообщение?

Фундаментальная архитектура Kafka

Kafka использует уникальный подход к организации потребления сообщений, который позволяет разным группам консьюмеров независимо читать из одного топика. Ключ к пониманию этого лежит в архитектуре offset management (управление смещениями) и изоляции групп друг от друга.

Независимость консьюмер-групп

Каждая консьюмер-группа (consumer group) — это логически независимая сущность, которая имеет:

• Собственный offset — позиция в каждом разделе (partition) топика
• Собственное имя (group.id) для идентификации
• Собственное состояние в Kafka, хранящееся в служебном топике __consumer_offsets

Это означает, что Group A может читать сообщения с offset 0, в то время как Group B одновременно читает с offset 1000 из того же раздела. Каждая группа отслеживает свою позицию независимо.

Как это работает на практике

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("group.id", "group-a");
props.put("auto.offset.reset", "earliest");
KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);

consumer.subscribe(Collections.singletonList("events"));

while (true) {
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));
    for (ConsumerRecord<String, String> record : records) {
        System.out.println("Group A: " + record.value());
    }
}

Механизм разделения нагрузки внутри группы

Важный момент: внутри одной группы каждый раздел (partition) назначается только одному консьюмеру. Это гарантирует, что сообщение из конкретного раздела будет обработано только один раз в пределах группы.

Сравнение с другими системами

В отличие от RabbitMQ (где сообщение удаляется после первого потребления) или JMS queues (где конкурирующие консьюмеры делят сообщения), Kafka не удаляет сообщения при прочтении. Сообщение остаётся в топике, а Kafka просто запоминает, какой offset прочитала каждая группа.

Практический пример

Kafka хранит offset'ы каждой группы отдельно:

• Group A: partition 0 -> offset 500
• Group B: partition 0 -> offset 100

Это позволяет реализовать различные сценарии: real-time processing и batch analytics одновременно, backups и live processing, независимые потребители с разными SLA.

Ключевые преимущества

1. Масштабируемость — множество приложений независимо потребляют один топик
2. Репроцессинг — группа может вернуть offset и перечитать данные
3. Гибкость — новая группа стартует с любой позиции (earliest/latest)
4. Durability — данные в брокере не удаляются после потребления

Конфликтов не возникает, потому что Kafka разделяет ответственность за отслеживание позиции между группами.