Уровень Junior

Определение

Репликация — это копирование данных партиций на несколько брокеров для отказоустойчивости.

Партиция 0:
  Broker A → Leader (принимает запись)
  Broker B → Follower (копия)
  Broker C → Follower (копия)

Зачем нужна репликация?

Если лидер упадёт:
  Один из фолловеров станет новым лидером
  Данные не потеряются (при условии unclean.leader.election.enable=false и наличии синхронных реплик).
  Консьюмеры продолжат чтение

Replication Factor

replication-factor=3 → 3 копии на разных брокерах
replication-factor=1 → нет отказоустойчивости

Пример создания топика

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

---

Когда НЕ нужен высокий replication factor

1. Dev/test окружения — RF=1 допустим
2. Высокообъёмные метрики/логи где потеря допустима — RF=1 или 2
3. Ограниченные ресурсы — каждая реплика = xN дисковое пространство

---

Уровень Middle

Leader и Followers

Partition 0:
  Broker 1 → Leader (read/write)
  Broker 2 → Follower (read-only, реплицирует от лидера)
  Broker 3 → Follower (read-only, реплицирует от лидера)

Все записи идут через лидера
Follower'ы пассивно копируют данные

ISR (In-Sync Replicas)

ISR — список реплик, которые синхронизированы с лидером

Пример:
  Leader: Broker 1
  ISR: [Broker 1, Broker 2, Broker 3]

Если Broker 3 отстаёт:
  ISR: [Broker 1, Broker 2]

min.insync.replicas

Минимальное число реплик в ISR для записи

min.insync.replicas=2:
  acks=all + минимум 2 реплики в ISR
  Если ISR < 2 → запись отклоняется

Failover

Leader упал:
  Controller брокер выбирает нового лидера из ISR
  Автоматический процесс
  Консьюмеры и продюсеры переключаются

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

1. Маленький replication factor:

   replication-factor=1 → нет отказоустойчивости
   При падении брокера данные потеряны
   

2. min.insync.replicas=1 с acks=all:

   Нет защиты от потери данных
   Leader упал → данные потеряны
   

---

Уровень Senior

Leader Election

Controller Broker:

Один из брокеров — контроллер кластера
Отвечает за:
- Выбор лидеров для партиций
- Управление ISR
- Обработку failover

При падении контроллера → новый контроллер выбирается

Leader Election Process:

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

ISR Management

Expanding ISR:

Follower догнал лидера → добавляется в ISR

Shrinking ISR:

Follower отстаёт → исключается из ISR
Критерий: replica.lag.time.max.ms (30 секунд по умолчанию)

Cross-Datacenter Replication

MirrorMaker 2:

(доступен с Kafka 2.4, заменяет устаревший MirrorMaker 1)
Репликация между дата-центрами
Active-passive или active-active topology
Асинхронная репликация

Considerations:

- Network latency между DC
- Bandwidth costs
- RPO (Recovery Point Objective)
- RTO (Recovery Time Objective)

Production Configuration

# Topic level
replication-factor: 3
min.insync.replicas: 2

# Broker level
unclean.leader.election.enable: false
replica.lag.time.max.ms: 30000

Best Practices

✅ RF=3 для production
✅ min.insync.replicas=2
✅ acks=all для критичных данных
✅ unclean.leader.election.enable=false
✅ Равномерное распределение лидеров
✅ Мониторинг ISR shrink/expansion

❌ RF=1 для production
❌ min.insync=1 с acks=all
❌ Unclean leader election
❌ Игнорирование ISR shrink
❌ Один дата-центр для критичных данных

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

1. RF=3 — стандарт для production
2. min.insync.replicas=2 — баланс между availability и durability
3. Cross-DC replication — для disaster recovery
4. ISR monitoring — ранний индикатор проблем

Резюме для Senior

• Репликация — основа отказоустойчивости Kafka
• ISR — критический механизм для consistency
• Leader election из ISR гарантирует отсутствие потери данных
• Cross-DC replication для disaster recovery
• Monitoring ISR health обязателен для production

---

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

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

• Репликация = копирование данных партиций на несколько брокеров для отказоустойчивости
• Replication Factor (RF): RF=3 — стандарт для production, выдерживает падение 2 брокеров
• Leader принимает read/write, Followers пассивно копируют данные
• ISR (In-Sync Replicas) — реплики, синхронизированные с лидером
• min.insync.replicas=2 при RF=3: запись отклоняется если ISR < 2
• unclean.leader.election.enable=false — лидер только из ISR, иначе data loss
• При падении лидера: Controller выбирает нового лидера из ISR

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

• Что будет при RF=1? — Нет отказоустойчивости, при падении брокера данные потеряны.
• Зачем min.insync.replicas=2? — Защита от записи в единственную копию (leader upал = data loss).
• Что такое unclean leader election? — Лидер из non-ISR фолловера → потеря данных.
• Как работает кросс-DC репликация? — MirrorMaker 2: асинхронная репликация между дата-центрами.

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

• «RF=1 достаточно для production» — нет отказоустойчивости
• «Все реплики принимают запись» — только Leader, Followers read-only
• min.insync.replicas=1 с acks=all — нет защиты от потери данных
• «Unclean leader election — безопасен» — данные потеряны при选举

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

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