Предлагам да прочетете стенограмата на лекцията "Hadoop. ZooKeeper" от поредицата "Методи за разпределена обработка на големи количества данни в Hadoop"
Какво е ZooKeeper, неговото място в екосистемата Hadoop. Лъжата за разпределените изчисления. Схема на стандартна разпределена система. Трудност при координиране на разпределени системи. Типични проблеми с координацията. Принципите зад дизайна на ZooKeeper. Модел на данни ZooKeeper. znode флагове. Сесии. API на клиента. Примитиви (конфигурация, групово членство, прости ключалки, избор на лидер, заключване без стаден ефект). Архитектура на ZooKeeper. ZooKeeper DB. ZAB. Обработчик на заявки.
Днес ще говорим за ZooKeeper. Това нещо е много полезно. Той, както всеки продукт на Apache Hadoop, има лого. Изобразява човек.
Преди това говорихме основно за това как могат да се обработват данни там, как да се съхраняват, тоест как да се използват по някакъв начин и да се работи с тях по някакъв начин. И днес бих искал да поговоря малко за изграждането на разпределени приложения. А ZooKeeper е едно от онези неща, които го правят лесно. Това е вид услуга, която е предназначена за някакъв вид координация на взаимодействието на процесите в разпределени системи, в разпределени приложения.
Нуждата от такива приложения става все по-голяма и по-голяма всеки ден, това е темата на нашия курс. От една страна, MapReduce и тази готова рамка ви позволява да изравните тази сложност и да освободите програмиста от писане на примитиви като взаимодействие, координация на процеси. Но от друга страна, никой не гарантира, че това няма да се наложи да се направи така или иначе. Не винаги MapReduce или други готови рамки заместват напълно някои случаи, които не могат да бъдат внедрени в този. Включително самия MapReduce и куп други проекти на Apache, те всъщност също са разпределени приложения. И за да се пише по-лесно, са написали ZooKeeper.
Както всички приложения, свързани с Hadoop, то е разработено от Yahoo! Сега това е и официалното приложение на Apache. Не се развива толкова активно, колкото HBase. Ако отидете на JIRA HBase, тогава всеки ден има много задачи за грешки, много предложения за оптимизиране на нещо, тоест животът в проекта непрекъснато продължава. А ZooKeeper, от една страна, е сравнително прост продукт, а от друга, това гарантира неговата надеждност. И е доста лесен за използване, поради което се превърна в стандарт в приложенията в рамките на екосистемата Hadoop. Затова реших, че би било полезно да го прегледам, за да разбера как работи и как да го използвам.
Това е снимка от някаква лекция, която имахме. Можем да кажем, че е ортогонален на всичко, което разгледахме досега. И всичко, което е посочено тук, в една или друга степен работи с ZooKeeper, тоест това е услуга, която използва всички тези продукти. Нито HDFS, нито MapReduce пишат свои собствени подобни услуги, които биха работили специално за тях. Съответно се използва ZooKeeper. И това опростява разработката и някои неща, свързани с грешки.
Откъде идва всичко това? Изглежда, че стартираха две приложения паралелно на различни компютри, свързаха ги с кабел или в мрежа и всичко работи. Но проблемът е, че мрежата е ненадеждна и ако подушите трафика или погледнете какво се случва там на ниско ниво, как клиентите взаимодействат в мрежата, често можете да видите, че някои пакети са загубени, изпратени повторно. Не напразно са измислили TCP протоколи, които ви позволяват да установите определена сесия и да гарантирате доставката на съобщения. Но във всеки случай дори TCP не винаги може да спаси. Всичко има таймаут. Мрежата може просто да падне за известно време. Тя може само да мига. И всичко това води до факта, че не можете да разчитате на факта, че мрежата е надеждна. Това е основната разлика от писането на паралелни приложения, които работят на един компютър или на някой суперкомпютър, където няма мрежа, където има по-надеждна шина за обмен на данни в паметта. И това е фундаменталната разлика.
Освен всичко друго, при използване на мрежата винаги има известно забавяне. Дискът също го има, но в мрежата има повече. Латентността е някакъв вид време на забавяне, което може да бъде както малко, така и доста значително.
Топологията на мрежата се променя. Това, което е топология, е разположението на нашето мрежово оборудване. Има центрове за данни, има стелажи, които стоят там, има свещи. Всичко това може да бъде повторно свързано, преместено и т.н. Всичко това също трябва да се вземе предвид. IP адресите се променят, маршрутизирането се променя, през което имаме трафик. Това също трябва да се вземе предвид.
Мрежата може да се промени и по отношение на оборудването. От практиката мога да кажа, че нашите мрежови инженери много обичат периодично да актуализират нещо на свещите. Изведнъж излиза нов фърмуер и те не се интересуват особено от някакъв Hadoop клъстер. Те имат собствена работа. За тях основното е Мрежата да работи. Съответно искат да прекачат нещо там, да направят флашване на техния хардуер, като и хардуера се сменя периодично. Всичко това трябва да се вземе предвид по някакъв начин. Всичко това се отразява на нашето разпределено приложение.
Обикновено хората, които започват да работят с голямо количество данни, по някаква причина вярват, че мрежата е безгранична. Ако има файл от няколко терабайта, тогава можете да го занесете на вашия сървър или компютър, да го отворите с котка и гледайте. Друга от грешките е Vim гледайте дневници. Никога не го правете, защото е лошо. Тъй като Vim се опитва да буферира всичко, да зареди всичко в паметта, особено когато започнем да навигираме в този журнал и да търсим нещо. Това са неща, които са забравени, но си струва да се помисли.
По-лесно е да напишете една програма, която да работи на един компютър с един процесор.
Когато системата ни расте, ние искаме да паралелизираме всичко това, и да паралелизираме не само на компютър, но и на клъстер. Възниква въпросът - как да координираме този бизнес? Нашите приложения може дори да не взаимодействат помежду си, но стартирахме няколко процеса паралелно на няколко сървъра. И как да следят дали всичко им върви? Те, например, изпращат нещо по мрежата. Те трябва да пишат някъде за своето състояние, например в някаква база данни или в дневник, след това да обобщят този дневник и след това да го анализират някъде. Освен това трябва да вземете предвид, че процесът е работил, работил, внезапно в него се е появила някаква грешка или се е сбил, тогава колко бързо ще разберем за това?
Ясно е, че всичко това може бързо да се следи. Това също е добре, но мониторингът е ограничено нещо, което ви позволява да наблюдавате някои неща на най-високо ниво.
Когато искаме нашите процеси да започнат да взаимодействат помежду си, например да си изпращат някакви данни, тогава също възниква въпросът - как ще стане това? Ще има ли някакво състезателно условие, ще се презаписват ли, данните ще пристигнат ли правилно, губи ли се нещо по пътя? Необходимо е да се разработи някакъв протокол и т.н.
Координацията на всички тези процеси не е тривиално нещо. И това принуждава разработчика да отиде още по-ниско и да напише системи от нулата или не напълно от нулата, но не е толкова лесно.
Ако сте измислили криптографски алгоритъм или дори сте го внедрили, вземете го и го изхвърлете веднага, защото най-вероятно няма да работи за вас. Най-вероятно ще съдържа куп грешки, които сте забравили да предвидите. В никакъв случай не го използвайте за нещо сериозно, защото най-вероятно ще бъде нестабилно. Тъй като всички алгоритми, които съществуват, те са тествани от времето за много дълго време. Търси се за грешки от общността. Това е отделен въпрос. И тук е същото. Ако е възможно да не реализирате сами някаква синхронизация на процеси, тогава е по-добре да не го правите, защото е доста трудно и ви води по нестабилния път на постоянно търсене на грешки.
Днес говорим за ZooKeeper. От една страна, това е рамка, от друга страна, това е услуга, която улеснява живота на разработчика и улеснява максимално прилагането на логиката и координирането на нашите процеси.
Спомнете си как може да изглежда една стандартна разпределена система. Това е, за което говорихме - това е HDFS, HBase. Има главен процес, който управлява работници, подчинени процеси. Той отговаря за координирането и разпределянето на задачите, рестартирането на работници, стартирането на нови и балансирането на натоварването.
По-напреднало нещо е Coordination Service, т.е. преместете самата координационна задача в отделен процес, плюс паралелно стартирайте някакъв вид архивиране или режим на готовност на Master, защото Master може да се срине. И ако Учителят падне, тогава нашата система няма да работи. Изпълняваме резервно копие. Някои гласят, че главният трябва да бъде копиран в резервно копие. Това може да бъде поверено и на службата за координация. Но в тази схема самият магистър координира работниците, тук услугата координира репликацията на данни.
По-усъвършенстван вариант е, когато нашата служба извършва цялата координация, както обикновено се прави. Той поема отговорността да гарантира, че всичко работи. И ако нещо не работи, ние разбираме за това и се опитваме да заобиколим тази ситуация. Във всеки случай оставаме с Master, който по някакъв начин взаимодейства с робите, може да изпраща данни, информация, съобщения и т.н. чрез определена услуга.
Има още по-напреднала схема, когато нямаме Master, всички възли са master-slave, различни в поведението си. Но все пак те трябва да взаимодействат помежду си, така че все още има определена услуга за координиране на тези действия. Вероятно Касандра, която работи на този принцип, отговаря на тази схема.
Трудно е да се каже коя от тези схеми работи най-добре. Всеки има своите плюсове и минуси.
И няма нужда да се страхувате от някои неща с Учителя, защото, както показва практиката, той не е толкова склонен да дава постоянно. Основното нещо тук е да изберете правилното решение за хостване на тази услуга на отделен мощен възел, така че да има достатъчно ресурси, така че, ако е възможно, потребителите да нямат достъп там, за да не убият случайно този процес. Но в същото време в такава схема е много по-лесно да се управляват работници от главния процес, т.е. тази схема е по-проста по отношение на изпълнението.
И тази схема (по-горе) може би е по-сложна, но по-надеждна.
Основният проблем са частичните повреди. Например, когато изпращаме съобщение по мрежата, възниква някакъв инцидент и този, който е изпратил съобщението, няма да знае дали съобщението му е достигнало и какво се е случило от страна на получателя, няма да знае дали съобщението е обработено правилно , т.е. няма да получи потвърждение.
Съответно трябва да обработим тази ситуация. И най-простото нещо е да изпратим отново това съобщение и да изчакаме, докато получим отговор. В този случай никъде не се взема предвид дали състоянието на приемника се е променило. Може би ще изпратим съобщение и ще добавим същите данни два пъти.
ZooKeeper предлага начини за справяне с подобни неуспехи, което също улеснява живота ни.
Както споменахме по-рано, това е подобно на писането на многонишкови програми, но основната разлика е, че в разпределените приложения, които изграждаме на различни машини, единственият начин за взаимодействие е мрежата. По същество това е споделена архитектура без нищо. Всеки процес или услуга, която работи на една машина, има собствена памет, собствен диск, собствен процесор, които не споделя с никого.
Ако пишем многонишкова програма на един компютър, тогава можем да използваме споделена памет за обмен на данни. Там имаме превключване на контекста, процесите могат да превключват. Това се отразява на производителността. От една страна, няма такова нещо в програмата на клъстера, но има проблеми с мрежата.
Съответно, основните проблеми, които възникват при писането на разпределени системи, са конфигурацията. Пишем някакво приложение. Ако е просто, тогава кодираме твърдо всякакви числа в кода, но това е неудобно, защото ако решим, че вместо таймаут от половин секунда, искаме таймаут от една секунда, тогава трябва да прекомпилираме приложението , разточете всичко отново. Едно е, когато е на една машина, когато можете просто да го рестартирате, а когато имаме много машини, трябва постоянно да копираме всичко. Трябва да се опитаме да направим приложението конфигурируемо.
Тук говорим за статична конфигурация за системни процеси. Това не е съвсем, може би от гледна точка на операционната система може да е статична конфигурация за нашите процеси, т.е. това е конфигурация, която не може просто да бъде взета и актуализирана.
Освен това има динамична конфигурация. Това са параметрите, които искаме да променим в движение, така че да бъдат взети там.
Какъв е проблемът тук? Актуализирахме конфигурацията, внедрихме я и какво от това? Проблемът може да е, че от една страна пуснахме конфигурацията, но забравихме за новото нещо, конфигурацията остана там. Второ, докато се пускахме, някъде конфигурацията беше актуализирана, но някъде не. И някои процеси на нашето приложение, които работят на същата машина, се рестартираха с нова конфигурация, а някъде със старата. Това може да доведе до това, че нашето разпределено приложение не е в последователно състояние по отношение на конфигурацията. Този проблем е често срещан. За динамична конфигурация е по-подходящо, защото се предполага, че може да се променя в движение.
Друг проблем е членството в групата. Винаги имаме някакъв набор от работници, винаги искаме да знаем кой от тях е жив, кой е мъртъв. Ако има Master, тогава той трябва да разбере кои работници могат да бъдат пренасочени към клиенти, така че да започнат изчисления или да работят с данни и кои не. Постоянно възниква проблемът, че трябва да знаете кой работи в нашия клъстер.
Друг типичен проблем е изборът на лидер, когато искаме да знаем кой управлява. Един пример е репликацията, когато имаме някакъв процес, който приема операции за запис и след това ги репликира към други процеси. Той ще бъде лидер, всички останали ще му се подчиняват, ще го следват. Трябва да се избере такъв процес, който да е недвусмислен за всички, за да не се получи двама лидери.
Има и взаимно изключващ се достъп. Тук проблемът е по-сложен. Има такова нещо като mutex, когато пишете многонишкови програми и искате достъпът до някакъв ресурс, например до клетка от паметта, да бъде ограничен и осъществен само от една нишка. Тук ресурсът може да е нещо по-абстрактно. И различни приложения от различни възли на нашата мрежа трябва да получават само изключителен достъп до този ресурс, а не така, че всеки да може да го промени или да напише нещо там. Това са така наречените брави.
ZooKeeper ви позволява да разрешите всички тези проблеми в една или друга степен. И ще покажа с примери как ви позволява да направите това.
Няма блокиращи примитиви. Когато започнем да използваме нещо, този примитив няма да чака да се случи каквото и да е събитие. Най-вероятно това нещо ще работи асинхронно, като по този начин ще позволи на процесите да не висят в състояние, че чакат нещо. Това е много полезно нещо.
Всички клиентски заявки се обработват по реда на общата опашка.
И клиентите имат възможност да получават известия за промени в дадено състояние, за промени в данните, преди клиентът да види самите променени данни.
ZooKeeper може да работи в два режима. Първият е самостоятелен, на един възел. Това е удобно за тестване. Освен това може да работи в режим на клъстер, на произволен брой сървъри. Ако имаме клъстер от 100 машини, тогава не е необходимо той да работи на 100 машини. Достатъчно е да изберете няколко машини, на които можете да стартирате ZooKeeper. И изповядва принципа на висока наличност. ZooKeeper съхранява пълно копие на данните за всеки работещ екземпляр. По-късно ще ви кажа как го прави. Не разделя данни, не ги разделя. От една страна, това е минус, че не можем да съхраняваме много, от друга страна, това не е необходимо. Не е предназначен за това, не е база данни.
Данните могат да бъдат кеширани от страна на клиента. Това е стандартен принцип, така че да не дърпаме услугата, да не я зареждаме с едни и същи заявки. Интелигентният клиент обикновено знае за това и го кешира у дома.
Например нещо се е променило. Има някакво приложение. Избрахме нов лидер, който отговаря например за обработката на операциите за запис. И ние искаме да възпроизведем данните. Едно решение е да сложите цикъл. И ние непрекъснато анкетираме нашата услуга - променило ли се е нещо? Вторият вариант е по-оптимален. Това е механизъм за наблюдение, който ви позволява да уведомите клиентите, че нещо се е променило. Това е по-евтин начин от гледна точка на ресурси и по-удобен за клиентите.
Клиент е потребителят, който използва ZooKeeper.
Сървърът е самият процес на ZooKeeper.
Znode е основната функция на ZooKeeper. Всички znodes се съхраняват в паметта от ZooKeeper и са организирани в йерархична схема под формата на дърво.
Има два вида операции. Първият е актуализиране/запис, когато някаква операция променя състоянието на нашето дърво. Дървото е общо.
И е възможно клиентът да не изпълни една заявка и да бъде отрязан, но може да установи сесия, с която взаимодейства със ZooKeeper.
Моделът на данните на ZooKeeper наподобява файлова система. Има стандартен root и след това минахме сякаш през директориите, които идват от root. И след това каталогът на първо ниво, второ ниво. Всичко е znodes.
Всеки znode може да съхранява някои данни, обикновено не много големи, например 10 килобайта. И всеки znode може да има известен брой деца.
Znodes се предлагат в няколко вида. Те могат да бъдат създадени. И когато създаваме znode, ние определяме типа, към който трябва да принадлежи.
Има два вида. Първото е ефимерното знаме. Znode живее в рамките на една сесия. Например, клиентът е установил сесия. И докато е жива тази сесия, тя ще съществува. Това е необходимо, за да не се произведе нещо излишно. Подходящ е и за такива моменти, когато е важно за нас да съхраняваме примитиви на данни в сесията.
Вторият тип е последователният флаг. Той увеличава брояч по пътя към znode. Например, имахме директория с приложение 1_5. И когато създадохме първия възел, той получи p_1, вторият - p_2. И когато извикваме този метод всеки път, ние предаваме пълния път, посочвайки само част от празния, и това число автоматично се увеличава, тъй като ние посочваме типа на възела - последователен.
Редовен znode. Тя ще живее вечно и ще носи името, което ние ще й кажем.
Друго полезно нещо е флагът на часовника. Ако го зададем, тогава клиентът може да се абонира за някои събития за конкретен възел. По-късно ще покажа с пример как се прави това. Самият ZooKeeper уведомява клиента, че данните на възела са се променили. В същото време известията не гарантират, че са пристигнали нови данни. Те просто казват, че нещо се е променило, така че по-късно ще трябва да сравните данните така или иначе с отделни обаждания.
И както казах, редът на данните се определя от килобайти. Няма нужда да съхранявате големи текстови данни там, защото това не е база данни, това е сървър за координиране на действията.
Ще ви разкажа малко за сесиите. Ако имаме няколко сървъра, тогава можем прозрачно да се преместваме от сървър на сървър, използвайки идентификатора на сесията. Доста е удобно.
Всяка сесия има някакъв вид таймаут. Една сесия се определя от това дали клиентът изпраща нещо до сървъра по време на тази сесия. Ако не е предал нищо по време на таймаута, сесията пада или клиентът може да я затвори сам.
Той няма толкова много функции, но можете да правите всякакви неща с този API. Обаждането, което видяхме да създава, създава znode и приема три параметъра. Това е пътят към znode и трябва да се квалифицира от root. Освен това това са някои данни, които искаме да прехвърлим там. И вида на знамето. И след създаването, той връща пътя към znode.
Вторият може да бъде премахнат. Тук трикът е, че вторият параметър, в допълнение към пътя към znode, можете да посочите версията. Съответно този znode ще бъде изтрит, ако неговата версия, която предадохме, е еквивалентна на тази, която е в действителност.
Ако искаме да не проверяваме тази версия, тогава просто подаваме аргумента "-1".
Трето, той проверява за съществуването на znode. Връща true, ако възелът съществува, false в противен случай.
След това се появява наблюдение на флагове, което ви позволява да зададете наблюдение за този възел.
Можете да зададете този флаг дори на несъществуващ възел и да получите известие, когато се появи. Това също е полезно.
Има още няколко обаждания getData. Ясно е, че можем да получим данни чрез znode. Можете също да използвате часовник с флаг. В този случай той няма да бъде инсталиран, ако няма възел. Следователно трябва да разберете, че съществува, и след това да получите данните.
Има и setdata. Тук предаваме версията. И ако го предадем, тогава данните за znode на определена версия ще бъдат актуализирани.
Можете също да посочите "-1", за да изключите тази проверка.
Друг полезен метод е getChildren. Можем също да получим списък на всички znodes, които принадлежат към него. Можем да наблюдаваме това, като зададем часовник с флаг.
И метод синхронизирате позволява всички промени да бъдат изпратени наведнъж, като по този начин гарантира, че те са запазени и всички данни са напълно променени.
Ако правите аналогии с конвенционалното програмиране, тогава когато използвате методи като write, които записват нещо на диска и след като ви върнат отговор, няма гаранция, че имате данни, записани на диска. И дори когато операционната система е сигурна, че всичко е записано, в самия диск има механизми, при които процесът преминава през буферни нива и едва след това данните се поставят на диска.
Използват се предимно асинхронни повиквания. Това позволява на клиента да работи по различни заявки паралелно. Можете да използвате синхронния подход, но той е по-малко продуктивен.
Двете операции, за които говорихме, са актуализиране/запис, които променят данните. Това са create, setData, sync, delete. И read е съществува, getData, getChildren.
Сега няколко примера за това как можете да накарате примитивите да работят в разпределена система. Например, свързани с конфигурацията на нещо. Появи се нов работник. Добавихме кола, стартирахме процеса. И има три въпроса. Как иска конфигурация от ZooKeeper? И ако искаме да променим конфигурацията, тогава как да я променим? И след като го сменихме, как го получават работниците, които имахме?
В ZooKeeper това може да стане относително лесно. Например, има нашето дърво znode. Тук има възел за нашето приложение, в него създаваме допълнителен възел, който съдържа данни от конфигурацията. Това могат или не могат да бъдат отделни параметри. Тъй като размерът е малък, размерът на конфигурацията обикновено също е малък, така че е напълно възможно да се съхранява тук.
Вие използвате метода getData за да получите конфигурацията за работника от възела. Задайте true. Ако по някаква причина този възел не съществува, ние ще бъдем информирани за това, когато се появи или когато се промени. Ако искаме да знаем, че нещо се е променило, тогава го настройваме на true. И ако данните в този възел се променят, ние ще знаем за това.
setdata. Задаваме данните, задаваме "-1", т.е. не проверяваме версията, вярваме, че винаги имаме една и съща конфигурация, не е необходимо да съхраняваме много конфигурации. Ако трябва да съхранявате много, тогава ще трябва да добавите още едно ниво. Тук считаме, че е единствената, така че актуализираме само най-новата, така че не проверяваме версията. В този момент всички клиенти, които са се абонирали преди това, получават известие, че нещо се е променило в този възел. И след като са ги получили, те също трябва да поискат данните отново. Уведомяването се състои в това, че те не получават самите данни, а само известие за промени. След това те трябва да поискат нови данни.
Второто използване на примитива е групово членство. Имаме разпространено приложение, имаме куп работници и искаме да разберем, че всички те са на мястото си. Следователно те трябва да се регистрират, че работят в нашето приложение. И също така искаме да научим за всички активни работници, които имаме в момента, или от главния процес, или от някъде другаде.
Как да го направим? За приложението създаваме възел за работници и добавяме подниво там, използвайки метода create. Имам грешка в слайда. Тук имате нужда следващ посочете, тогава всички работници ще бъдат създадени един по един. И приложението, изисквайки всички данни за децата на този възел, получава всички активни работници, които са.
Ето такова ужасно изпълнение на това как това може да се направи в Java код. Нека започнем от края, с основния метод. Това е нашият клас, ние създаваме неговия метод. Като първи аргумент използваме host, където се свързваме, т.е. задаваме го като аргумент. И като втори аргумент - името на групата.
Как върви връзката? Това е прост пример за API, който се използва. Тук всичко е сравнително просто. Има стандартен клас ZooKeeper. Даваме го домакини. И задайте време за изчакване, например 5 секунди. И имаме член като ConnectedSignal. По същество създаваме група по изминат път. Ние не пишем данни там, въпреки че може да се напише нещо. И възелът тук е от тип постоянен. Всъщност това е обикновен редовен възел, който ще съществува през цялото време. Това е мястото, където се създава сесията. Това е внедряването на самия клиент. Нашият клиент ще докладва периодично, че сесията е жива. И когато завършим сесията, извикваме close и това е, сесията пада. Това е в случай, че нещо отпадне при нас, така че ZooKeeper да разбере за това и да прекъсне сесията.
Как да заключите някакъв ресурс? Тук всичко е малко по-сложно. Имаме набор от работници, има някакъв вид ресурс, който искаме да заключим. За да направим това, създаваме отделен възел, например наречен lock1. Ако сме успели да го създадем, значи имаме заключване тук. И ако не можем да го създадем, тогава работникът се опитва да получи GetData от тук и тъй като възелът вече е създаден, тогава поставяме наблюдател тук и в момента, когато състоянието на този възел се промени, ще знаем за то. И можем да се опитаме да имаме време да го пресъздадем. Ако сме взели този възел, взели сме това заключване, след като вече нямаме нужда от заключване, ще го откажем, защото възелът съществува само в рамките на сесията. Съответно ще изчезне. И друг клиент в рамките на друга сесия ще може да заключи този възел или по-скоро ще получи известие, че нещо се е променило и може да опита да го направи навреме.
Друг пример за това как можете да изберете главния лидер. Това е малко по-сложно, но и относително просто. Какво става тук? Има основен възел, който обединява всички работници. Опитваме се да получим данни за лидера. Ако това се случи успешно, т.е. получихме някакви данни, тогава нашият работник започва да следва този лидер. Той вярва, че лидерът вече е там.
Ако лидерът умре по някаква причина, например падна, тогава се опитваме да създадем нов лидер. И ако успеем, тогава нашият работник става лидер. И ако някой в този момент е успял да създаде нов лидер, тогава ние се опитваме да разберем кой е и след това да го следваме.
Тук възниква така нареченият ефект на стадото, т.е. ефектът на стадото, защото когато водачът умре, този, който дойде пръв навреме, ще стане лидер.
Когато улавяте ресурс, можете да опитате да използвате малко по-различен подход, който е както следва. Например, искаме да получим ключалка, но без ефект на hert. Това ще се състои в това, че нашето приложение изисква списъци с всички идентификатори на възли за вече съществуващ възел със заключване. И ако преди това възелът, за който сме създали ключалката, е минимумът от набора, който сме получили, тогава това означава, че сме уловили ключалката. Проверяваме дали имаме ключалка. Като проверка ще има условие ID-то, което сме получили при създаване на нова ключалка, да е минималното. И ако сме получили, тогава работим по-нататък.
Ако има някакъв идентификатор, който е по-малък от нашия ключ, тогава поставяме наблюдател на това събитие и чакаме известие, докато нещо се промени. Тоест получихме тази ключалка. И докато не падне, ние няма да станем минималния id и няма да получим минималния лок и по този начин ще можем да заключим. И ако това условие не е изпълнено, тогава веднага отиваме тук и се опитваме да получим тази ключалка отново, защото нещо може да се е променило през това време.
От какво е направен ZooKeeper? Има 4 основни неща. Това е обработката на процеси – Заявка. А също и ZooKeeper Atomic Broadcast. Има Commit Log, където се записват всички операции. И самата In-memory Replicated DB, т.е. самата база данни, където се съхранява цялото това дърво.
Струва си да се отбележи, че всички операции по запис преминават през процесора за заявки. А операциите за четене отиват директно в базата данни в паметта.
Самата база данни е напълно репликирана. Всички копия на ZooKeeper съхраняват пълно копие на данните.
За да се възстанови базата данни след срив, има Commit log. Стандартна практика е да се записват данни там, преди да попаднат в паметта, така че в случай на срив този дневник да може да бъде възпроизведен и състоянието на системата да бъде възстановено. Прилагат се и периодични моментни снимки на база данни.
ZooKeeper Atomic Broadcast е такова нещо, което се използва за поддържане на репликирани данни.
ZAB вътрешно избира лидер от гледна точка на възела ZooKeeper. Други възли стават нейни последователи, чакайки някакво действие от нея. Ако записите дойдат при тях, всички те ги пренасочват към лидера. Той предварително извършва операцията за запис и след това изпраща съобщение за това какво се е променило на своите последователи. Това всъщност трябва да се извърши атомарно, т.е. операцията по записване и излъчване на цялото това нещо трябва да се извърши атомарно, като по този начин се гарантира съгласуваност на данните.
Той обработва само заявки за писане. Основната му задача е да трансформира операцията в транзакционна актуализация. Това е специално изготвена заявка.
И тук си струва да се отбележи, че идемпотентността на актуализациите за една и съща операция е гарантирана. Какво е? Това нещо, ако го стартирате два пъти, то ще има същото състояние, т.е. самата заявка няма да се промени от това. И трябва да направите това, така че в случай на срив да можете да рестартирате операцията, като по този начин прехвърлите промените, които са паднали в момента. В този случай състоянието на системата ще стане същото, т.е. не трябва да е такова, че поредица от едни и същи, например процеси на актуализиране, са довели до различни крайни състояния на системата.
Източник: www.habr.com