Какие варианты репликации существуют в Kafka

Что проверяют

Понимаете ли вы, как Kafka реально хранит копии данных, а не абстрактную «синхронную и асинхронную» репликацию из учебника по базам. Почти всегда следом спрашивают: «Какие настройки дадут гарантию, что подтверждённое сообщение не потеряется при падении брокера?»

Как отвечать

Внутри кластера механизм один: у каждой партиции есть лидер и фолловеры, и фолловеры сами забирают данные у лидера. Всё остальное это настройки вокруг него:

• replication.factor: число копий партиции. В проде обычно 3, а default.replication.factor на брокере по умолчанию 1, и это ловушка при автосоздании топиков;
• ISR (in-sync replicas): реплики, которые отстают от лидера не дольше replica.lag.time.max.ms. Новым лидером становится только реплика из ISR;
• acks у продюсера: 0 без подтверждения, 1 подтверждает лидер, all ждёт все реплики из ISR. С Kafka 3.0 по умолчанию acks=all и включена идемпотентность;
• min.insync.replicas: минимальный размер ISR для записи с acks=all. Классика: фактор 3, min.insync.replicas=2, acks=all, и потеря одного брокера не стоит ни данных, ни записи;
• unclean.leader.election.enable: по умолчанию false. Если включить, лидером станет отставшая реплика, и часть данных пропадёт ради доступности.

Между кластерами работает MirrorMaker 2 на базе Kafka Connect: асинхронная копия для резервного ДЦ или географии, с переводом офсетов консьюмер-групп. Для полноты: в Kafka 4.0 ZooKeeper убран, метаданные кластера реплицирует кворум контроллеров KRaft.

Где спотыкаются

Говорят, что acks=all означает запись на все реплики. Это все реплики из ISR, и если ISR сжался до одного лидера, без min.insync.replicas гарантия вырождается в acks=1.

Называют «логическую и физическую репликацию» Kafka. Таких режимов нет, это термины из PostgreSQL.

Путают репликацию с масштабированием чтения. Консьюмеры по умолчанию читают с лидера, а чтение с ближайшей реплики включается отдельно через replica.selector.class на брокере и client.rack у клиента.