Реплики подписчика выходят из синхронизации в Кафке

Question

У меня есть тема с partitions = 1 и replication factor = 5.Я начал публиковать сообщения на эту тему.Через несколько секунд, к моему удивлению, я заметил, что все подписчики были не синхронизированы, за исключением реплики лидера.

Перед запуском производителя:

Тема: log_compaction_topic4-15 Раздел: 0 Лидер: 5 Реплики: 5,1,2,3,4 Isr: 5,1,2,3,4

После запуска производителя:

Тема: log_compaction_topic4-15 Раздел: 0 Лидер: 5 Реплики: 5,1,2,3,4 Isr: 5

Здесь min.insync.replicas=5 и остальные настройки темы имеют значения по умолчанию.Кроме того, мой продюсер публикует с acks=1

Вопросы

1. Почему я могу публиковать сообщения дальше, даже если mininsync.replicas=5

2. Можно ли сделать так, чтобы все подписчики были синхронизированы все время?

3. Это ожидаемое поведение?Если да, не теряю ли я некоторые сообщения в случае сбоя лидера?

Answer 1

Почему я могу публиковать сообщения дальше, хотя min.insync.replicas = 5

Эта конфигурация будет учитываться только при установке acks="-1" or acks="all".

Официальный документ Кафки говорит:

Когда производитель устанавливает acks на "all" (или "-1"), min.insync.replicas указывает минимальное количество реплик, которые должны подтверждать запись длязапись считается успешной.Если этот минимум не может быть достигнут, то производитель выдаст исключение (NotEnoughReplicas или NotEnoughReplicasAfterAppend)

Могу ли я сделать так, чтобы все последователи были синхронизированы все время?

Как уже упоминалось выше, вы можете достичь этого, набрав acks="-1" or acks="all", а затем упомянув min.insync.replicas=5.

Это ожидаемое поведение?Если да, не теряю ли я некоторые сообщения в случае сбоя лидера?

Да, в случае сбоя лидера вы потеряете сообщения.acks=1 означает, что лидер записывает запись в свой локальный журнал, но отвечает, не ожидая полного подтверждения от всех подписчиков.В этом случае, если лидер потерпит неудачу сразу после подтверждения записи, но до того, как последователи реплицируют ее, запись будет потеряна.

Вопрос из комментария:

Но я заметил разницу в пропускной способности между (acks = all, min.insync.replicas = 1) и (acks = 1).При настройке acks = -1, даже если min.insync.replicas = 1, ведущий ожидает подтверждения всех синхронизированных реплик и, следовательно, снижения пропускной способности

С этого ответа на Kafka :

Также параметр минимальной синхронизации реплики указывает минимальное количество реплик, которые должны быть синхронизированы, чтобы раздел оставался доступным для записи.Когда производитель указывает ack (-1 / all config), он все еще будет ожидать подтверждения от всех в синхронизирующих репликах в этот момент (независимо от настройки минимальных синхронизируемых реплик).

Кроме того, один из полезных комментариев :

Просто подтвердил мой ответ с Джуном (соавтор Apache Kafka).Распространенным заблуждением является то, что min.insync.replicas допускает ACK, когда только минимальное подмножество ISR получает опубликованное сообщение.Однако «минимальная» часть относится к чему-то другому.Минимальное значение определяет, насколько маленький список ISR может получить и по-прежнему разрешать запись.ACK всегда возвращаются, когда все ISR в списке получают сообщение. В противном случае выбор лидера будет намного сложнее, поскольку не все реплики будут синхронизированы.

Документация: https://kafka.apache.org/documentation/#brokerconfigs