Уровень 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
✅ Monitoring 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.
• Можно ли писать в фолловер? — Нет, все записи только через лидера.

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

• «Фолловеры принимают запись» — только лидер
• «Unclean election — нормальная практика» — потеря данных
• «ISR только из фолловеров» — лидер всегда в ISR
• «Консьюмеры могут читать с любой реплики по умолчанию» — только с лидера (по умолчанию)

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

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