Java Interview Questions

Главная / Все ответы / Kafka

Вопрос 18 · Раздел 15

Что такое ISR (In-Sync Replicas)

Реплика считается синхронной если:

Russian Kafka Исходный Markdown
Версии по языкам: English Russian Ukrainian

Уровень Junior

Определение

ISR (In-Sync Replicas) — это список реплик партиции, которые полностью синхронизированы с лидером.

Partition 0:
  Leader: Broker 1
  ISR: [Broker 1, Broker 2, Broker 3]

Все три брокера имеют актуальные данные

Зачем нужен ISR?

1. Выбор нового лидера при failover
   — Только из ISR (гарантия отсутствия потери данных)

2. Подтверждение записи
   — acks=all ждёт подтверждения от всех ISR

Как реплика попадает в ISR?

Реплика входит в ISR если:
1. Брокер активен и отправляет heartbeat
2. Не отстаёт от лидера больше чем на 30 секунд (по умолчанию)

Пример

# Проверить ISR для топика
kafka-topics.sh --describe --topic orders --bootstrap-server localhost:9092

Topic: orders  Partition: 0  Leader: 1  Replicas: 1,2,3  ISR: 1,2,3

Числа 1,2,3 — это ID брокеров в кластере. ISR: 1,2,3 означает что все три
брокера синхронизированы.

Уровень Middle

Определение “In-Sync”

Реплика считается синхронной если:

1. Живучесть: Брокер активен и поддерживает связь
2. Актуальность: Не отстаёт больше чем на replica.lag.time.max.ms (30 сек)

ISR и выбор лидера

При падении лидера:
  Новый лидер выбирается только из ISR
  → Гарантирует, что новый лидер имеет все закоммиченные данные
  → Потери данных исключены

ISR и подтверждение записи

acks=all + min.insync.replicas=2:
  Producer → Leader → ждёт подтверждения от всех ISR
  Если ISR < 2 → запись отклоняется

Shrinking и Expanding ISR

Shrinking (сжатие):
  Follower тормозит → исключается из ISR

Expanding (расширение):
  Follower догнал → возвращается в ISR

min.insync.replicas

Минимально допустимый размер ISR для приёма записей

Пример:
  min.insync.replicas=2
  ISR=[Leader, Follower1] → запись разрешена
  ISR=[Leader] → запись отклоняется (NotEnoughReplicasException)

Типичные ошибки

  1. ISR Shrinking без расследования: 
    Реплики выходят из ISR → риск потери данных
→ Нужно мониторить и устранять причину
  2. min.insync.replicas=1: 
    Нет защиты — один лидер может потерять данные

Уровень Senior

Internal Implementation

ISR Tracking:

Лидер отслеживает каждую реплику:
- Last Fetch Time — время последнего fetch request
- Last Caught Up Time — когда догнал лидера
- Log End Offset — последний offset у реплики

Критерий включения в ISR:
  (now - lastCaughtUpTime) <= replica.lag.time.max.ms

Historical Note:

До Kafka 0.9: replica.lag.max.messages (лимит по сообщениям)
После Kafka 0.9: replica.lag.time.max.ms (лимит по времени)

Причина: лимит по сообщениям неэффективен для high-throughput систем

ISR и acks=all

acks=all ждёт подтверждения от всех ISR реплик

Сценарий:
  ISR=[1,2,3], min.insync.replicas=2
  Producer → acks=all → ждёт от 1,2,3
  Если 3 вышел из ISR → ISR=[1,2] → всё ещё работает

Сценарий с проблемой:
  ISR=[1,2,3], min.insync.replicas=2
  2 и 3 вышли из ISR → ISR=[1]
  Запись отклоняется (NotEnoughReplicasException)

Unclean Leader Election

Если ISR пуст (все синхронные реплики упали):

unclean.leader.election.enable=false (по умолчанию):
  → Ждать восстановления любой реплики из ISR
  → Система недоступна на запись
  → Данные сохранены

unclean.leader.election.enable=true:
  → Выбрать любого живого фолловера
  → Система заработает
  → Потеря данных, которые не скопированы

