Проверяет понимание отказоустойчивости Apache Kafka и механизмов репликации при сбое брокера.
Apache Kafka спроектирована как отказоустойчивая распределенная система. Когда один из брокеров выходит из строя, механизмы репликации и координации обеспечивают продолжение работы без потери данных. Каждая партиция (partition) имеет лидера (leader) и несколько реплик (followers), распределенных по разным брокерам. Лидер обрабатывает все запросы на запись и чтение, а followers синхронно копируют данные.
При сбое брокера, который был лидером для некоторых партиций, контроллер кластера (ZooKeeper или KRaft) обнаруживает потерю связи. Контроллер выбирает нового лидера из списка in-sync replicas (ISR) — реплик, которые полностью синхронизированы с лидером. Новый лидер начинает принимать запросы, и кластер продолжает работу. Если сбойный брокер возвращается, он становится follower и догоняет данные.
# Создание топика с replication-factor=3
kafka-topics.sh --create --topic my-topic \
--bootstrap-server localhost:9092 \
--partitions 3 --replication-factor 3
# Продюсер отправляет сообщения
producer.send(new ProducerRecord<>("my-topic", "key", "value"));
# При сбое брокера 1, партиция 0 (лидер на брокере 1)
# переключается на реплику на брокере 2 или 3min.insync.replicas определяет минимальное количество ISR для записи.Kafka обеспечивает высокую доступность за счет репликации и автоматического переключения лидера. Для надежной работы в production необходимо настроить replication factor >= 3 и min.insync.replicas >= 2. Это позволяет пережить сбой одного или даже двух брокеров без потери данных и остановки сервиса.
