Кафка сбросить раздел повторно потреблять или нет - PullRequest
0 голосов
/ 12 ноября 2018

Если я сам использую свою тему и управляю смещением, некоторые обрабатываемые мной записи успешны, тогда я перемещаю смещение вперед, но иногда я обрабатываю записи, которые выдают исключение. Мне все еще нужно переместить смещение вперед. Но позже мне нужно будет сбросить смещение и повторно обработать ошибочные записи. Возможно ли при смещении установить флаг, чтобы сказать, что если я потреблю это событие снова, проигнорирую или потреблю?

Ответы [ 2 ]

0 голосов
/ 12 ноября 2018

Лучший способ обработать эти записи - это не сбросить смещения, а использовать очередь недоставленных сообщений , по сути, отправив их в другой раздел kafka для последующей обработки позже.Таким образом, ваш основной потребитель может сосредоточиться на обработке записей, которые не генерируют исключения, а некоторые другие потребители могут постоянно слушать и пытаться обрабатывать записи, которые выдают ошибки.

Если этот второй потребитель по-прежнему генерирует исключения при попытке повторно обработать сообщения, вы можете либо отправить их в одну очередь, если исключение вызвано временной проблемой (система временно недоступна, проблема с базой данных,сетевое сообщение и т. д.) или просто выберите запись идентификатора и содержимого сообщения, а также лучшее предположение о том, в чем заключается проблема, для того, чтобы кто-то мог посмотреть позже.

0 голосов
/ 12 ноября 2018

На самом деле - нет, это невозможно.Записи Кафки только для чтения.Я видел этот пример использования на практике, и я постараюсь дать вам несколько советов:

  • , если у вас возникла ошибка, просто скопируйте сообщение в отдельном разделе об ошибках и продолжайте.Это позволит вам в любое время воспроизвести все сообщения об ошибках из раздела об ошибках.Это определенно было бы моим предпочтительным решением - гибким и производительным.
  • при возникновении ошибки - просто повесьте своего потребителя - желательно войти в бесконечный цикл с экспоненциальным откатом, перечитывая одно и то же сообщение снова и снова.Мы использовали эту стратегию вместе с хорошим мониторингом / предупреждением и уплотнением журнала.Если что-то идет не так, мы либо исправляем неисправного потребителя и повторно используем наш сервис, либо, если само сообщение было сломано, производитель исправит ошибку, повторно опубликует сообщение с тем же ключом, и сжатие журнала будет активировано. Неисправное сообщение будет удалено (журналуплотнению).На этом этапе мы сможем продвигать наших потребителей вперед.Это требует ручного взаимодействия в большинстве случаев.Если причиной сбоя является проблема с сетью (например, сбой базы данных), потребитель может восстановиться самостоятельно.
  • использовать локальное хранилище (например, базу данных) для хранения данных о сбоях смещения.Затем сбросьте смещение и проигнорируйте успешно обработанные записи.Это мое наименее предпочтительное решение.
...