Java Interview Questions

Головна / Усі відповіді / Kafka

Питання 18 · Розділ 15

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

Репліка вважається синхронною якщо:

Ukrainian 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)]]