Уровень Junior

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

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

1. Репликация — данные на нескольких брокерах
2. Leader election — автоматический выбор нового лидера
3. 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

1. Leader упал
2. Controller обнаружил падение
3. Выбирает нового лидера из ISR
4. Продюсеры и консьюмеры переключаются

Min.insync.replicas

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

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

1. Недостаточная репликация:

   RF=2, min.insync=1 → потеря данных при падении лидера
   

2. 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:ActiveControllerCount
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
✅ Monitoring under-replicated partitions

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

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

1. RF=3 + min.insync=2 — баланс между availability и durability
2. Cross-DC replication — для disaster recovery
3. Unclean election = data loss — избегать в production
4. 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]]