Кафка: Это хорошая практика - держать смещение темы в базе данных? - PullRequest
Новая
       6

Кафка: Это хорошая практика - держать смещение темы в базе данных?

0 голосов
/ 06 октября 2019

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

1 Ответ

2 голосов
/ 06 октября 2019

краткий ответ на ваш вопрос "сложный": -)

длинный ответ на ваш вопрос примерно такой:

  1. kafka (без дополнительной настройки и / илитщательно продуманный дизайн вашего кода) является хотя бы разовой системой (см. официальная документация ). это означает, что да, ваш потребитель может увидеть определенный набор записей более одного раза. это не произойдет при изящном завершении работы / перебалансировке, но обязательно произойдет, если ваше приложение выйдет из строя.
  2. Более новые версии kafka поддерживают так называемый «ровно один раз». это включает настройку ваших клиентов по-разному (и значительное снижение производительности и задержки), а гарантии сохраняются только в том случае, если все ваши входы и выходы находятся в / из одного и того же кластера kafka . поэтому, если ваш потребитель делает что-то вроде вызова внешнего HTTP API или вставки в базу данных в ответ на просмотр записи kafka, мы возвращаемся, по крайней мере, один раз.
  3. , если ваши результаты переходят в транзакционную систему (например,классическая база данных ACID) распространенным шаблоном будет запуск транзакции, и в этой транзакции записываются как ваши выходные данные, так и смещения потребителя (вам также потребуется изменить код для восстановления с этих смещений БД, а не по умолчанию kafka). это дает лучшие гарантии (но все равно не поможет, если ваш код взаимодействует с нетранзакционными системами, такими как выполнение HTTP-вызова)
  4. еще один общий шаблон проектирования, который нужно хотя бы раз преодолеть, - это как-то «пометить» каждую операциювы делаете (запись, которую вы производите, вызов http, который вы делаете ...) с некоторым UUID, который получается из исходных записей kafka, которые используются для создания этого вывода. это означает, что если ваш потребитель снова увидит ту же самую запись, он снова выполнит те же самые операции и повторит то же значение тега. это переносит бремя на нисходящие системы, которые теперь должны помнить (по крайней мере, в течение некоторого периода времени) все «теги», которые они видели, чтобы они могли игнорировать повторную операцию или каким-то образом спроектировать все ваши операции как идемпотентные
...