Визуализация наиболее непонятого параметра конфигурации Kafka

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

Эти две конфигурации acks и min.insync.replicas - и как они взаимодействуют друг с другом.

Эта статья призвана быть удобной справочной информацией, которая устраняет путаницу с помощью некоторых иллюстраций.

Репликация

Чтобы лучше понять эти конфигурации, полезно напомнить себе о протоколе репликации Kafka.

Я предполагаю, что вы уже знакомы с Kafka - если нет, не стесняйтесь прочитать мою статью Тщательное введение в Apache Kafka.

Для каждого раздела существует один ведущий брокер и n ведомых брокеров.
Конфигурация, которая определяет, сколько таких брокеров (1 + N) существует, - replication.factor. Это общее количество репликаций данных внутри одного раздела в кластере.

Стандартная и типичная рекомендация - три.

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

Синхронизированные реплики

синхронизируемая реплика (ISR) - это брокер, у которого есть последние данные для данного раздела. Лидер всегда является синхронизированной репликой. подписчик является синхронизированной репликой только в том случае, если он полностью догнал раздел, за которым следит. Другими словами, он не может отставать от последних записей для данного раздела.

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

Обратите внимание, что способ определения того, является ли реплика синхронизированной или нет, немного более тонок - это не так просто, как "Есть ли у брокера последняя запись?" Обсуждение этого выходит за рамки данной статьи. А пока поверьте мне, что красные брокеры с улитками на них не синхронизированы.

Благодарности

Параметр acks - это конфигурация клиента (производителя). Он обозначает количество брокеров, которые должны получить запись, прежде чем мы сочтем запись успешной. Он поддерживает три значения - 0, 1 и all.

‘Acks = 0’

При значении 0 производитель даже не будет ждать ответа от брокера. Он немедленно считает запись успешной в момент отправки записи.

‘Acks = 1’

При установке 1 производитель будет считать запись успешной, когда ведущий получит запись. Брокер-лидер будет знать, что нужно немедленно ответить, как только он получит запись, и больше не ждать.

‘Acks = all’

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

Как я уже сказал, ведущий брокер знает, когда отвечать производителю, использующему acks=all.

Утилита Acks

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

Если вы хотите, чтобы ваши записи были хорошими и безопасными, настройте свои подтверждения на all.

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

Минимальная синхронизированная реплика

В изолированной конфигурации acks=all отсутствует одна вещь.
Если лидер отвечает, когда все синхронизированные реплики получили запись, что происходит, когда лидер является единственной синхронизированной репликой? Разве это не эквивалентно настройке acks=1?

Вот где сияет min.insync.replicas!

min.insync.replicas - это конфигурация брокера, обозначающая минимальное количество синхронизируемых реплик, необходимых для брокера, чтобы разрешить acks=all запросы. То есть все запросы с acks=all не будут обработаны и получат ответ об ошибке, если количество синхронизируемых реплик меньше установленного минимального количества. Он действует как своего рода привратник, чтобы исключить возможность возникновения сценариев, подобных описанному выше.

Как показано, min.insync.replicas=X позволяет acks=all запросам продолжать работу, когда хотя бы x реплик раздела синхронизированы. Здесь мы видели пример с двумя репликами.

Но если мы опустимся ниже этого значения синхронизированных реплик, производитель начнет получать исключения.

Как видите, производители с acks=all не могут успешно выполнять запись в раздел в такой ситуации. Обратите внимание, однако, что производители с acks=0 или acks=1 продолжают работать нормально.

Предостережение

Распространенное заблуждение состоит в том, что min.insync.replicas обозначает, сколько реплик должно получить запись, чтобы лидер ответил производителю. Это неправда - конфигурация - это минимальное количество синхронизируемых реплик, которые должны существовать для обработки запроса.

То есть, если есть три синхронизированных реплики и min.insync.replicas=2, лидер ответит только тогда, когда все три реплики будут иметь запись.

Резюме

Вот и все! Просто визуализируйте, не правда ли?

Напомним, что параметры acks и min.insync.replicas - это то, что позволяет вам настроить предпочтительные требования к устойчивости для записи в вашем кластере Kafka.

  • acks=0 - запись считается успешной в момент отправки запроса. Не нужно ждать ответа.
  • acks=1 - лидер должен получить запись и ответить, прежде чем запись будет считаться успешной.
  • acks=all - все синхронизированные реплики в сети должны получить запись. Если в сети меньше min.insync.replicas, запись не будет обработана.

Дальнейшее чтение

Kafka - это сложная распределенная система, поэтому есть еще много чего узнать!
Вот несколько ресурсов, которые я могу порекомендовать в качестве дополнения:

Kafka активно развивается - возможности и надежность только растут благодаря здоровому сообществу. Чтобы лучше следить за его развитием, я бы рекомендовал присоединиться к спискам рассылки.

Спасибо, что нашли время, чтобы прочитать это.

Если вам понравилось, проверьте, сколько раз вы можете нажать 👏 за 5 секунд. Это отличное кардио для ваших пальцев И поможет другим людям увидеть историю.
Вы можете подписаться на меня в Twitter на @StanKozlovski, чтобы поговорить о программировании, технологиях, стартапах, здоровье, инвестициях, а также узнать, когда будут выходить новые статьи. !