kafka-как обеспечить надежность и непротиворечивость сообщений

В kafka надежность сообщения в основном гарантируется за счет механизма ISR. Вот несколько вопросов, чтобы проиллюстрировать, как kafka обеспечивает надежность и согласованность сообщений.

Что такое ISR в Кафке?

Список AR (Assigned Replicas) сохраняется в zk, который содержит все реплики раздела, где AR = ISR+OSR

ISR (синхронная реплика): это группа синхронных реплик, которые kafka поддерживает динамически. Когда в ISR есть живые участники, только члены этой группы могут стать лидером. Внутреннее хранилище — это реплика (acks), которая должна быть синхронизируется каждый раз при отправке информации = все), всякий раз, когда лидер умирает, в наборе ISR избирается последователь, который будет служить лидером, а когда реплика в ISR считается сломанной, она будет выкинута из ISR, и он снова догонит сообщение ведущего data, повторно войдет в ISR.
OSR (аутсинхронизирующая реплика): Сохраненную реплику не нужно подтверждать после завершения синхронизации. То, синхронизирует ли реплика в OSR данные лидера, не влияет на отправку данных. Последователи в OSR стараются изо всех сил синхронизировать лидер, а версия данных может отставать.

Как kafka контролирует, сколько реплик необходимо синхронизировать, прежде чем их можно будет вернуть производителю до того, как сообщение станет доступным?

При записи в какфа производитель может выбрать, ждать ли 0 (запись только лидера), 1 (необходимо синхронизировать только одну реплику) или -1 (все реплики) для подтверждения сообщения (реплика здесь относится к ISR в ISR) копия).
Важно отметить, что «подтверждение всех реплик» не гарантирует, что все выделенные реплики получили сообщение. По умолчанию, когда acks=all, подтверждения будут выполняться всякий раз, когда сообщение будет получено всеми синхронизированными в данный момент репликами (репликами в ISR). Таким образом, обязательство по доставке Kafka можно понимать следующим образом: для сообщений, которые не были успешно отправлены, не гарантируется доставка, а «успешно отправленные» сообщения гарантированно не будут потеряны, если в ISR есть хотя бы одна уцелевшая полностью синхронизированная реплика.

Каковы условия существования узла кафки?

Первый пункт: узел должен поддерживать сеанс с zk, что достигается за счет обнаружения сердцебиения zk.
Второй момент: Если узел подчиненный, то есть узел репликации, то он должен реплицировать узел-лидер и не сильно отставать. Отсталость здесь может относиться к двум ситуациям
- 1: Репликация данных отстает, а данные ведомого узла и ведущего узла сильно отличаются.У этой ситуации есть недостаток.После того, как производитель внезапно отправляет большое количество сообщений, чтобы вызвать перегрузку сети, большое количество ведомых репликаций блокируется, что приводит к большому количеству задержек репликации данных и исключению из ISR.
- 2: Разница во времени слишком велика, что означает, что время между ведомым устройством, запрашивающим репликацию от лидера, и последним запросом слишком велико. по конфигурацииreplica.lag.time.maxВы можете настроить этот параметр времени. Этот метод решает проблему, вызванную первым методом выше.

Как восстановиться после зависания раздела раздела kafka?

В kafka есть механизм восстановления раздела для восстановления сбойного раздела.

Каждый раздел будет записывать RecoveryPoint (точку восстановления) на диск, записывая максимальное смещение, которое было сброшено на диск. Когда брокер выйдет из строя и перезапустится, будут выполнены loadLogs. Сначала будет прочитана точка восстановления раздела, и будет найден сегмент, содержащий точку восстановления, и последующие сегменты, которые могут быть не полностью сброшены на сегменты диска. Затем вызовите восстановление сегмента, перечитайте сообщение каждого сегмента и перестройте индекс.

преимущество:

Данные раздела управляются по сегментам, что удобно для управления жизненным циклом данных, и данные с истекшим сроком действия легко удалить.
При сбое программы и перезапуске ускорьте восстановление, просто восстановите не до конца слитый сегмент на диск

Из-за чего реплика не синхронизируется с лидером?

Медленная реплика: последователь не может догнать лидера в течение определенного периода времени. Одна из наиболее распространенных причин заключается в том, что из-за узких мест ввода-вывода последователи добавляют реплицированные сообщения медленнее, чем извлекают из лидера.
Застрявшая реплика: последователь перестает получать запросы от лидера в течение определенного периода времени. Реплика ведомого зависла из-за паузы GC, сбоя или смерти ведомого.
Недавно запущенные реплики: когда пользователь увеличивает коэффициент репликации до темы, новые подписчики не появляются в списке синхронизированных реплик до тех пор, пока они полностью не догонят журнал лидеров.

Последователи раздела считаются несинхронизированными или отстающими, если они достаточно отстают от лидера.

