Рівень Junior

Визначення

Leader — основна репліка, яка приймає запис і читання.

Follower — копія, яка реплікує дані від лідера.

Partition 0:
  Broker 1 → Leader (read/write)
  Broker 2 → Follower (read-only, реплікує від лідера)
  Broker 3 → Follower (read-only, реплікує від лідера)

Основні ролі

Leader:
  - Приймає записи від продюсерів
  - Віддає дані консьюмерам
  - Управляє ISR списком

Follower:
  - Копіює дані від лідера
  - Не приймає записи від продюсерів
  - Може стати лідером при failover

Failover

Leader впав:
  Controller вибирає нового лідера з ISR
  Follower → новий Leader
  Консьюмери і продюсери перемикаються автоматично

---

Рівень Middle

Replication Flow

Producer → Leader → Follower 1
                  → Follower 2
                  → Follower 3

Consumer → читає тільки з Leader (за замовчуванням; в Kafka 2.4+ можна налаштувати читання
з фолловерів через replica.selector.class).

ISR (In-Sync Replicas)

ISR включає репліки, які:
1. Активні і надсилають heartbeat
2. Не відстають від лідера більше ніж на replica.lag.time.max.ms

Приклад:
  ISR: [Broker 1 (Leader), Broker 2, Broker 3]
  Якщо Broker 3 відстає → ISR: [Broker 1, Broker 2]

Unclean Leader Election

unclean.leader.election.enable=false (за замовчуванням):
  Лідер вибирається тільки з ISR
  Гарантія відсутності втрати даних

unclean.leader.election.enable=true:
  Лідер може бути вибраний з будь-якого фолловера
  Ризик втрати даних
  Якщо лідер закоммітив offset 100, а фолловер має тільки offset 95,
  при unclean election повідомлення 96-100 будуть втрачені.

Типові помилки

1. Unclean leader election:

   Follower не в ISR став лідером
   → Дані, яких немає у фолловера, втрачені
   

2. Нерівномірний розподіл лідерів:

   Брокер A: лідер для 80% партицій
   Брокер B: лідер для 20% партицій
   → Нерівномірне навантаження
   

---

Рівень Senior

ISR Management

Follower виходить з ISR якщо:

- Не надсилає fetch request > replica.lag.time.max.ms
- Відстає від лідера занадто сильно
- Broker недоступний

Follower повертається в ISR коли:

- Наздоганяє лідера
- Починає отримувати актуальні дані
- Controller додає його назад в ISR

Replica Fetcher

Follower періодично надсилає fetch requests до лідера:
- replica.fetch.wait.max.ms
- replica.fetch.min.bytes
- replica.fetch.max.bytes

Налаштування впливає на latency реплікації і network usage

Leader Election — детально

Controller Broker:

- Один брокер — контролер кластера
- Зберігає metadata всіх партицій
- Відповідає за leader election
- При падінні контроллера → новий вибирається

Election Process:

1. Leader впав або став недоступний
2. Controller виявив через ZooKeeper/KRaft
3. Перевіряє ISR список
4. Вибирає нового лідера (перший в ISR)
5. Оновлює metadata
6. Сповіщає брокерів і клієнтів

Preferred Leader

Кожна партиція має preferred leader (перший брокер в replica list)
При unbalanced кластері:
  kafka-leader-balancer.sh --bootstrap-server localhost:9092
  → Переміщує лідерів до preferred broker
  → Балансує навантаження

Monitoring

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

kafka.server:UnderReplicatedPartitions
kafka.server:IsrShrinksPerSec
kafka.server:IsrExpandsPerSec
kafka.server:LeaderCount
kafka.server:ReplicaManager:PartitionCount

Alerts:

- Under-replicated partitions > 0 → warning
- ISR shrinks per sec > threshold → warning
- Leader count imbalance > 20% → warning
- Replica lag > threshold → critical

Best Practices

✅ ISR monitoring
✅ unclean.leader.election.enable=false
✅ Рівномірний розподіл лідерів
✅ Регулярний leader balancer
✅ Моніторинг replica lag
✅ RF=3 для production

❌ Unclean leader election
❌ Ігнорування ISR shrink
❌ Нерівномірний розподіл лідерів
❌ Без моніторингу replica lag
❌ RF < 3 для production

Архітектурні рішення

1. ISR — гарантія consistency — лідер тільки з ISR
2. Unclean election = data loss — уникати в production
3. Leader balancing — рівномірне навантаження на брокери
4. Monitoring ISR health — критичний для production

Резюме для Senior

• Leader приймає усі записи і читання
• Follower’и пасивно копіюють дані
• ISR management критичний для consistency
• Leader election з ISR гарантує відсутність втрати даних
• Monitoring replica lag і ISR shrink/expansion обов’язковий

---

🎯 Шпаргалка для інтерв’ю

Обов’язково знати:

• Leader — єдина репліка, що приймає read/write від продюсерів і консьюмерів
• Follower — пасивно копіює дані від лідера, може стати лідером при failover
• ISR включає і лідера, і синхронних фолловерів; лідер вибирається тільки з ISR
• unclean.leader.election.enable=false (за замовчуванням) — тільки з ISR, інакше data loss
• При unclean election: фолловер з offset 95 замість лідера з offset 100 → втрата 96-100
• Replica Fetcher Thread: фолловер періодично fetch-ить дані від лідера
• Preferred Leader — перший брокер в replica list; leader balancer розподіляє рівномірно

Часті уточнюючі запитання:

• Чому консьюмери читають тільки з лідера? — Єдина точка істини, гарантія порядку. (Kafka 2.4+ дозволяє читати з фолловерів через replica.selector.class.)
• Коли фолловер виходить з ISR? — Не надсилає fetch > replica.lag.time.max.ms (30s).
• Що таке Preferred Leader? — Брокер, який має бути лідером за планом; leader balancer повертає до preferred.
• Чи можна писати в фолловер? — Ні, усі записи тільки через лідера.

Червоні прапорці (НЕ говорити):

• «Follower’и приймають запис» — тільки лідер
• «Unclean election — нормальна практика» — втрата даних
• «ISR тільки з фолловерів» — лідер завжди в ISR
• «Консьюмери можуть читати з будь-якої репліки за замовчуванням» — тільки з лідера (за замовчуванням)

Пов’язані теми:

• [[16. Що таке реплікація в Kafka]]
• [[18. Що таке ISR (In-Sync Replicas)]]
• [[19. Як Kafka забезпечує відмовостійкість]]
• [[20. Що таке producer acknowledgment і які режими існують (acks=0,1,all)]]