Избегайте потери данных при обработке сообщений от Kafka

Question

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

Мой вариант использования такой, как показано ниже.

a) Причина, по которой я использую СЕРВИС для обработки сообщения, - в будущем я планирую написать приложение ERROR PROCESSOR, которое бызапустите в конце дня, который попытается обработать сообщения об ошибках (не все сообщения, но сообщения, которые не удалось из-за каких-либо зависимостей, таких как родительский отсутствует) снова.

b) Я хочу убедиться, что потеря сообщений равна нулю, и поэтому я сохраню сообщение в файл на случай возникновения проблем при сохранении сообщения в БД.

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

В-1) Является ли запись в файл единственной возможностью избежать потери данных?

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

ПРОЦЕСС ОШИБКИ - Наш источникследуя механике, управляемой событиями, и существует высокая вероятность того, что несколько раз зависимое событие (например, родительская сущность для чего-либо) может быть отложено на пару дней.Поэтому в этом случае я хочу, чтобы мой ПРОЦЕССОР ОШИБКИ обрабатывал одни и те же сообщения несколько раз.

Answer 1

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

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

Кроме того, вместо того, чтобы записывать своего собственного потребителя в базу данных, вы можете заглянуть в среду Kafka Connect. Для проверки сообщения вы можете аналогичным образом развернуть приложение Kafka Streams, чтобы отфильтровать плохие сообщения из входной темы в тему для отправки в БД

Answer 2

Я сталкивался с чем-то похожим раньше.Итак, углубляясь в ваши вопросы:

• Не обязательно, вы могли бы, возможно, отправить эти сообщения обратно Кафке в новой теме (скажем, - error-topic).Итак, когда ваш обработчик ошибок готов, он может просто прослушать this error-topic и использовать эти сообщения по мере их поступления.

• Я думаю, что этот вопрос был рассмотрен в ответек первому.Поэтому вместо одновременного использования файла для записи, чтения и открытия нескольких файловых дескрипторов Kafka может быть лучшим выбором, поскольку он предназначен для таких задач.

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

Еще один момент, который стоит рассмотреть при разработке вашего компонента service. Можно также рассмотреть возможность объединения точек 4 и 5, отправив все сообщения об ошибках обратно в Kafka.Это позволит вам согласованно обрабатывать все сообщения об ошибках, а не помещать некоторые сообщения в базу данных ошибок, а некоторые - в Кафку.

EDIT : На основе дополнительной информации о требовании ERROR PROCESSOR приведено схематическое представление схемы решения.

Я намеренно сохранил вывод аннотации ERROR PROCESSOR на данный момент, просто чтобы сделать его обобщенным.

Надеюсь, это поможет!