Как стать автором
Обновить

Комментарии 8

Семантика Exactly once очень дорогая и влечёт вместе с собой определенные риски. Так например, мы можем получить блокировку при отправке, поскольку данные могут не реплицироваться из‑за упавшей реплики или же уже после обработки сообщения

Именно эта семантика и требуется в большинстве случаях. То что она дорогая - далеко не факт. Зависит от того, что мы собираемся с этими данными делать.
Мы не получим блокировку при отправке, ибо коммитить офсеты в кафке надо после успешной обработки, а не после получения сообщения. Для этого и придуманы ручные подтверждения.

Эта семантика потребуется лишь в банковской сфере или нечто подобном, где она не столько дорога, сколько необходима.

С помощью ручных подтверждений мы всё ещё можем получить блокировку в случае если произойдут проблемы с сетью, неправильной обработке исключений, сообщений, неправильной конфигурации самой кафки.

Можно даже просто недосмотреть и подтверждать получение до окончания полной обработки и потерять сообщение

Эта семантика потребуется лишь в банковской сфере или нечто подобном, где она не столько дорога, сколько необходима.

С помощью ручных подтверждений мы всё ещё можем получить блокировку в случае если произойдут проблемы с сетью, неправильной обработке исключений, сообщений, неправильной конфигурации самой кафки.

Можно даже просто недосмотреть и подтверждать получение до окончания полной обработки и потерять сообщение

а где в коде задается число консьюмеров в группе? Читается в 4 потока, но не очень понятно, как это связано с числом консьюмеров в группе.

Число потоков никак не связано с числом консюмеров. В наших группах (2 группы) по одному консюмеру, как видно из кода:

@KafkaListener(
            id = "consumer-group-1",
            topics = "${kafka.topics.test-topic}",
            containerFactory = "kafkaListenerContainerFactory")
    public void handle(@Payload JsonMessage message) {
        readMessage(message);
    }

    @KafkaListener(
            id = "consumer-group-2",
            topics = "${kafka.topics.test-topic}",
            containerFactory = "kafkaListenerContainerFactory")
    public void handle2(@Payload JsonMessage message) {
        readMessage(message);
    }

метод handle относится является первым (и единственным) консюмером в консюмер группе consumer-group-1
метод handle2 относится является первым (и единственным) консюмером в консюмер группе consumer-group-2

В общем случае нет необходимости консюмеров в рамках одного инстанса приложения разносить в разные консюмер группы. Сам инстанс нашего приложения уже будет одной консюмер группой

А что означает параметр "KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR" в докер-файле?

Я так понимаю, что данные о смещениях в группах реплицируются между брокерами. Тогда для кластера из 2х брокеров наверно стоит ставить значение 2 ?

Да, верно. Спасибо, что указали на этот момент. Конечно, можно оставить этот параметр равным единице, но так снизим отказоустойчивость и надежность системы. Я поправил в статье. Также стоит отметить, что этот параметр должен быть меньше или равен числу брокеров в кластере

почему не в режиме kraft mode это же считается более современным подходом ?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории