Как убедиться, что при падении брокера Kafka данные не потерялись

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

Понимаете ли вы, что надёжность Kafka собирается из настроек топика, брокера, продюсера и потребителя вместе, и одного acks=all мало. Следом обычно спрашивают, что будет при падении второй реплики и как вы вообще узнаете о потере.

Как отвечать

Разберите защиту по звеньям:

• репликация: replication.factor=3 для важных топиков, реплики в разных стойках или зонах (broker.rack);
• min.insync.replicas=2 при факторе 3. acks=all ждёт подтверждения от реплик из ISR, а не от всех вообще. Если ISR сжался до лидера, без этой настройки запись подтвердится одной копией, а с ней продюсер получит NotEnoughReplicasException вместо тихой потери;
• выбор лидера: unclean.leader.election.enable=false, это значение по умолчанию. Иначе лидером станет отставшая реплика, и хвост подтверждённых сообщений исчезнет;
• продюсер: в актуальных версиях Java-клиента по умолчанию acks=all и enable.idempotence=true, повторы идут до delivery.timeout.ms (две минуты) без дублей. Результат отправки всё равно проверяйте: колбэк send() или get() у Future, ошибку обрабатывать, а не терять;
• потребитель: enable.auto.commit=false и коммит смещения после обработки, иначе упавший обработчик потеряет сообщения, смещения которых уже закоммичены.

Как убедиться, что потерь нет: метрики брокера UnderReplicatedPartitions, UnderMinIsrPartitionCount, OfflinePartitionsCount в Prometheus через JMX exporter, метрика продюсера record-error-rate, lag потребителей. Для критичных потоков добавляют сквозную сверку числа отправленных и обработанных сообщений за период. И регулярно гасят брокер на стенде под нагрузкой.

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

Говорят, что acks=all означает подтверждение всеми репликами. Без min.insync.replicas это не так, и при деградации кластера гарантия незаметно слабеет.

Считают, что брокер сбрасывает данные на диск при каждой записи. По умолчанию Kafka пишет в page cache и полагается на репликацию, поэтому одна копия на одном брокере ничего не гарантирует.

Забывают про потребителя. Автокоммит смещений по таймеру даёт потерю при падении обработчика, даже если брокеры отработали идеально.