acks, min.insync.replicas и ISR: где именно теряются сообщения в Kafka?

Долговечность записи определяется парой настроек с двух сторон. На стороне продюсера — acks: 0 означает «отправил и забыл» (потеря при любом сбое), 1 — подтверждение от лидера (потеря, если лидер упал до репликации), all — подтверждение от всех синхронных реплик. На стороне топика — min.insync.replicas: минимальное число реплик в ISR, при котором запись вообще принимается. Именно комбинация решает: acks=all с min.insync.replicas=1 не защищает, потому что «все синхронные» может означать «одна». Рабочий набор для важных данных: фактор репликации 3, min.insync.replicas=2, acks=all — переживаем потерю одного брокера без потери данных и без остановки записи. Отдельный источник потерь — unclean.leader.election.enable=true: лидером становится отставшая реплика, и всё, чего у неё не было, исчезает. По умолчанию эта опция выключена, и включать её означает менять данные на доступность.