ISR (In-Sync Replicas) в Kafka — это набор реплик раздела (partition), которые полностью синхронизированы с лидером и считаются безопасными для выбора новым лидером. Только реплики из ISR участвуют в корректных выборах лидера (при отключённом unclean leader election) и используются при подтверждении записей с `acks=all`. Размер и состав ISR напрямую влияют на баланс между отказоустойчивостью и доступностью брокера.
Подробный ответ
В Apache Kafka каждый раздел (partition) имеет одного лидера и несколько фолловеров (реплик). Лидер принимает записи от продюсеров, а фолловеры асинхронно дочитывают (реплицируют) эти данные у лидера. Не все реплики одинаково "полезны" с точки зрения надёжности, поэтому Kafka вводит понятие ISR — In-Sync Replicas.Определение ISR ISR — это подмножество всех реплик раздела, которые:
"Успевают" за лидером: их отставание по логам не превышает настроек наподобие `replica.lag.time.max.ms`.
Считаются живыми: брокер доступен, проходит heartbeat, реплика не в состоянии ошибки.
Успешно реплицируют данные с лидера и подтверждают свою актуальность контроллеру кластера.
Все реплики, которые формально есть (по `replication.factor`), но не удовлетворяют этим условиям, в ISR не входят и считаются отставшими или недоступными.Зачем нужен ISR Основная задача ISR — обеспечить управляемый компромисс между доступностью и гарантией сохранности данных: 1) Надёжность данных. При типичной конфигурации `unclean.leader.election.enable=false` новым лидером может стать только реплика из ISR. Это гарантирует, что новый лидер не будет иметь меньше данных, чем предыдущий (нет "отката" записей). 2) Семантика подтверждений продюсера. При `acks=all` запись считается подтверждённой только тогда, когда она записана лидером и реплицирована на все реплики из ISR. Так продюсер может быть уверен, что данные выдержат падение одного или нескольких брокеров (в зависимости от `replication.factor`).Связь с параметром min.insync.replicas Параметр `min.insync.replicas` задаёт минимальное количество реплик в ISR, которое должно подтвердить запись при `acks=all`. Если фактический размер ISR падает ниже этого значения (например, несколько брокеров отвалились или сильно отстают), брокер будет отвергать новые записи с ошибкой, чтобы не нарушать заданный уровень надёжности. На практике часто используют схему: — `replication.factor = 3` — `min.insync.replicas = 2` — продюсер отправляет с `acks=all` В таком случае система выдерживает падение одной реплики без потери подтверждённых данных, но начнёт отказывать в записи, если останется только одна синхронная реплика.Как реплика попадает в ISR и выпадает из него Реплика добавляется в ISR, когда она догоняет лидера и некоторое время поддерживает допустимое отставание. Если же реплика начинает отставать слишком сильно (по времени или количеству записей), либо брокер становится недоступен, контроллер кластера удаляет её из ISR. Это динамический процесс: при восстановлении брокера и успешном догоне лога реплика снова будет включена в ISR.Влияние ISR на отказоустойчивость и производительность Чем больше реплик в ISR, тем надёжнее данные, но тем выше накладные расходы на репликацию и тем потенциально больше задержки подтверждения при `acks=all`. Если же ISR сужается (реплики выпадают из него), система: — становится менее отказоустойчивой (меньше кандидатов в лидеры); — при жёстких настройках (`min.insync.replicas` + `acks=all`) может начать отказывать в приёме новых сообщений, чтобы не рисковать потерей данных.Итог ISR в Kafka — это ключевой механизм, через который реализуются гарантия "без потери подтверждённых сообщений" и предсказуемое поведение при падении брокеров. Понимание того, как формируется ISR и как с ним связаны настройки `replication.factor`, `acks`, `min.insync.replicas` и `unclean.leader.election.enable`, критично для правильного проектирования отказоустойчивого кластера Kafka. Нашли ошибку? Выделите ее