Проблемы с высокой доступностью, вызванные простоем Kafka

Проблема начинается с простоя Kafka.

Автором является финансовая технологическая компания, но компания не приняла на вооружение более популярную в сфере финансовых платежей.RabbitMQ, но использует дизайн, изначально предназначенный для обработки журналов.Kafka, поэтому мне всегда было интересно узнать о реализации и гарантиях высокой доступности Kafka. С тех пор, как Kafka была развернута, Kafka, используемая в системе, работала стабильно без каких-либо недоступностей.

Однако в последнее время системные тестировщики часто сообщали о том, что потребители Kafka время от времени не получали сообщения.После входа в интерфейс управления было обнаружено, что один из трех узлов не работает и зависает. Однако, согласно концепции высокой доступности, почему доступны три узла и два узла, так что потребители всего кластера не могут получать сообщения?

Чтобы решить эту проблему, мы должны начать с реализации высокой доступности Kafka.

Многокопийная избыточность Kafka

Будь то традиционная система, основанная на реляционной базе данных, или распределенная система, такая какzookeeper,redis,Kafka,HDFSИ т. д., способ достижения высокой доступности обычно заключается в использовании избыточной конструкции для решения проблемы простоя и недоступности узла за счет избыточности.

Во-первых, кратко разберем несколько концепций Кафки:

• физическая модель

• логическая модель

• Broker(узел): сервисный узел Kafka, просто одинBrokerЭто сервер Kafka, физический узел.

• Topic(тема): В Kafka сообщения классифицируются по темам, и каждая тема имеетTopic Name, производитель отправляет сообщение в определенную тему в соответствии с названием темы, а потребитель также получает сообщение из соответствующей темы в соответствии с именем темы.

• Partition(раздел):Topic(тема) — это единица классификации сообщений, но каждая тема может быть дополнительно подразделена на одну или несколькоPartition(раздел), раздел может принадлежать только одной теме. И темы, и разделы являются логическими понятиями.Например, и сообщение 1, и сообщение 2 отправляются в тему 1, и они могут поступать в один и тот же раздел или в разные разделы (таким образом, сообщения, содержащиеся в разных разделах одной и той же темы, различны), и затем он будет отправлен на узел Broker, соответствующий разделу.

• Offset(смещение): раздел можно рассматривать как очередь, в которую можно только войти, но нельзя (Kafka гарантирует только упорядоченность сообщений в разделе), сообщение будет добавлено в конец очереди, и каждое сообщение будет получить сообщение после входа в раздел. Смещение, определяющее положение сообщения в разделе. Потребители хотят получить сообщение, указав смещение.

В самом деле, в соответствии с несколькими концепциями, приведенными выше, это не то, насколько Кафка догадался, что несколько избыточных копий спроектированы и реализованы? Не волнуйтесь, мы продолжаем смотреть вниз.

До версии Kafka 0.8 не существовало механизма резервирования нескольких копий.PartitionДанные больше не могут быть использованы. Это означает, что часть данных, отправленных в тему, теряется.

Внедрение репортеров копирования после версии 0.8 — хорошее решение проблемы потери данных после простоя. копияTopicкаждый изPartitionДанные каждого раздела синхронизируются с другими физическими узлами для формирования нескольких копий.

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

Это так просто? Да, на основе приведенной выше схемы многокопийной архитектуры достигается высокая доступность Kafka. когдаBrokerПовесьте трубку, не волнуйтесь, этоBrokerВверхPartitionВ другомBrokerНа узлах также есть реплики. Вы сказали, что если вы повесите трубкуLeaderчто делать? то естьFollowerизбраниеLeaderТо есть производители и потребители могут общаться с новымLeaderПолучайте удовольствие, играя, это высокая доступность.

У вас могут остаться вопросы, сколько копий достаточно? Что делать, если нет полной синхронизации между Последователем и Лидером? Каково правило выбора лидера после отказа узла?

Сразу к выводу:

Сколько копий достаточно?Чем больше реплик, тем более высокая доступность Kafka может быть гарантирована, но чем больше реплик, тем больше потребление сетевых и дисковых ресурсов, а производительность будет снижаться.Вообще говоря, для обеспечения высокой доступности количество реплик равно 3. В крайних случаях будетreplication-factorПараметр можно увеличить.

Что делать, если нет полной синхронизации между Подписчиком и Лидом?Ведомый и ведущий не полностью синхронны, но и не полностью асинхронны, но принимаютISRмеханизм(In-Sync Replica). Каждый лидер будет динамически поддерживать список ISR, в котором хранятся последователи, которые в основном синхронизированы с лидером. Если ведомый не инициирует запрос на извлечение данных к ведущему из-за сети, GC и т. д., ведомый не синхронизируется с ведущим и будет исключен из списка ISR. Следовательно, Последователи в списке ISR — это все копии, которые могут не отставать от Лидера.

