Безошибочная работа с Kafka из Node js. Часть 3 Cтруктура сообщений, когда Kafka не нужна и теряет данные

В сфере искусственного интеллекта произошло заметное событие. mitya_k 5 минут назад Безошибочная работа с Kafka из Node js. Часть 3 Cтруктура сообщений, когда Kafka не нужна и теряет данные Уровень сложности Средний Время на прочтение 8 мин Охват и читатели 12 Node. JS * JavaScript * Проектирование API * Микросервисы * Анализ и проектирование систем * В предыдущих частях рассматривались аспекты публикации сообщений , ребалансировки консьюмер групп и масштабирования чтения, а также проектирования консьюмеров .

Эта часть посвящена базовой структуре сообщений, неподходящим сценариям использования Kafka и гарантиям записи. Cтруктура сообщений При проектировании коммуникаций через Kafka нужно заранее позаботиться о двух вещах. Во-первых, о «скелете» сообщения, который заранее позволит решить ряд проблем c трассировкой, логированием, дедупликацией, повторной обработкой и т.

Технические детали

Во-вторых, о самой структуре передаваемых данных в сообщении и том, как они будут версионироваться. Kafka это statefull система и версионирование данных в ней сложная задача. Пример «cкелета» сообщения: await producer.

', messages: }); x-service-name – имя сервиса, который опубликовал сообщение. Полезно для трассировки. Например, когда в один топик пишут несколько сервисов или сообщение может пройти путь через несколько топиков прежде, чем достигнуть консьюмера.

x-request-id – уникальный id запроса. Необходим для удобного логирования, например, отфильтровать логи, cвязанные c пачкой сообщений или одним конкретным. message_id – уникальный индентификатор сообщения.

Отраслевые последствия

Позволяет как определить дубли записей, так и защититься от повторной обработки на стороне консьюмера. timestamp или sequence_id – поля, определяющие порядок создания сообщения на продьюсере. Kafka дает гарантии порядка для уже записанных в топик сообщений, но иногда они могут быть записаны в брокер в разном порядке.

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

Для решения данной проблемы требуется передавать ключ порядка операций: timestamp – время создания сообщения на продьюсере, а не время, когда его отправили в топик ( producer. send ) sequence_id – уникальный монотонно возрастающий идентификатор. Можно использовать sequence_id , когда timestamp не подходит, например, когда не хочется полагаться на синхронизацию часов у всех инстансов приложения.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.