Як Kafka забезпечує відмовостійкість

Рівень Junior

Основні механізми

Kafka забезпечує відмовостійкість через реплікацію:

Реплікація — дані на кількох брокерах
Leader election — автоматичний вибір нового лідера
Consumer group — консьюмери перезапускаються і продовжують

Приклад failover

Broker A (Leader) → впав
Broker B (Follower) → став Leader
Консьюмери → продовжили читання з нового лідера
Продюсери → продовжують запис на нового лідера

Replication Factor

replication-factor=3 → витримує падіння 2 брокерів (за умови що репліки
розподілені по різних брокерах, що відбувається за замовчуванням при достатній
кількості брокерів).
replication-factor=2 → витримує падіння 1 брокера
replication-factor=1 → немає відмовостійкості

Створення відмовостійкого топика

kafka-topics.sh --create \
  --topic orders \
  --partitions 3 \
  --replication-factor 3 \
  --bootstrap-server localhost:9092

Рівень Middle

Відмовостійкість на різних рівнях

Брокер:

RF=3 → дані на 3 брокерах
Витримує падіння 2 брокерів

Продюсер:

acks=all + retries → автоматичний retry
enable.idempotence → захист від дублікатів

Консьюмер:

Committed offsets → продовжує після перезапуску
Consumer group → автоматичний ребаланс

Leader Election

Leader впав
Controller виявив падіння
Вибирає нового лідера з ISR
Продюсери і консьюмери перемикаються

Min.insync.replicas

min.insync.replicas=2:
  Запис дозволений тільки якщо >= 2 реплік в ISR
  Захист від запису в єдину копію

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

Недостатня реплікація:

RF=2, min.insync=1 → втрата даних при падінні лідера

Unclean leader election:

unclean.leader.election.enable=true → ризик втрати даних

Рівень Senior

Cross-Datacenter Replication

MirrorMaker 2:

Реплікація між дата-центрами
Active-passive або active-active topology
Асинхронна реплікація

Topology options:

1. Active-Passive:
   DC1 (active) → DC2 (passive)
   При падінні DC1 → DC2 стає active

2. Active-Active:
   DC1 ← → DC2
   Обидва DC приймають записи
   Складніше consistency

Failure Scenarios

1. Single Broker Failure:

RF=3, min.insync=2:
  Broker A (Leader) впав
  ISR=[B,C] → новий лідер з B або C
  Записи продовжуються (ISR >= 2)
  Дані не втрачені

2. Network Partition:

Брокери розділені на дві групи:
  Group 1: Broker A, B
  Group 2: Broker C

Group 1: ISR=[A,B] → працює
Group 2: ISR=[C] → запис відхиляється (ISR < min.insync)

3. Datacenter Failure:

Active-Passive:
  DC1 впав → MirrorMaker зупинився
  DC2 активується → продовжує роботу
  RPO = дані, репліковані до падіння
  RTO = час активації DC2

Recovery Procedures

1. Broker Recovery:

Впалий брокер restarts:
  → Підключається до кластера
  → Починає реплікувати з лідера
  → Коли наздоганяє → додається в ISR
  → Може стати лідером при наступному failover

2. Datacenter Recovery:

DC1 відновлений:
  → MirrorMaker resume replication
  → Sync даних між DC
  → Switch back або continue в DC2

Production Configuration

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

# Broker level
replica.lag.time.max.ms: 30000
auto.leader.rebalance.enable: true

# Producer level
acks: all
enable.idempotence: true
retries: Integer.MAX_VALUE

# Consumer level
enable.auto.commit: false
isolation.level: read_committed
// isolation.level=read_committed потрібен для читання тільки закоммічених
// транзакційних повідомлень, ігноруючи скасовані.

Monitoring

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

kafka.server:UnderReplicatedPartitions
kafka.server:IsrShrinksPerSec
kafka.server:ActiveControllerCounts
kafka.server:OfflinePartitionsCount
kafka.server:LeaderElectionRate

Alerts:

- Under-replicated partitions > 0 → warning
- Offline partitions > 0 → critical
- ISR shrinks rate > threshold → warning
- Controller changed → investigate
- Leader election rate > threshold → warning

Best Practices

✅ RF=3 для production
✅ min.insync.replicas=2
✅ acks=all для критичних даних
✅ Кросс-DC реплікація для disaster recovery
✅ Автоматичний leader rebalancer
✅ Моніторинг under-replicated partitions

❌ RF < 3 для production
❌ Один дата-центр для критичних даних
❌ unclean.leader.election.enable=true
❌ min.insync.replicas=1 з acks=all
❌ Без моніторингу ISR health

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

RF=3 + min.insync=2 — баланс між availability і durability
Cross-DC replication — для disaster recovery
Unclean election = data loss — уникати в production
Monitoring under-replicated partitions — ранній індикатор проблем

Резюме для Senior

Відмовостійкість будується на реплікації і ISR
RF=3 витримує падіння 2 брокерів
Cross-DC replication для disaster recovery
Monitoring under-replicated partitions критичний
Unclean leader election — останній захід з ризиком втрати даних

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

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

Відмовостійкість будується на реплікації (RF=3), ISR і leader election
RF=3 витримує падіння 2 брокерів; RF=2 — падіння 1 брокера
min.insync.replicas=2 + acks=all — захист від запису в єдину копію
Producer: acks=all + enable.idempotence=true + retries=INT_MAX
Consumer: committed offsets + consumer group auto-rebalancing при failover
При network partition: група з більшістю ISR працює, решта — запис відхиляється
Cross-DC replication (MirrorMaker 2) — для disaster recovery

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

Що буде при падінні одного брокера з RF=3? — Follower стає лідером, дані не втрачені.
Як producer обробляє failover? — Retries + idempotence → дублікати відхиляються брокером.
Що при network partition? — Група з більшістю ISR продовжує, minority — запис відхиляється.
Як consumer відновлюється? — Committed offsets → продовжує з останнього збереженого offset.

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

«RF=2 достатньо для критичних даних» — min.insync=1 при RF=2 = data loss risk
«Kafka не втрачає дані ніколи» — втрачає при unclean leader election
«Consumer вручну повинен відновлювати offset» — автоматично через consumer group
«Cross-DC replication синхронна» — асинхронна, RPO > 0

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

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