Кафка: в чем смысл использования «cknowledgement.nack », если я могу просто« не подтвердить.acknowledge » - PullRequest
Новая
       91

Кафка: в чем смысл использования «cknowledgement.nack », если я могу просто« не подтвердить.acknowledge »

0 голосов
/ 16 июня 2020

Что касается новой функции Kafka, направленной на отрицательное подтверждение и теперь поддерживаемой Spring-Kafka, согласно / spring-kafka / docs / 2.4.4.RELEASE /

".. . Начиная с версии 2.3, интерфейс Acknowledgment имеет два дополнительных метода: nack (длительный сон) и nack (int index, long sleep). Первый используется со слушателем записи, второй - с пакетным слушателем. Вызов неправильного метода для ваш тип слушателя выдаст исключение IllegalStateException.

...

С слушателем записи, когда вызывается nack (), любые ожидающие смещения фиксируются, оставшиеся записи из последнего опроса отбрасываются , и поиск выполняется в их разделах, так что неудавшаяся запись и необработанные записи повторно доставляются при следующем опросе (). Потребительский поток может быть приостановлен перед повторной доставкой , установив аргумент сна. Это аналогичные функции для создания исключения, когда контейнер настроен с помощью SeekToCurrentErrorHandler. "

* 1 012 * Что ж, если на стороне потребителя произойдет какая-то ошибка, скажем, не удалось сохранить в базе данных, скажем, потребитель не подтверждает.acknowledge (), насколько я понимаю, сообщение все еще находится в опросе, и оно будет прочитано / использовано очередной раз. Я предполагаю, что кто-то может сказать, что с nack (..., некоторое время) потребитель может спать, давая возможность читать / потреблять снова немного позже и не сталкиваться с ошибкой. Если продолжать слушать topi c не проблема, мой прямой вопрос:

есть ли какой-нибудь дополнительный смысл использовать nack вместо того, чтобы просто не подтверждать?

Насколько я могу см. сообщение будет храниться в пуле дольше, чем спишь. Так что, кстати, если потребитель будет продолжать попытки получить сообщение и сохранить сообщение, он будет успешным, если проблема будет устранена менее, чем за время сна. уведомил, что используется nack. Если это так, я мог бы найти какую-то ценность в каком-то конкретном c сценарии ios. Скажем, при использовании Log Compation (интересует только статус последнего сообщения) или Kafka в качестве службы долгосрочного хранения (я думаю, в будущих версиях это будет - KIP 405 )

В более общем плане исключения Я обычно использую такие подходы, как , настраиваю SeekToCurrentErrorHandler и генерирую исключение

1 Ответ

1 голос
/ 16 июня 2020

nack - это просто альтернатива использованию SeekToCurrentErrorHandler - он был добавлен до того, как мы сделали SeekToCurrentErrorHandler обработчиком ошибок по умолчанию (ранее по умолчанию просто регистрировалась ошибка).

STCEH более сложен в том, что вы можете настроить количество повторных попыток, настроить средство восстановления, вызываемое после исчерпания повторных попыток (например, DeadLetterPublishingRecoverer).

nack отличается от «не подтверждать»; в последнем случае, если вы не генерируете исключение, вы получите следующую запись из опроса (или следующий опрос, если это была последняя запись); вы не получите повторную доставку неподтвержденной записи, если вы не используете nack или STCEH и не вызовете исключение.

...