Как упоминалось выше, существует два типа решений Kafka об отставании: Оценка задержки реплики основана на максимальном количестве сообщений, которые реплика отстает от лидера (replica.lag.max.messages), или на самом длительном времени ожидания реплик. ответить лидеру раздела (replica.lag.time.max.ms). Первый используется для обнаружения медленных реплик, а второй — для обнаружения неисправных или мертвых реплик.

Что делать, если реплика внутри ISR умирает?

Два варианта: служба напрямую недоступна в течение определенного периода времени и ожидает восстановления реплики в ISR (пожалуйста, молитесь, чтобы в восстановленной реплике были данные) или напрямую выберите первую реплику (эта реплика не обязательно находится в ISR) как лидер Эти два метода также в доступности и согласованности.
Режим недоступности службы Применяется, когда не допускается потеря сообщений. Подходит для большей согласованности, чем доступность. Существует два подхода.
- Установите минимальное количество синхронных реплик ISR. Если текущее количество ISR больше установленного минимального синхронного значения, раздел будет принимать записи, избегая слишком малого количества синхронных реплик ISR. Если оно меньше минимального значения, то раздел не будет получать записи. Этот минимальный параметр вступает в силу, только если acks = all.
- Отключите выбор нечистого лидера.Когда все реплики в ISR недоступны, вы не можете использовать реплику в OSR в качестве лидера, чтобы напрямую сделать сервис недоступным, пока реплика в ISR не восстановится перед выбором лидера.
Метод прямого выбора первой реплики в качестве лидера подходит для сценариев, где доступность больше, чем согласованность.Это также метод обработки по умолчанию, принятый kafka, когда умирают все реплики в isr.Мы можем настроить параметры черезunclean.leader.election.enableЧтобы запретить такое поведение, используйте первый способ.

Так как же ISR достигает синхронизации?

Смещение брокера можно условно разделить на три типа: базовое смещение, верхний водяной знак (HW), смещение конца журнала (LEO).

базовое смещение: начальное смещение, смещение сообщения первого дня в реплике
HW: значение верхнего водяного знака реплики, смещение последнего зафиксированного сообщения в реплике. Значение HW лидера также является диапазоном фактически отправленных сообщений.Каждая реплика имеет значение HW, но только HW в лидере может использоваться в качестве информации для маркировки. Что это значит, то есть, когда резервное копирование сообщения будет успешно завершено по стандарту параметра (после успешной синхронизации с репликой-последователем), значение HW будет обновлено, а это означает, что сообщение теоретически не будет потеряно и может считаться «представленным».
LEO: Перемещение конца лога, то есть смещение следующего сообщения, которое будет записано в реплике, причем оно будет следующим и должно быть записано, а не последним. Это личное чувство ЛЬВА также используется для обозначения прогресса синхронизации последователя. Таким образом, HW представляет расположение данных, которые были синхронизированы, а LEO представляет собой последнее записанное местоположение.Внешний мир может получить доступ только к данным до местоположения HW. Теперь давайте посмотрим, что происходит в черном ящике брокера от получения сообщения до возврата ответа.

Брокер получает запрос производителя
Лидер получает сообщение и успешно пишет его, значение LEO +1
Брокер отправляет сообщение реплике ведомого, и ведомый успешно записывает в LEO +1. …
После того, как все LEO написаны, лидер HW +1
Сообщение может быть использовано, и ответ успешен

Описанный выше процесс можно увидеть на следующем рисунке:

После решения предыдущей проблемы следующий шаг — как Кафка выбирает лидера?

Обычно используемый метод избрания лидеров — это метод выборов большинства, такой как Redis и т. д., но Кафка не использует метод выборов большинства, и Кафка принимает кворум (кворум).

Кворум — это широко используемый алгоритм в распределенных системах, в основном используемый для обеспечения согласованности данных посредством алгоритма голосования по избыточности данных. Реализацией этого алгоритма в Kafka является ISR, то есть кворум, который может быть избран лидером в ISR.

После отказа лидера он может выбрать нового лидера только из списка ISR.Независимо от того, какая реплика в ISR выбрана в качестве нового лидера, он знает данные до HW, что может гарантировать, что после переключения лидера потребители может продолжать просматривать данные, которые были отправлены до HW.
Механизм усечения HW: выбирается новый лидер, и новый лидер не гарантирует, что все данные предыдущего лидера были полностью синхронизированы, синхронизируются только данные до HW.В это время все последователи должны урезаться до местоположения аппаратного обеспечения, а затем синхронизируйте данные с новым лидером для обеспечения согласованности данных. Когда упавший лидер восстанавливается и обнаруживает, что данные в новом лидере несовместимы с данными, которые он содержит, упавший лидер усекает свои данные до позиции hw перед временем простоя, а затем синхронизирует данные нового лидера. Упавший лидер также синхронизирует данные, как и ведомый, для обеспечения согласованности данных.

Если вы чувствуете, что эта статья полезна для вас, пожалуйста, нажмите «Нравится» или подпишитесь на блогера, ваши лайки и внимание будут для меня самой большой мотивацией двигаться вперед!

refer: effectivecoding Официальный сайт блог