Spring, kafka, неблокирующий retry, лаги

[remindscope]

Спасибо за интересный кейс.

С почином на Хабре!)

[DenSigma]

Интересно. Можно уточнить: кто делал pausePartition,

это потребитель-приложение ваше?

[Thedo]

да, это под капотом делает spring-kafka в ListenerContainerPauseService

[MishaBucha]

Спасибо за статью, механизм @RetryableTopic интересный, для маленьких приложений находка, чтобы не создавать велосипед)

@RetryableTopic Для хайлоада будет убийцей) У нас на проекте за ночь гоняются по 7-8 млн данных и такой алгоритм ретраев может создать жесткий Кафка лаг. Мы используем ручную отправку в dlq со сдвигом офсета, либо же в отдельную таблицу и обрабатываем в мультиинстансе шедулерами(все фиксируем руками, так как нам так надежнее и мы точно знаем, что происходит)

Но опять же, если нагрузка не очень большая, то супер вообще @RetryableTopic думаю зайдет на ура, особенно, если не хочется думать над логикой ретраев)

[simon_logic]

Меня больше интересует, почему сделали значение по-умолчанию 1. На эти грабли натыкаются абсолютно все, кто использует Spring. Дошло до того, что в каждый проект добавляю интеграционный тест на проверку размера пула.

[Thedo]

Да, согласен что это странно, хотя бы доступное количество ядер бы взяли

[simon_logic]

Вопрос по статье. У вас написано сколько ретраев, столько и топиков? Тут точно все в порядке с логикой?

[Thedo]

Пример: допустим нужно 4 попытки отправки.

Это дополнительные 4 топика от спринга для ретрая -retry-0, -retry-1, -retry-2, -dlx , последний это топик неудачных сообщений. И оригинальный топик еще.

Получается 4 попытки (оригинал -> 0, 0 -> 1, 1 -> 2, 2 -> dlx).

С точки зрения формулировки, да, правильнее говорить в таком случае именно 3 ретрая, если первую попытку не считать. Но в целом N топиков дополнительно создается для обеспечения N попыток отправки всего.