Комментарии 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 это же считается более современным подходом ?
Работа Apache Kafka на примерах. Поднимаем Kafka Cluster используя docker-compose