Ответ
In-Sync Replicas (ISR) в Apache Kafka — это набор реплик партиции, которые полностью синхронизированы с лидером. Их основная роль — обеспечивать отказоустойчивость и гарантировать сохранность данных (durability).
Когда продюсер отправляет сообщение с подтверждением acks=all, лидер коммитит его только после того, как получит подтверждение от всех реплик из списка ISR. Это гарантирует, что сообщение не будет потеряно, даже если лидер выйдет из строя сразу после отправки ответа продюсеру.
Механизм работы:
- Лидер (Leader): Единственная реплика, которая обрабатывает все запросы на чтение и запись для своей партиции.
- Последователи (Followers): Пассивно копируют данные с лидера.
- Попадание в ISR: Последователь считается синхронизированным и добавляется в ISR, если он не слишком сильно отстал от лидера. Величина отставания контролируется параметром
replica.lag.time.max.ms. - Смена лидера: В случае отказа текущего лидера, Kafka выбирает нового из числа реплик в ISR, что гарантирует отсутствие потери данных.
Ключевая настройка:
min.insync.replicas: Минимальное количество реплик в ISR (включая лидера), которое должно подтвердить запись, чтобы она считалась успешной. Если число реплик в ISR падает ниже этого значения, брокер перестает принимать записи в данный топик, возвращая ошибкуNotEnoughReplicas.
Пример проверки ISR через CLI:
kafka-topics.sh --describe --bootstrap-server localhost:9092 --topic my-topicВ выводе команды для каждой партиции будут указаны Leader, Replicas и Isr.
Ответ 18+ 🔞
Давай разберём эту штуку, которая ISR называется, в Кафке. Ну, чтобы не просто сухие буквы читать, а понять, на каком таком хуе она вертится.
Представь себе, есть у тебя главный брокер — лидер. Он, сука, король партиции, все продюсеры к нему лезут, все консьюмеры с него читают. А есть его подчинённые — фолловеры. Их задача — тупо копировать с лидера всё, что он пишет, как обезьянки.
Так вот, ISR (In-Sync Replicas) — это не просто все фолловеры подряд. Это элитный клуб, блядь! Туда попадают только те, кто не отъехал в запой и успевает за лидером. Критерий простой: если фолловер отстал больше, чем на replica.lag.time.max.ms миллисекунд, его, этого мартышлюшку, вышвыривают из ISR на мороз. Он теперь out-of-sync replica, лузер конченый.
А зачем это всё? А затем, ёпта, чтобы данные не потерялись, когда лидеру настанет пиздец. Продюсер присылает сообщение и говорит: «Подтверждай только когда все в синке запишут!» (acks=all). Лидер кивает, рассылает данные своей банде из ISR, ждёт, пока они все ответят «закоммитил, шеф!». И только тогда он сам коммитит и рапортует продюсеру: «Готово!». Теперь, даже если лидера тут же грохнет метеоритом — новый лидер выберется из этой же синхронизированной банды (ISR), и все данные на месте, нихуя не потеряно. Красота, да?
Но есть подлянка, хитрая жопа. Настройка min.insync.replicas. Это типа минимальный состав банды для совершения сделки. Допустим, стоит min.insync.replicas=2. В ISR у тебя лидер + два фолловера, всё охуенно. Но если один фолловер сдох и вылетел из ISR, в синке остаются только лидер и один фолловер. Это уже меньше двойки! И что делает лидер? Он, блядь, паникует и начинает отказывать всем продюсерам с ошибкой NotEnoughReplicas! «Не, ребята, я сейчас ненадёжный, пишите куда-нибудь ещё, пока я тут с одним подручным». Отказоустойчивость, мать её, в действии.
Как на это всё посмотреть, чтобы не гадать на кофейной гуще? Запускаешь в консоли свою палочку-выручалочку:
kafka-topics.sh --describe --bootstrap-server localhost:9092 --topic my-topicИ в выводе, для каждой партиции, ищешь три столбца:
Leader— кто главный на районе.Replicas— все, кто вообще должен эту партицию хранить (список желаний).Isr— а вот это, сука, реальная обстановка, кто фактически в синке и готов к работе. ЕслиReplicasиIsrотличаются — у тебя где-то проблемы, кто-то отстал или помер. Волнение ебать, пора разбираться.