Как Apache Kafka обеспечивает отказоустойчивость и высокую доступность? Объясните концепцию репликации и ISR (синхронизированных реплик).
Apache Kafka обеспечивает отказоустойчивость и высокую доступность за счёт репликации каждой партиции топика между несколькими брокерами и автоматического перевыбора лидера при сбое. У партиции есть один лидер и несколько реплик‑фолловеров, а надёжность гарантирует набор синхронных реплик ISR (In-Sync Replicas), которые не отстают от лидера. Сообщение считается надёжно зафиксированным, когда оно записано на все реплики из ISR, поэтому при отказе лидера один из фолловеров из ISR может стать новым лидером без потери зафиксированных данных.
В Kafka данные организованы в топики, которые делятся на партиции. Для каждой партиции задаётся фактор репликации (например, replication.factor=3), и эта партиция хранится не на одном, а сразу на нескольких брокерах. Среди реплик партиции один брокер назначается лидером (leader), а остальные выступают фолловерами (followers).
Лидер партиции обрабатывает все запросы на запись и чтение для этой партиции. Фолловеры асинхронно копируют данные у лидера, периодически посылая ему запросы на чтение новых записей. Таким образом, каждая новая запись сначала попадает на лидера, а затем реплицируется на фолловеры.
Набор ISR (In-Sync Replicas) — это подмножество реплик партиции (лидер + фолловеры), которые считаются достаточно «синхронными» с лидером. Реплика входит в ISR, если она не слишком отстаёт по смещению (offset) и регулярно подтверждает лидеру, что прочитала все актуальные записи. Если фолловер начинает сильно отставать или становится недоступен по сети, брокеры временно исключают его из ISR.
Факт «надёжной фиксации» сообщения тесно связан с ISR. Когда продюсер отправляет сообщение с настройкой подтверждений acks=all, запись считается зафиксированной только тогда, когда лидер успешно записал её на диск и получил подтверждения от всех реплик из набора ISR. Это даёт гарантию, что при отказе одного брокера зафиксированные сообщения по-прежнему находятся минимум на одной другой реплике из ISR.
Дополнительно администратор может настроить минимальное число синхронных реплик, необходимых для приёма записи (параметр min.insync.replicas). Если число доступных реплик в ISR падает ниже этого порога, лидер перестаёт принимать записи с acks=all. Так Kafka выбирает в пользу целостности и долговечности данных, а не продолжения приёма записей любой ценой.
Если брокер‑лидер партиции выходит из строя, контроллер кластера (в классической архитектуре — через ZooKeeper, в новых версиях — встроенный контроллер Kafka) обнаруживает потерю лидера и инициирует процедуру перевыбора. Новым лидером может стать только одна из реплик из текущего ISR — это принципиально важно, чтобы не оказаться с лидером, который отстаёт по данным и может привести к потере уже подтверждённых сообщений.
Когда упавший брокер восстанавливается, он сначала догоняет лидера по данным, реплицируя все пропущенные сообщения. После того как смещения выравниваются и брокер снова удовлетворяет требованиям к синхронности, он возвращается в набор ISR. Этот цикл «выпал из ISR при отставании — догнал — вернулся в ISR» постоянно поддерживает баланс между производительностью и надёжностью.
Таким образом, отказоустойчивость и высокая доступность в Kafka достигаются сочетанием нескольких механизмов.
ISR и подтверждения записи от всех синхронных реплик гарантируют, что зафиксированные сообщения не потеряются.Отметьте свой прогресс