Phenquestions
Моля, обърнете внимание, че това не е уводен урок. Моля, прочетете Какво е Apache Kafka и как работи, преди да продължите с този урок, за да получите по-задълбочена представа.
Теми в Кафка
Темата в Kafka е нещо, където се изпраща съобщение. Потребителските приложения, които се интересуват от тази тема, привличат съобщението вътре в тази тема и могат да направят всичко с тези данни. До определен час произволен брой потребителски приложения могат да изтеглят това съобщение неограничен брой пъти.
Помислете за тема като страницата на блога на Ubuntu на LinuxHint. Уроците са поставени до вечността и произволен брой ентусиазирани читатели могат да дойдат и да прочетат тези уроци произволен брой пъти или да преминат към следващия урок, както желаят. Тези читатели могат да се интересуват и от други теми от LinuxHint.
Разделяне на теми
Kafka е проектиран да управлява тежки приложения и да поставя на опашка голям брой съобщения, които се съхраняват в дадена тема. За да се осигури висока толерантност към грешки, всяка тема е разделена на множество тематични дялове и всеки дял на темата се управлява на отделен възел. Ако един от възлите слиза надолу, друг възел може да действа като лидер на темата и може да сървира теми на заинтересованите потребители. Ето как едни и същи данни се записват в множество тематични дялове:
Тематични дялове
Сега горното изображение показва как едни и същи данни се репликират в множество дялове. Нека визуализираме как различните дялове могат да действат като лидер на различни възли / дялове:
Разделяне на Kafka Broker
Когато клиент пише нещо в тема на позиция, за която дялът в Broker 0 е водещ, тези данни след това се репликират в брокерите / възлите, така че съобщението да остане в безопасност:
Репликация в брокерски дялове
Повече дялове, по-висока производителност
Кафка използва Паралелизъм да осигури много висока производителност на приложенията за производители и потребители. Всъщност по същия начин той запазва статута си на високоустойчива на повреди система. Нека разберем колко висока производителност се постига с паралелизъм.
Когато приложение на Producer напише някакво съобщение към дял в Broker 0, Kafka отваря паралелно множество нишки, така че съобщението да може да бъде реплицирано едновременно във всички избрани брокери. От страна на потребителя потребителското приложение консумира съобщения от един дял чрез нишка. Колкото повече е броят на дяловете, толкова повече потребителски нишки могат да бъдат отворени, за да могат всички те да работят паралелно. Това означава, че колкото повече е броят на дяловете в клъстер, толкова повече паралелизъм може да бъде използван, създавайки много висока производителност.
Повече дялове се нуждаят от повече обработчици на файлове
Точно така, за да проучите по-горе как можем да увеличим производителността на системата Kafka, като просто увеличим броя на дяловете. Но трябва да внимаваме с каква граница се движим.
Всеки темен дял в Kafka се преобразува в директория във файловата система на сървърния посредник, където се изпълнява. В тази директория на дневника ще има два файла: един за индекса и друг за действителните данни на лог сегмент. Понастоящем в Kafka всеки брокер отваря дескриптор на файл както за индекса, така и за файла с данни на всеки лог сегмент. Това означава, че ако имате 10 000 дяла на един брокер, това ще доведе до паралелно изпълнение на 20 000 обработчика на файлове. Въпреки това, това е само за конфигурацията на брокера. Ако системата, на която е разположен Брокерът, има висока конфигурация, това едва ли ще бъде проблем.
Риск с голям брой дялове
Както видяхме на изображенията по-горе, Kafka използва техниката на репликация в рамките на клъстера, за да репликира съобщение от лидер към дяловете Replica, които се намират в други брокери. Както производителите, така и потребителските приложения четат и пишат в дял, който в момента е лидер на този дял. Когато брокерът се провали, лидерът на този брокер ще стане недостъпен. Метаданните за това кой е водач се съхраняват в Zookeeper. Въз основа на тези метаданни Kafka автоматично ще назначи ръководството на дяла на друг дял.
Когато брокер се изключи с чиста команда, възелът на контролера на клъстера Kafka ще премести последователно лидерите на изключващия брокер i.д. един по един. ако помислим, че преместването на един лидер отнема 5 милисекунди, липсата на лидери няма да наруши потребителите, тъй като липсата е за много кратък период. Но ако вземем предвид кога Брокерът е убит по нечист начин и този Брокер съдържа 5000 дяла и от тях 2000 бяха ръководителите на разделянето, назначаването на нови лидери за всички тези дялове ще отнеме 10 секунди, което е много високо, когато става въпрос за силно търсени приложения.
Заключение
Ако разглеждаме като мислител на високо ниво, повече дялове в клъстер на Kafka водят до по-голяма производителност на системата. Имайки предвид тази ефективност, трябва да се вземе предвид и конфигурацията на клъстера Kafka, която трябва да поддържаме, паметта, която трябва да присвоим на този клъстер, и как можем да управляваме наличността и латентността, ако нещо се обърка.
Прочетете повече публикации, базирани на Ubuntu тук, и много повече за Apache kafka.