Monitoring ISR

Ключевые метрики:

kafka.server:IsrShrinksPerSec
kafka.server:IsrExpandsPerSec
kafka.server:UnderReplicatedPartitions
kafka.server:PartitionCount (ISR size)

Alerts:

- ISR shrinks per sec > threshold → warning
- Under-replicated partitions > 0 → warning
- ISR size < replication factor → critical
- Replica lag > 30s → critical

ISR Troubleshooting

Причины shrinking:

1. Network issues между брокерами
2. Перегрузка брокера (CPU, disk, memory)
3. Медленный диск у фолловера
4. Большой volume данных (follower не успевает)

Решения:

1. Проверить network connectivity
2. Мониторить ресурсы брокеров
3. Увеличить replica.fetch.max.bytes
4. Увеличить replica.lag.time.max.ms (временное решение)

Production Configuration

# Broker level
replica.lag.time.max.ms: 30000
num.replica.fetchers: 1

# Topic level
replication.factor: 3
min.insync.replicas: 2
unclean.leader.election.enable: false

Best Practices

✅ ISR monitoring (shrinks/expands)
✅ min.insync.replicas=2 при RF=3
✅ unclean.leader.election.enable=false
✅ Alert на under-replicated partitions
✅ Равномерное распределение реплик
✅ Мониторить replica lag

❌ Игнорирование ISR shrink
❌ min.insync.replicas=1 для production
❌ unclean.leader.election.enable=true
❌ Без мониторинга replica lag
❌ RF < 3 для production

Архитектурные решения

  1. ISR — гарант отсутствия потерь — лидер только из ISR
  2. min.insync.replicas=2 — баланс между availability и durability
  3. Monitoring ISR shrink — ранний индикатор проблем
  4. Unclean election = data loss — избегать в production

Резюме для Senior

  • ISR — критический механизм для consistency Kafka
  • Реплика входит в ISR по времени отставания, не по сообщениям
  • ISR включает в себя и самого Лидера — лидер всегда в ISR, так как он является источником истины, ему не нужно копировать данные.
  • min.insync.replicas защищает от записи в единственную копию
  • IsrShrinksPerSec — ключевая метрика для мониторинга
  • Unclean leader election — последняя мера с риском потери данных

🎯 Шпаргалка для интервью

Обязательно знать:

  • ISR — список реплик, полностью синхронизированных с лидером (включая самого лидера)
  • Реплика в ISR если: активна и не отстаёт больше чем replica.lag.time.max.ms (30s)
  • Новый лидер выбирается ТОЛЬКО из ISR → гарантия отсутствия потери данных
  • acks=all ждёт подтверждения от всех ISR реплик
  • min.insync.replicas=2 при RF=3: запись отклоняется если ISR < 2
  • Shrinking: фолловер отстаёт → исключается; Expanding: догнал → возвращается
  • До Kafka 0.9: лимит по сообщениям; после: лимит по времени (эффективнее для high-throughput)

Частые уточняющие вопросы:

  • Входит ли лидер в ISR? — Да, лидер всегда в ISR — он источник истины.
  • Что будет если ISR пуст? — При unclean.leader.election.enable=false — система недоступна; если true — любой фолловер (data loss).
  • Почему по времени а не по сообщениям? — Лимит по сообщениям неэффективен для high-throughput.
  • Какие причины shrinking ISR? — Network issues, перегрузка брокера, медленный диск, большой volume.

Красные флаги (НЕ говорить):

  • «ISR только из фолловеров» — лидер всегда в ISR
  • min.insync.replicas=1 для production — нет защиты от data loss
  • «ISR shrinking — можно игнорировать» — ранний индикатор проблем
  • «Unclean leader election безопасен» — потеря данных гарантирована

Связанные темы:

  • [[16. Что такое репликация в Kafka]]
  • [[17. Что такое leader и follower реплики]]
  • [[19. Как Kafka обеспечивает отказоустойчивость]]
  • [[20. Что такое producer acknowledgment и какие режимы существуют (acks=0,1,all)]]