Zookeeper е подпроект на Hadoop и въпреки че произлиза от Hadoop, установих, че Zookeeper все повече използва разпределени фреймуъркове извън Hadoop. Днес искам да говоря за Zookeeper, тази статия няма да говори за това как да се използва Zookeeper, а какви са практическите приложения на Zookeeper, какви видове приложения могат да имат предимствата на Zookeeper, и накрая да говорим за ролята на Zookeeper в разпределената архитектура на уебсайтове.
Zookeeper е изключително надеждна координационна система за големи разпределени системи. От тази дефиниция знаем, че zookeeper е координирана система, която действа върху разпределени системи. Защо разпределените системи се нуждаят от координационна система? Причините са следните:
Разработването на разпределена система е много трудно, а трудността се отразява основно в "частичния провал" на разпределената система. "Частична повреда" се отнася до предаването на информация между два възела в мрежата, ако мрежата се повреди, подателят не може да знае дали получателят е получил съобщението, а причината за тази повреда е сложна – получателят може да е получил съобщението преди мрежовата грешка, или процесът на получателя е мъртъв. Единственият начин изпращачът да получи реалната картина е да се свърже отново с получателя и да попита получателя защо е възникнала грешката, която е проблемът с "частичната повреда" в разработката на разпределени системи.
Zookeeper е рамката за решаване на "частичната повреда" на разпределените системи. Zookeeper не позволява на разпределените системи да избегнат проблеми с "частична повреда", но позволява на разпределените системи правилно да се справят с такива проблеми при среща с частични повреди, така че разпределените системи да могат да работят нормално.
Нека поговорим за практическата употреба на Zookeeper:
Сценарий 1: Има група сървъри, които предоставят определена услуга на клиента (например, сървърната страна на разпределения уебсайт, който направих по-рано, е клъстер, съставен от четири сървъра, за да предоставят услуги на фронтенд клъстера), и се надяваме, че клиентът може да намери сървър в сървърния клъстер всеки път, когато клиентът го поиска, така че сървърът да предоставя на клиента услугите, които клиентът изисква. За този сценарий трябва да имаме списък със сървъри в нашата програма, от който четем списъка със сървърите всеки път, когато клиентът го поиска. Тогава този подлист очевидно не може да се съхранява на един възел сървър, иначе възелът ще прекъсне и целият клъстер ще се провали, и се надяваме, че този списък ще бъде много достъпен тогава. Ако сървър в списъка за съхранение е повреден, други сървъри могат незабавно да заменят повредения сървър и повреденият сървър може да бъде премахнат от списъка, така че повреденият сървър да може да се оттегли от работата на целия клъстер, и всички тези операции няма да се изпълняват от повредения сървър, а от нормалния сървър в клъстера. Това е активна разпределена структура от данни, която може активно да променя състоянието на елементите от данни, когато външни условия се променят. Рамката Zookeeper предоставя тази услуга. Името на тази услуга е: Unified Naming Service, което е много подобно на JNDI услугата в javaEE.
Сценарий 2: Разпределена услуга за заключване. Когато разпределена система манипулира данни, като четене на данни, анализ на данни и накрая модифициране на данни. В разпределената система тези операции могат да бъдат разпръснати към различни възли в клъстера, тогава възниква проблем с консистентността в процеса на работа с данни; ако тя е непоследователна, ще получим грешен резултат от операцията; в една единствена програма проблемът с консистентността е лесен за решаване, но е по-трудно да се достигне до разпределената система, тъй като операциите на различните сървъри в разпределената система са в независими процеси, а междинните резултати и процеси на операцията трябва да се предават през мрежата. Тогава е много по-трудно да се постигне консистентност при работа с данни. Zookeeper предоставя услуга за заключване, която решава този проблем, позволявайки ни да осигурим последователност на операциите с данни при извършване на разпределени операции с данни.
Сценарий 3: Управление на конфигурацията. В разпределена система ще разположим приложение за услуга на n сървъра отделно, а конфигурационните файлове на тези сървъри са едни и същи (например, в разпределената уеб рамка, която проектирах, има 4 сървъра от страна на сървъра, програмите на 4-те сървъра са еднакви, а конфигурационните файлове са същите), ако конфигурационните опции на конфигурационните файлове се променят, тогава трябва да ги променяме един по един, ако трябва да променим, сървърите са сравнително малки, тези операции не са прекалено проблемни, Ако имаме голям брой разпределени сървъри, като например Hadoop клъстера на голяма интернет компания с хиляди сървъри, тогава промяната на конфигурационните опции може да бъде проблематична и опасна задача. В този момент zookeeper може да бъде полезен, можем да използваме zookeeper като много достъпна конфигурационна памет, да предадем такова нещо на zookeeper за управление, копираме конфигурационния файл на клъстера в възел от файловата система на zookeeper, а след това използваме zookeeper, за да следим състоянието на конфигурационния файл във всички разпределени системи, след като се установи, че конфигурационният файл е променен, Всеки сървър ще получи известие от Zookeeper за синхронизиране на конфигурационните файлове в Zookeeper, а услугата Zookeeper също ще гарантира, че операцията по синхронизация е атомарна, за да гарантира, че конфигурационният файл на всеки сървър е актуализиран правилно.
Сценарий 4: Осигуряване на функции за възстановяване на повреди за разпределени системи. Управлението на клъстера е трудно, а добавянето на услугата zookeeper към разпределената система улеснява управлението на клъстера. Най-проблемното при управлението на клъстера е управлението на грешки във възлите, zookeeper може да позволи на клъстера да избере здрав възел като главен възел, главният възел ще знае текущото състояние на здравето на всеки сървър в клъстера, а след като възел се повреди, главният ще уведоми останалите сървъри в клъстера, за да преразпредели изчислителните задачи на различните възли. Zookeeper може не само да открива грешки, но и да проверява дефектния сървър, да види какъв вид дефект е сървърът, ако може да бъде отстранена, Zookeeper може автоматично да оправи или да каже на системния администратор причината за грешката, така че администраторът бързо да го открие и да отстрани проблема на възела. Може би все още имате въпрос – какво да направя, ако главният монитор е дефектен? Zookeeper също взема предвид това – Zookeeper има вътрешен "алгоритъм за избор на лидери", майсторите могат да се избират динамично, а когато главният се провали, Zookeeper може веднага да избере нов майстор за управление на клъстера.
Нека поговорим за функциите на Zookeeper:
ZooKeeper е опростена файлова система. Това е малко подобно на Hadoop, но файловата система ZooKeeper управлява малки файлове, докато Hadoop управлява много големи.
Zookeeper предоставя богатство от "артефакти", които позволяват на много операции да координират структури от данни и протоколи. Например: разпределени опашки, разпределени заключвания и алгоритъмът за "избор на лидер" на група възли на едно и също ниво.
ZooKeeper е много достъпен, собствената му стабилност е доста добра, разпределените клъстери могат да разчитат на управлението на клъстерите на Zookeeper, а ZooKeeper се използва за избягване на проблема с едноточкова повреда на разпределени системи.
Zookeeper използва слабо свързан режим на взаимодействие. Това е най-очевидно във факта, че Zookeeper предоставя разпределени заключвания, които могат да се използват като механизъм за назначаване, позволяващ участващите процеси да откриват и взаимодействат помежду си, без да познават другите процеси (или мрежата), а участващите страни дори не е задължително да съществуват едновременно, стига да оставят съобщение в zookeeper, а след края на процеса друг процес може да прочете това съобщение, като по този начин разчленява връзката между възлите.
ZooKeeper предоставя споделено хранилище за клъстера, от което клъстерът може централно да чете и записва споделена информация, като се избягва програмирането на споделени операции за всеки възел и се намалява трудността при разработката на разпределени системи.
Zookeeper е основно отговорен за съхранението и управлението на данните, които са важни за всички, а след това приемането на регистрация на наблюдатели; след като статусът на тези данни се промени, Zookeeper ще бъде отговорен за уведомяване на регистрираните наблюдатели в Zookeeper да реагират съответно, за да постигнат режим на управление на master/slave, подобен на клъстера.
Вижда се, че Zookeeper е много благоприятен за разработката на разпределени системи, което може да направи разпределените системи по-устойчиви и ефективни.
Неотдавна участвах в групата по интереси към hadoop на отдела и инсталирах hadoop, mapreduce, Hive и Hbase в тестовата среда, а Zookeeper инсталирах предварително при инсталирането на hbase. Zookeeper може да предоставя услуги, така че повече от половината от 3 са 2, а повече от половината от 4 също са два, така че инсталирането на три сървъра може да постигне ефекта от 4 сървъра. В процеса на учене на Hadoop чувствам, че Zookeeper е най-трудният подпроект за разбиране, причината не е, че е технически отговорен, а че посоката на приложението му ми е много объркваща, затова първата ми статия за Hadoop технологията започва с Zookeeper и не говори за конкретна техническа имплементация, но от сценариите за приложение на Zookeeper, разбирам областта на приложението на Zookeeper, мисля, че ученето на Zookeeper ще бъде по-ефективно с половината усилия.
Причината, поради която искам да говоря за zookeeper днес, е да допълня рамката за разпределени уебсайтове от предишната ми статия. Въпреки че проектирах архитектурата на уебсайта да бъде разпределена структура, създадох и прост механизъм за обработка на грешки, като механизма за сърдечен ритъм, но все още няма начин да се реши единствената точка на повреда на клъстера – ако сървърът е повреден, клиентът ще се опита да се свърже с него, което води до блокиране на някои заявки и също така до загуба на ресурси на сървъра. Въпреки това, в момента не искам да променям рамката си, защото винаги смятам, че добавянето на zookeeper услуга към съществуващите услуги ще повлияе на ефективността на уебсайта. За щастие, нашият отдел също откри такъв проблем – той ще разработи мощна рамка за отдалечени обаждания, ще отдели управлението на клъстера и комуникационното управление и ще предостави ефективни и налични услуги централизирано.
Прехвърлен от ttp://www.cnblogs.com/sharpxiajun/archive/2013/06/02/3113923.html |
Публикувано в 18.07.2017 г. 14:19:01 ч.
|
|
|
