Как Kafka обеспечивает сохранность данных при отказе брокера?

Ответ

Kafka использует несколько взаимосвязанных механизмов для обеспечения отказоустойчивости и сохранности данных (durability):

Репликация партиций. Каждая партиция топика копируется на несколько брокеров. Этот replication-factor (обычно 3) определяет, сколько копий данных существует в кластере. Одна реплика является лидером (принимает запись), остальные — фолловерами (копируют данные с лидера).
In-Sync Replicas (ISR). Это список реплик (включая лидера), которые не сильно отстали от лидера. Только реплики из списка ISR могут быть выбраны новым лидером в случае отказа текущего. Это гарантирует, что новый лидер будет иметь актуальные данные.
Настройка подтверждений (acks). Продюсер при отправке сообщения может указать, какого уровня подтверждения он ожидает:
- acks=0: Не ждать подтверждения. Максимальная производительность, но есть риск потери данных.
- acks=1: Ждать подтверждения только от лидера. Хороший баланс, но данные могут быть потеряны, если лидер упадет сразу после отправки подтверждения, но до того, как фолловеры скопируют данные.
- acks=all: Ждать подтверждения от всех реплик из списка ISR. Максимальная надежность, но самая низкая производительность.
Конфигурация min.insync.replicas. Этот параметр на стороне брокера задает минимальное количество реплик в ISR, которые должны подтвердить запись, чтобы она считалась успешной (при acks=all). Если синхронизированных реплик меньше, продюсер получит ошибку. Это защита от записи в кластер с недостаточной репликацией.

Пример конфигурации продюсера для максимальной надежности:

from kafka import KafkaProducer

producer = KafkaProducer(
    bootstrap_servers='kafka1:9092,kafka2:9092',
    # Ждём подтверждения от всех реплик в ISR
    acks='all',
    # Повторяем отправку в случае временных ошибок сети
    retries=5
)

Ключевая настройка на стороне брокера для предотвращения потери данных — unclean.leader.election.enable = false, которая запрещает выбирать лидером реплику, не входящую в ISR.