Да, верно. Спасибо, что указали на этот момент. Конечно, можно оставить этот параметр равным единице, но так снизим отказоустойчивость и надежность системы. Я поправил в статье. Также стоит отметить, что этот параметр должен быть меньше или равен числу брокеров в кластере
Вроде статья называется "как начать тестировать бэкенд?", но по сути это лишь краткое описание инструментов (спасибо, что краткое), отличие БТ от ФТ, советы (некоторые странные, особенно если учитывать, что материал для тех кто уже долго в этом варится) и никакой конкретики
Поиск по тексту не нашёл таких ключевых фраз как: модульное тестирование, unit, юнит, qa, интеграционное тестирование
Может быть это не про то "как" тестировать, а "чем"? А "как" это делается мы узнаем позже?
Число потоков никак не связано с числом консюмеров. В наших группах (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
В общем случае нет необходимости консюмеров в рамках одного инстанса приложения разносить в разные консюмер группы. Сам инстанс нашего приложения уже будет одной консюмер группой
Эта семантика потребуется лишь в банковской сфере или нечто подобном, где она не столько дорога, сколько необходима.
С помощью ручных подтверждений мы всё ещё можем получить блокировку в случае если произойдут проблемы с сетью, неправильной обработке исключений, сообщений, неправильной конфигурации самой кафки.
Можно даже просто недосмотреть и подтверждать получение до окончания полной обработки и потерять сообщение
Эта семантика потребуется лишь в банковской сфере или нечто подобном, где она не столько дорога, сколько необходима.
С помощью ручных подтверждений мы всё ещё можем получить блокировку в случае если произойдут проблемы с сетью, неправильной обработке исключений, сообщений, неправильной конфигурации самой кафки.
Можно даже просто недосмотреть и подтверждать получение до окончания полной обработки и потерять сообщение
Да, верно. Спасибо, что указали на этот момент. Конечно, можно оставить этот параметр равным единице, но так снизим отказоустойчивость и надежность системы. Я поправил в статье. Также стоит отметить, что этот параметр должен быть меньше или равен числу брокеров в кластере
Знаете, я и сам своего рода мануальный тестировщик
Вроде статья называется "как начать тестировать бэкенд?", но по сути это лишь краткое описание инструментов (спасибо, что краткое), отличие БТ от ФТ, советы (некоторые странные, особенно если учитывать, что материал для тех кто уже долго в этом варится) и никакой конкретики
Поиск по тексту не нашёл таких ключевых фраз как: модульное тестирование, unit, юнит, qa, интеграционное тестирование
Может быть это не про то "как" тестировать, а "чем"? А "как" это делается мы узнаем позже?
Число потоков никак не связано с числом консюмеров. В наших группах (2 группы) по одному консюмеру, как видно из кода:
метод handle относится является первым (и единственным) консюмером в консюмер группе consumer-group-1
метод handle2 относится является первым (и единственным) консюмером в консюмер группе consumer-group-2
В общем случае нет необходимости консюмеров в рамках одного инстанса приложения разносить в разные консюмер группы. Сам инстанс нашего приложения уже будет одной консюмер группой
Эта семантика потребуется лишь в банковской сфере или нечто подобном, где она не столько дорога, сколько необходима.
С помощью ручных подтверждений мы всё ещё можем получить блокировку в случае если произойдут проблемы с сетью, неправильной обработке исключений, сообщений, неправильной конфигурации самой кафки.
Можно даже просто недосмотреть и подтверждать получение до окончания полной обработки и потерять сообщение
Эта семантика потребуется лишь в банковской сфере или нечто подобном, где она не столько дорога, сколько необходима.
С помощью ручных подтверждений мы всё ещё можем получить блокировку в случае если произойдут проблемы с сетью, неправильной обработке исключений, сообщений, неправильной конфигурации самой кафки.
Можно даже просто недосмотреть и подтверждать получение до окончания полной обработки и потерять сообщение