Если ISR меньше, чем коэффициент репликации, и для всех подтверждений установлены все подтверждения, сколько подтверждений будет ждать производитель? - PullRequest
0 голосов
/ 24 марта 2020
  • RF = 3, ISR = 3, acks = все >>> успешно отправлено
  • RF = 3, ISR = 2, acks = все >>> успешно отправлено
  • RF = 3, ISR = 1, acks = все >>> успешно отправлено
  • RF = 3, ISR = 1, acks = все, min.isr.replicas = 3 >>> успешно отправлено!

Итак, если коэффициент репликации равен 4, ISR равен 3 и для всех подтверждений производителя заданы значения, сколько подтверждений будет ждать производитель? Я пробовал разные сценарии ios, каким должно быть реальное поведение?

Ответы [ 2 ]

1 голос
/ 24 марта 2020

Если вы установите acks=all, то брокер, являющийся лидером раздела, будет ждать все реплики in-syn c для репликации данных. In-syn c -replica - это реплика, которая не сильно отстает от лидера раздела.

Что я имею в виду, что не далеко позади: В Кафке, когда сообщение отправляется разделу topi c (сначала сообщение принимается и сохраняется в лидере), и если коэффициент репликации для этой топи c больше 1, то брокер (-ы) реплики отправляют запрос на выборку руководителю брокер и эти данные реплицируются на другой брокер (ы). Если replica.lag.time.max.ms передается от последнего перехваченного, реплика считается несинхронной c и удаляется из списка ISR. (Это все еще реплика и извлечение сообщений, но ведущий брокер не ждет его, пока не догонит и снова не станет синонимом c -реплики)

Из документов Кафки:

Параметр конфигурации replica.lag.time.max.ms теперь относится не только к времени, прошедшему с момента последнего запроса на выборку из реплики, но и ко времени, прошедшему с момента последней реплики. Реплики, которые все еще извлекают сообщения от лидеров, но не отслеживают последние сообщения в replica.lag.time.max.ms, будут считаться несинхронными c.

Существует также min.insync.replicas параметр в конфиге брокера. Он задает минимальное количество in-syn c -реплик для продолжения отправки сообщения, когда acks=all.

min.insyn c .replicas: Когда производитель устанавливает acks to "all" (или "-1"), min.insyn c .replicas указывает минимальное количество реплик, которые должны подтвердить запись, чтобы запись считалась успешной. Если этот минимум не может быть достигнут, то производитель сгенерирует исключение (NotEnoughReplicas или NotEnoughReplicasAfterAppend). При совместном использовании min.insyn c .replicas и acks позволяет обеспечить более высокие гарантии долговечности. Типичным сценарием может быть создание темы с коэффициентом репликации 3, установка min.insyn c .replicas равной 2 и создание с подтверждением «all». Это будет гарантировать, что производитель выдаст исключение, если большинство реплик не получит запись.


Если коэффициент репликации равен 4, ISR равен 3, а подтверждения производителя установлены на все, сколько подтверждений будет ждать производитель?

Ответ : Брокер, являющийся лидером топи c, будет ждать 3 других брокера в списке ISR для репликации данных. и отправить подтверждение. Если количество реплик в списке ISR меньше min.insync.replicas, тогда ваш производитель получает исключение и не может выдать данные.

Примечание. Вы можете проверить текущую реплику и список ISR с помощью следующей команды.

bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic myTopic --describe
1 голос
/ 24 марта 2020

Когда дело доходит до установки acks, replication factor самой топи c играет только неявную роль. Как написано в документации по конфигурации брокера и цитируется ниже, min.insync.replicas определяет минимальное количество успешных репликаций в масштабе брокера, прежде чем оно будет рассматриваться как успешная запись.

min.insyn c .replicas: когда производитель устанавливает acks на «all» (или «-1»), min.insyn c .replicas указывает минимальное количество реплик, которые должны подтверждать запись для записи в считаться успешным . Если этот минимум не может быть достигнут, то производитель сгенерирует исключение (NotEnoughReplicas или NotEnoughReplicasAfterAppend). При совместном использовании min.insyn c .replicas и acks позволяет обеспечить более высокие гарантии долговечности. Типичным сценарием может быть создание topi c с коэффициентом репликации 3, значение min.insyn c .replicas равным 2 и получение с подтверждением «all». Это гарантирует, что производитель создает исключение, если большинство реплик не получают запись.

Тип: int

По умолчанию: 1

Допустимые значения: [1, ...]

Важность: высокая

Режим обновления: для всего кластера

Чтобы ответить на конкретный вопрос: Если replication factor равно 4, а min.insync.replicas равно 3, а для производителя acks установлены все, тогда производитель будет ждать 3 подтверждения в кластере, прежде чем он будет считаться успешной записью.

...