Каково правило выбора лидера после отказа узла?Существует много распределенных связанных правил выбора, таких как Zookeeper.Zab,Raft,Viewstamped Replication, МайкрософтPacificAЖдать. Идея избрания вождя Кафкой очень проста, исходя из упомянутого вышеISRList, когда он не работает, будет искать последовательно со всех реплик, если найденная реплика есть в списке ISR, то она будет выбрана ведущей. Кроме того, необходимо следить, чтобы бывший лидер уже находился в состоянии отречения, иначе возникнет ситуация с раздвоением мозгов (лидеров два). Как гарантировать? Kafka гарантирует наличие только одного лидера, устанавливая контроллер.

Параметр Ack определяет надежность

Кроме того, вот необходимая точка знаний для интервью с высокой доступностью Kafka:request.required.acksпараметр.

Этот параметр Acks является важной конфигурацией клиента производителя, и этот параметр можно установить при отправке сообщения. Этот параметр имеет три настраиваемых значения:0, 1, Все.

Первый установлен в 0, что означает, что после того, как производитель отправит сообщение, нам все равно, живо сообщение или мертво, а это означает, что после отправки оно забыто, и он не несет ответственности за сказанное. Если вы не несете ответственности, это сообщение может быть потеряно, и тогда доступность будет потеряна.

Второй установлен на 1, что означает, что после того, как производитель отправит сообщение, пока сообщение успешно передано лидеру, не имеет значения, синхронизированы ли другие подписчики или нет. Возникает ситуация, когда лидер только что получил сообщение, а фолловер еще не успел синхронизировать брокера, а производитель уже подумал, что сообщение успешно отправлено, поэтому сообщение в это время теряется. Уведомление,Значение 1 — это конфигурация Kafka по умолчанию.! ! ! Видно, что конфигурация Kafka по умолчанию не так высокодоступна, а представляет собой компромисс между высокой доступностью и высокой пропускной способностью.

Третий - установить на Все (или -1), что означает, что после того, как производитель отправит сообщение, его должен получить не только Лидер, но и Последователи в списке ISR должны быть синхронизированы, чтобы производитель успешно отправил сообщение задачи.

Думай дальше,Acks=AllНе будет ли потери сообщений? Ответ - нет. Когда в списке ISR остается только Лидер,Acks=AllэквивалентноAcks=1, в этом случае, если нода выйдет из строя, может ли она еще гарантировать, что данные не будут потеряны? Поэтому только вAcks=AllИ в ISR есть две копии, чтобы данные не были потеряны.

Решать проблему

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

Я настроил в тестовой среде разработкиBrokerКоличество узлов 3,Topicв том, что количество копий равно 3,PartitionЧисло 6,AsksПараметр равен 1.

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

Таким образом, пока количество реплик Topic установлено таким же, как количество Brokers, многокопийная избыточность Kafka может обеспечить высокую доступность, и не будет ситуации, когда она будет недоступна после простоя (но это следует отметить, что у Kafka есть стратегия защиты A, Kafka останавливается, когда больше половины узлов недоступно). Тогда хорошенько подумайте, есть ли Тема с репликой номер 1 по Кафке?

проблема в__consumer_offsetначальство,__consumer_offsetКафка создается автоматическиTopic, используется для хранения потребительского потребленияoffset(смещение) информация, по умолчаниюPartitionЧисло 50. Это тема, и ее количество копий по умолчанию равно 1. я упалPartitionВсе они существуют на одной машине, что является очевидной единственной точкой отказа! при хранении__consumer_offsetПосле того, как Брокер Раздела даст «Убить», он обнаружит, что все потребители прекратили потребление.

Как решить эту проблему?

Первая точка, нужно быть__consumer_offsetУдалить, обратите внимание на встроенный в Кафку Топик, когда используется этот Топик, его нельзя удалить командой.logsУдалено для достижения удаления.

Второй момент, вам нужно установитьoffsets.topic.replication.factorна 3 будущее__consumer_offsetКоличество копий изменено на 3.

поставив__consumer_offsetОн также копирует избыточность, а затем решает проблему потребления потребителей после выхода узла из строя.

Наконец, о том, почему__consumer_offsetРаздел будет храниться только на одном Брокере, а не распределяться по каждому Брокеру. Я в замешательстве. Если кто-то знает об этом, пожалуйста, сообщите~

В этой статье используетсяmdniceнабор текста