Одним из ключевых компонентов гарантии надежности и доступности Kafka является репликация.

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

Подтверждений производителя = 0

  • Конфигурация производителя, acks, напрямую влияют на гарантии долговечности. И это также обеспечивает одну из нескольких точек компромисса между долговечностью и задержкой.
  • Установка acks=0, также известная как режим «запустить и забыть», обеспечивает меньшую задержку, поскольку производитель не ждет ответа от брокера.
  • Но этот параметр не дает надежной гарантии надежности, поскольку лидер раздела может никогда не получить данные из-за временной проблемы с подключением или мы можем пройти через выборы лидера.

Подтверждений производителя = 1

  • С acks=1 у нас немного выше надежность, так как мы знаем, что данные были записаны в ведущую реплику, но у нас немного больше задержка, так как мы ждем всех шагов в процессе отправки запроса, которые мы видели в Модуль Внутри Apache Kafka Broker.
  • Мы также не используем все преимущества репликации, потому что не ждем, пока данные попадут в последующие реплики.

Подтверждения производителя = все

  • Наивысший уровень устойчивости достигается при acks=all (или acks=-1), что также является значением по умолчанию. При использовании этого параметра запрос на отправку не подтверждается до тех пор, пока данные не будут записаны в ведущую реплику и во все последующие реплики в списке ISR (синхронизированные реплики).
  • Теперь мы вернулись к ситуации, когда мы могли потерять N-1 узлов и не потерять никаких данных. Однако это будет иметь более высокую задержку, поскольку мы ждем завершения процесса репликации.

Тема min.insync.replicas

  • Конфигурация на уровне темы, min.insync.replicas, работает вместе с конфигурацией acks для более эффективного обеспечения гарантий устойчивости. Этот параметр указывает брокеру не разрешать запись события в тему, если в ISR нет N реплик.
  • В сочетании с acks=all это гарантирует, что любые события, полученные в теме, будут храниться в N репликах до подтверждения отправки события.

Продюсер Идемпотентность

  • У Kafka также есть гарантии порядка, которые обрабатываются в основном разделением Kafka и тем фактом, что разделы являются неизменяемыми журналами только для добавления.
  • События записываются в конкретный раздел в том порядке, в котором они были отправлены, и потребители читают эти события в том же порядке. Однако сбои могут привести к тому, что в раздел будут записаны повторяющиеся события, что приведет к нарушению порядка.
  • Чтобы предотвратить это, мы можем использовать Idempotent Producer, который гарантирует, что повторяющиеся события не будут отправлены в случае сбоя.

Гарантия сквозного заказа

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

И, если вы ищете краткие статьи об Apache Kafka, вы также можете ознакомиться с моими предыдущими статьями, такими как Основные концепции Kafka и ее ключевые принципы, Почему Apache Kafka быстр ?

Не забывайте нажимать кнопки «Аплодисменты» и «Подписаться», чтобы помочь мне написать больше подобных статей.

Ссылки