Един от ключовите компоненти на гаранциите за издръжливост и наличност на Kafka е репликацията.

Производителите от друга страна имат някои възможности за избор кога да получат потвърждение за успеха или неуспеха на заявка за продукция от брокера.

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

  • Конфигурацията на производителя, потвърждава, влияе пряко върху гаранциите за издръжливост. И също така осигурява една от няколко точки за компромис между издръжливост и латентност.
  • Задаването на acks=0, известно още като режим „задействане и забравяне“, осигурява по-ниска латентност, тъй като производителят не чака отговор от брокера.
  • Но тази настройка не предоставя силна гаранция за издръжливост, тъй като лидерът на дяла може никога да не получи данните поради преходен проблем със свързването или може да преминем през избор на лидер.

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

  • С acks=1 имаме малко по-добра издръжливост, тъй като знаем, че данните са записани в водещата реплика, но имаме малко по-висока латентност, тъй като чакаме всички стъпки в процеса на изпращане на заявка, който видяхме в Модул „Вътре в Apache Kafka Broker“.
  • Също така не се възползваме напълно от репликацията, защото не чакаме данните да се приземят в репликите на последователите.

Производителят потвърждава = всички

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

Тема min.insync.replicas

  • Конфигурацията на ниво тема, min.insync.replicas, работи заедно с конфигурацията на acks за по-ефективно налагане на гаранции за издръжливост. Тази настройка казва на брокера да не позволява събитие да бъде записвано в тема, освен ако няма N реплики в ISR.
  • В комбинация с acks=all, това гарантира, че всички събития, получени в темата, ще бъдат съхранени в N реплики, преди изпращането на събитието да бъде потвърдено.

Идемпотентност на производителя

  • Kafka също има гаранции за подреждане, които се управляват главно от разделянето на Kafka и факта, че дяловете са неизменни регистрационни файлове само за добавяне.
  • Събитията се записват в конкретен дял в реда, в който са изпратени, и потребителите четат тези събития в същия ред. Неуспехите обаче могат да доведат до записване на дублирани събития в дяла, което ще наруши подреждането.
  • За да предотвратим това, можем да използваме Idempotent Producer, който гарантира, че дублиращи се събития няма да бъдат изпратени в случай на повреда.

Гаранция за поръчка от край до край

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

И ако търсите обобщени статии за Apache Kafka, можете също да проверите предишните ми статии като Основни концепции на Kafka и неговите ключови принципи, Защо Apache Kafka е бърз ?

Не забравяйте да натиснете бутоните Clap и Follow, за да ми помогнете да напиша повече статии като тази.

Референции