Zookeeper je podprojekt Hadoopu a hoci je odvodený od Hadoopu, zistil som, že Zookeeper čoraz viac používa distribuované frameworky mimo Hadoopu. Dnes chcem hovoriť o Zookeeperi, tento článok sa nebude venovať tomu, ako používať Zookeeper, ale aké sú praktické aplikácie Zookeeperu, aké typy aplikácií môžu zookeeper využiť a nakoniec o tom, akú úlohu môže zookeeper zohrať v distribuovanej architektúre webových stránok.
Zookeeper je vysoko spoľahlivý koordinačný systém pre veľké distribuované systémy. Z tejto definície vieme, že Zookeeper je koordinovaný systém, ktorý pôsobí na distribuovaných systémoch. Prečo distribuované systémy potrebujú koordinačný systém? Dôvody sú nasledovné:
Vývoj distribuovaného systému je veľmi náročná vec a táto náročnosť sa najmä odráža v "čiastočnom zlyhaní" distribuovaného systému. "Čiastočné zlyhanie" označuje prenos informácií medzi dvoma uzlami siete; ak sieť zlyhá, odosielateľ nemôže vedieť, či prijímateľ správu prijal, a príčina tohto zlyhania je zložitá, príjemca mohol alebo nemusel správu prijať pred sieťovou chybou, alebo je proces prijímača mŕtvy. Jediný spôsob, ako môže odosielateľ získať skutočný obraz, je znovu sa pripojiť k prijímateľovi a opýtať sa, prečo k chybe došlo, čo je problém "čiastočného zlyhania" vo vývoji distribuovaných systémov.
Zookeeper je rámec na riešenie "čiastočného zlyhania" distribuovaných systémov. Zookeeper neumožňuje distribuovaným systémom vyhnúť sa problémom "čiastočného zlyhania", ale umožňuje distribuovaným systémom správne riešiť takéto problémy pri čiastočných poruchách, aby distribuované systémy mohli fungovať normálne.
Poďme sa porozprávať o praktickom využití Zookeepera:
Scenár 1: Existuje skupina serverov, ktoré poskytujú klientovi určitú službu (napríklad serverová časť distribuovanej webovej stránky, ktorú som vytvoril skôr, je klaster zložený zo štyroch serverov na poskytovanie služieb front-end klastru), a dúfame, že klient nájde server v klastru vždy, keď klient o to požiada, aby server mohol klientovi poskytovať služby požadované klientom. Pre tento scenár musíme mať v programe zoznam serverov, z ktorého zoznam serverov čítame vždy, keď si ho klient vyžiada. Potom tento podzoznam samozrejme nemôže byť uložený na jednom uzlovom serveri, inak sa uzol zasekne a celý klaster zlyhá, a dúfame, že tento zoznam bude v tom čase dobre dostupný. Ak je server v zozname úložiska pokazený, iné servery môžu okamžite nahradiť nefunkčný server a poškodený server môže byť zo zoznamu odstránený, takže zlyhaný server sa môže stiahnuť z prevádzky celého klastra a všetky tieto operácie nebudú prevádzkované zlyhaným serverom, ale bežným serverom v klastri. Ide o aktívnu distribuovanú dátovú štruktúru, ktorá môže aktívne meniť stav dátových položiek, keď sa menia vonkajšie podmienky. Rámec Zookeeper poskytuje túto službu. Názov tejto služby je: Unified Naming Service, ktorý je veľmi podobný službe JNDI v javaEE.
Scenár 2: Distribuovaná služba zámku. Keď distribuovaný systém manipuluje s dátami, ako je čítanie dát, analýza dát a nakoniec ich úprava. V distribuovanom systéme môžu byť tieto operácie rozptýlené do rôznych uzlov v klastri, potom nastáva problém konzistencie v procese spracovania dát, ak je nekonzistentný, dostaneme nesprávny výsledok operácie, v jednom procese je problém konzistencie ľahko vyriešiteľný, ale je ťažšie dosiahnuť distribuovaný systém, pretože operácie rôznych serverov v distribuovanom systéme prebiehajú v nezávislých procesoch a medzivýsledky a procesy operácie musia byť prenášané cez sieť. Potom je oveľa ťažšie dosiahnuť konzistentnosť operácií s dátami. Zookeeper poskytuje službu zámku, ktorá tento problém rieši a umožňuje zabezpečiť konzistentnosť dátových operácií pri distribuovaných dátových operáciách.
Scenár 3: Správa konfigurácie. V distribuovanom systéme nasadíme servisnú aplikáciu na n serverov samostatne a konfiguračné súbory týchto serverov sú rovnaké (napríklad v rámci distribuovaného webu, ktorý som navrhol, sú na strane servera 4 servery, programy na 4 serveroch sú rovnaké a konfiguračné súbory sú rovnaké), ak sa konfiguračné možnosti konfiguračných súborov menia, musíme tieto konfiguračné súbory meniť jeden po druhom, ak je potrebné zmeniť, servery sú relatívne malé, tieto operácie nie sú príliš zložité, Ak máme veľké množstvo distribuovaných serverov, napríklad Hadoop klaster veľkej internetovej spoločnosti s tisíckami serverov, potom zmena konfigurácie môže byť problémová a nebezpečná. V tomto čase sa nám zíde Zookeeper, môžeme použiť Zookeeper ako vysoko dostupnú konfiguračnú pamäť, odovzdať to Zookeeperu na správu, skopírovať konfiguračný súbor klastra do uzla súborového systému Zookeeper a potom použiť Zookeeper na sledovanie stavu konfiguračného súboru vo všetkých distribuovaných systémoch, keď sa zistí, že sa konfiguračný súbor zmenil, Každý server dostane notifikáciu od Zookeepera na synchronizáciu konfiguračných súborov v Zookeeper a služba Zookeeper tiež zabezpečí, že synchronizačná operácia je atómová, aby bol konfiguračný súbor každého servera správne aktualizovaný.
Scenár 4: Poskytnúť funkcie opravy porúch pre distribuované systémy. Správa klastrov je náročná a pridanie služby zookeeper do distribuovaného systému nám uľahčuje správu klastra. Najväčšou problémovou vecou v správe klastra je správa chýb uzlov, zookeeper môže umožniť klasstru vybrať zdravý uzol ako mastera, hlavný uzol pozná aktuálny stav každého servera v klastri, a keď uzol zlyhá, master upozorní ostatné servery v klastri, aby mohol redistribuovať výpočtové úlohy rôznych uzlov. Zookeeper dokáže nielen nájsť chyby, ale aj preveriť chybný server, zistiť, aký typ poruchy server je, ak sa porucha dá opraviť, Zookeeper môže automaticky opraviť alebo povedať správcovi systému príčinu chyby, aby administrátor mohol rýchlo lokalizovať problém a opraviť chybu uzla. Možno máte stále otázku, čo mám robiť, ak je hlavný kábel chybný? Zookeeper to tiež berie do úvahy – Zookeeper má interný "algoritmus na výber lídrov", páni môžu byť dynamicky vyberaní a keď majster zlyhá, zookeeper môže okamžite vybrať nového pána na správu klastra.
Poďme sa porozprávať o vlastnostiach Zookeepera:
ZooKeeper je zjednodušený súborový systém. Je to trochu podobné Hadoopu, ale súborový systém ZooKeeper spravuje malé súbory, zatiaľ čo Hadoop spravuje veľmi veľké súbory.
Zookeeper poskytuje množstvo "artefaktov", ktoré umožňujú mnohé operácie na koordináciu dátových štruktúr a protokolov. Napríklad: distribuované fronty, distribuované zámky a algoritmus "volby lídra" skupiny uzlov na rovnakej úrovni.
ZooKeeper je vysoko dostupný, jeho vlastná stabilita je veľmi dobrá, distribuované klastre sa môžu spoliehať na správu Zookeeper klastrov a ZooKeeper sa používa na zabránenie problému zlyhania jedného bodu distribuovaných systémov.
Zookeeper používa voľne prepojený režim interakcie. Najviac je to zrejmé v tom, že zookeeper poskytuje distribuované zámky, ktoré môžu slúžiť ako mechanizmus na vymenovanie, aby zúčastnené procesy mohli objavovať a interagovať medzi sebou bez toho, aby poznali ostatné procesy (alebo sieť), a zúčastnené strany nemusia existovať súčasne, pokiaľ zanechajú správu v Zookeeper a po skončení procesu môže iný proces túto správu prečítať, čím sa vzťah medzi uzlami odpojí.
ZooKeeper poskytuje zdieľané úložisko pre klaster, z ktorého môže klaster centrálne čítať a zapisovať zdieľané informácie, čím sa eliminuje programovanie zdieľaných operácií pre každý uzol a znižuje sa náročnosť vývoja distribuovaných systémov.
Zookeeper je hlavne zodpovedný za ukladanie a správu dát, na ktorých všetkým záleží, a následné prijatie registrácie pozorovateľov; keď sa stav týchto dát zmení, Zookeeper je zodpovedný za upozornenie tých pozorovateľov, ktorí sa zaregistrovali na Zookeeper, aby reagovali primerane, aby sa dosiahol režim správy master/slave podobný klastru.
Je zrejmé, že Zookeeper je veľmi vhodný pre vývoj distribuovaných systémov, čo môže distribuované systémy urobiť robustnejšími a efektívnejšími.
Nedávno som sa zúčastnil záujmovej skupiny oddelenia o Hadoop, kde som nainštaloval Hadoop, MapReduce, Hive a Hbase v testovacom prostredí a Zookeeper som inštaloval vopred pri inštalácii hbase. Zookeeper dokáže poskytovať služby, takže viac ako polovica z 3 je 2 a viac ako polovica zo 4 je tiež 2, takže inštalácia troch serverov môže dosiahnuť efekt 4 serverov. Pri učení sa Hadoop mám pocit, že Zookeeper je najťažší podprojekt na pochopenie, dôvodom nie je jeho technická zodpovednosť, ale to, že jeho aplikačné smerovanie je pre mňa veľmi mätúce, takže môj prvý článok o hadoop technológii začína so Zookeeperom a nehovorí o konkrétnej technickej implementácii, ale z aplikačných scenárov Zookeeperu rozumiem oblasti aplikácie Zookeeperu, myslím, že učenie sa Zookeeperu bude efektívnejšie s polovičným úsilím.
Dôvod, prečo chcem dnes hovoriť o zookeeperovi, je doplniť rámec distribuovanej webovej stránky v mojom predchádzajúcom článku. Aj keď som architektúru webu navrhol ako distribuovanú štruktúru, vytvoril som aj jednoduchý mechanizmus na spracovanie chýb, napríklad heartbeat mechanizmus, no stále neexistuje spôsob, ako vyriešiť jediný bod zlyhania klastra – ak je server pokazený, klient sa pokúsi pripojiť k tomuto serveru, čo vedie k blokovaniu niektorých požiadaviek a tiež k plytvaniu zdrojmi servera. Momentálne však nechcem meniť svoj framework, pretože vždy mám pocit, že pridanie služby zookeeper k existujúcim službám ovplyvní efektivitu webu. Našťastie, naše oddelenie tiež narazilo na takýto problém, vyvinie silný rámec pre vzdialené hovory, oddelí správu klastrov a riadenie komunikácie a poskytne efektívne a dostupné služby centrálne.
Preložený z ttp://www.cnblogs.com/sharpxiajun/archive/2013/06/02/3113923.html |
Zverejnené 18. 7. 2017 14:19:01
|
|
|
