Хобрук: Ваш путь к мастерству в программировании

Kafka docs Producer возможна потеря сообщения

В настоящее время я узнаю больше о Kafka Producer. Меня немного озадачил следующий абзац из документации:

Сообщения, написанные лидеру раздела, не могут быть немедленно прочитаны потребителями, независимо от настроек подтверждения производителя. Когда все синхронизированные реплики подтвердили запись, сообщение считается зафиксированным, что делает его доступным для чтения. Это гарантирует, что сообщения не могут быть потеряны из-за сбоя брокера после того, как они уже были прочитаны. Обратите внимание, что это означает, что сообщения, которые были подтверждены только лидером (то есть, acks = 1), могут быть потеряны, если лидер раздела выходит из строя до того, как реплики скопируют сообщение. Тем не менее на практике это часто является разумным компромиссом для обеспечения долговечности в большинстве случаев, при этом не слишком сильно влияя на пропускную способность.

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

Я не понимаю, как (например) приложение Java может защитить от этой потери сообщения. Получает ли он разные подтверждения между «единственным лидером» и полной репликацией?

на практике это часто бывает разумным компромиссом

Как так? Предполагают ли они, что вам следует регистрировать неудачные сообщения и заново ставить их в очередь вручную? Или как это работает?

apache-kafka kafka-producer-api
18.01.2021

Ответы:


1

Получает ли он разные подтверждения между «единственным лидером» и полной репликацией?

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

Если вы установите acks=all и синхронизация между лидером и репликами завершится неудачно, ваш производитель получит retriable Exception (либо NotEnoughReplicasException, либо NotEnoughReplicasAfterAppendException, подробнее см. здесь). В зависимости от конфигурации производителя retries он попытается повторно отправить сообщение. Kafka построен таким образом, что ожидает, что сбойные брокеры будут снова доступны (через короткий промежуток времени).

Если вы установили acks=1 и синхронизация между лидером и репликами не удалась, ваш производитель считает, что сообщение было успешно записано в кластер, и не будет пытаться воспроизвести сообщение. Конечно, лидер продолжит тиражировать сообщение своим репликам. Но на самом деле нет никаких гарантий, что это произойдет. И до того, как сообщение будет реплицировано, у самого брокера-лидера могут возникнуть проблемы, из-за которых сообщение будет потеряно навсегда.

18.01.2021
  • Итак, из вашего объяснения я понимаю, что нет гарантированной доставки, если вы не установите для подтверждения «все». Я не понимаю, как не устанавливать для него значение «все» - это приемлемый компромисс, если вы не хотите терять сообщения (?). Это похоже на то, что база данных просто теряет вставку при подтверждении, что мне вообще не кажется приемлемым. Для меня это звучит просто странно. Есть ли у вас какое-то представление о накладных расходах, связанных с ожиданием подтверждения всеми репликами? Я хочу использовать соединитель приемника для передачи данных из REST api в MongoDB. 18.01.2021
  • Примечание. Я понимаю, насколько это приемлемо для больших данных, однако мой вариант использования - улавливать всплески загрузки данных пользователями в определенное время. В этом случае данные не должны теряться, поскольку это касается пользовательских данных. Кажется, мне нужно установить для «acks» значение «all», но только если я смогу получить быстрый ответ клиенту. Если это имеет для вас смысл. Похоже на обычный вариант использования. 18.01.2021
  • Я понимаю вашу точку зрения по этому поводу, и вы правильно понимаете, что вы теряете некоторую степень гарантии доставки при установке acks = 1 или даже 0 (что было бы режимом «выстрелил и забыл»). Во многих случаях использования больших данных с использованием распределенных систем часто не представляет большой проблемы, если вы потеряете одно или другое сообщение. Если вас интересуют только данные, скажем, за последние несколько минут, несколько потерянных сообщений не повлияют на эти несколько минут. 18.01.2021
  • Хотя в одном из моих последних случаев использования было обязательным не терять никаких сообщений, я все же установил acks = 1, потому что мне приходилось обрабатывать много данных одновременно. В зависимости от настройки вашего кластера, пропускной способности сети, трафика, местоположения сервера и других факторов, вы получите реальный выигрыш в производительности, снизив количество подтверждений со всех до 1. В нашем случае это был коэффициент около 5, если какой-то кластер находился на расстоянии 50 км от друг с другом. Но, конечно, я не могу посоветовать потенциальный выигрыш в производительности в вашем случае, не зная всех упомянутых деталей ... Думаю, вам просто нужно это протестировать. 18.01.2021
  • Кстати, вы также можете использовать транзакции в Kafka, чтобы гарантировать, что вы не потеряете никаких данных. 18.01.2021
    • Новые материалы
    Dall-E 2: недавние исследования показывают недостатки в искусстве, созданном искусственным интеллектом
    DALL-E 2 — это всеобщее внимание в индустрии искусственного интеллекта. Люди в списке ожидания пытаются заполучить продукт. Что это означает для развития креативной индустрии? О применении ИИ в..
    «Очень простой» эволюционный подход к обучению с подкреплением
    В прошлом семестре я посетил лекцию по обучению с подкреплением (RL) в моем университете. Честно говоря, я присоединился к нему официально, но я редко ходил на лекции, потому что в целом я нахожу..
    Освоение информационного поиска: создание интеллектуальных поисковых систем (глава 1)
    Глава 1. Поиск по ключевым словам: основы информационного поиска Справочная глава: «Оценка моделей поиска информации: подробное руководство по показателям производительности » Глава 1: «Поиск..
    Фишинг — Упаковано и зашифровано
    Будучи старшим ИТ-специалистом в небольшой фирме, я могу делать много разных вещей. Одна из этих вещей: специалист по кибербезопасности. Мне нравится это делать, потому что в настоящее время я..
    ВЫ РЕГРЕСС ЭТО?
    Чтобы понять, когда использовать регрессионный анализ, мы должны сначала понять, что именно он делает. Вот простой ответ, который появляется, когда вы используете Google: Регрессионный..
    Не зря же это называют интеллектом
    Стек — C#, Oracle Опыт — 4 года Работа — Разведывательный корпус Мне пора служить Может быть, я немного приукрашиваю себя, но там, где я живу, есть обязательная военная служба на 3..
    LeetCode Проблема 41. Первый пропущенный положительный результат
    LeetCode Проблема 41. Первый пропущенный положительный результат Учитывая несортированный массив целых чисел, найдите наименьшее пропущенное положительное целое число. Пример 1: Input:..