Zookeeper je podprojekt Hadoopu a i když je odvozen od Hadoopu, zjistil jsem, že Zookeeper stále častěji používá distribuované frameworky mimo Hadoop. Dnes bych chtěl mluvit o Zookeeperu, tento článek se nebude zabývat tím, jak Zookeeper používat, ale jaké jsou praktické aplikace Zookeeperu, jaké typy aplikací mohou mít výhody Zookeeperu a nakonec o tom, jakou roli může zookeeper hrát v distribuované architektuře webu.
Zookeeper je vysoce spolehlivý koordinační systém pro velké distribuované systémy. Z této definice víme, že Zookeeper je koordinovaný systém, který působí na distribuovaných systémech. Proč distribuované systémy potřebují koordinační systém? Důvody jsou následující:
Vyvinout distribuovaný systém je velmi obtížná věc a tato obtížnost se odráží především v "částečném selhání" distribuovaného systému. "Částečné selhání" označuje přenos informací mezi dvěma uzly sítě; pokud selže síť, odesílatel nemůže vědět, zda příjemce zprávu obdržel, a příčina tohoto selhání je složitá, příjemce mohl zprávu obdržet před chybou v síti, nebo je proces příjemce mrtvý. Jediný způsob, jak může odesílatel získat skutečný obraz, je znovu se připojit k přijímači a zeptat se přijímače, proč k chybě došlo, což je problém "částečného selhání" ve vývoji distribuovaných systémů.
Zookeeper je rámec pro řešení "částečného selhání" distribuovaných systémů. Zookeeper neumožňuje distribuovaným systémům vyhnout se problémům "částečného selhání", ale umožňuje distribuovaným systémům správně řešit tyto problémy při částečných selháních, aby distribuované systémy mohly fungovat normálně.
Pojďme si povídat o praktickém využití Zookeeper:
Scénář 1: Existuje skupina serverů, které poskytují klientovi určitou službu (například serverová strana distribuovaného webu, který jsem vytvořil dříve, je cluster složený ze čtyř serverů, které poskytují služby front-end clusteru), a doufáme, že klient najde server v serverovém clusteru pokaždé, když o něj klient požádá, aby server mohl klientovi poskytovat požadované služby. V tomto scénáři musíme mít v programu seznam serverů, ze kterého si seznam serverů čteme pokaždé, když si ho klient vyžádá. Pak tento podseznam samozřejmě nelze uložit na jeden node server, jinak se uzel zasekne a celý cluster selže, a doufáme, že tento seznam bude v té době dobře dostupný. Pokud je server v seznamu úložišť rozbitý, mohou ho okamžitě nahradit jiné servery a rozbitý server může být ze seznamu odstraněn, takže selhávající server může odejít z provozu celého clusteru, a všechny tyto operace nebudou provozovány selhávajícím serverem, ale běžným serverem v clusteru. Jedná se o aktivní distribuovanou datovou strukturu, která může aktivně měnit stav datových položek při změně vnějších podmínek. Rámec Zookeeper tuto službu poskytuje. Název této služby je: Unified Naming Service, což je velmi podobné službě JNDI v javaEE.
Scénář 2: Distribuovaná služba zámku. Když distribuovaný systém manipuluje s daty, například čtením dat, analýzou dat a nakonec jejich úpravou. V distribuovaném systému mohou být tyto operace rozptýleny na různé uzly v clusteru, pak vzniká problém konzistence v procesu zpracování dat; pokud je nekonzistentní, dostaneme špatný výsledek operace, v jednom procesu je problém konzistence snadno řešitelný, ale obtížnější je dosáhnout distribuovaného systému, protože operace různých serverů v distribuovaném systému probíhají v nezávislých procesech a mezilehlé výsledky a procesy operace musí být přenášeny sítí. Pak je mnohem obtížnější dosáhnout konzistence datových operací. Zookeeper poskytuje službu zámku, která tento problém řeší a umožňuje zajistit konzistenci datových operací při distribuovaných datových operacích.
Scénář 3: Správa konfigurace. V distribuovaném systému nasadíme servisní aplikaci na n serverů samostatně a konfigurační soubory těchto serverů jsou stejné (například v distribuovaném webovém rámci, který jsem navrhl, jsou na straně serveru 4 servery, programy na těchto 4 serverech jsou stejné a konfigurační soubory jsou stejné), pokud se konfigurační možnosti konfiguračních souborů změní, musíme tyto konfigurační soubory měnit jeden po druhém, pokud je potřeba změnit, jsou servery relativně malé, tyto operace nejsou příliš komplikované. Pokud máme velké množství distribuovaných serverů, například Hadoop cluster velké internetové společnosti s tisíci servery, pak může být změna konfiguračních možností problémová a nebezpečná. V této době se nám Zookeeper hodí, můžeme použít Zookeeper jako vysoce dostupnou konfigurační paměť, předat takovou věc Zookeeperu ke správě, zkopírovat konfigurační soubor clusteru do uzlu souborového systému Zookeeperu a pak pomocí Zookeeperu sledovat stav konfiguračního souboru ve všech distribuovaných systémech, jakmile zjistíme, že se konfigurační soubor změnil, Každý server obdrží oznámení od Zookeeperu o synchronizaci konfiguračních souborů v Zookeeperu a služba Zookeeper také zajistí, že synchronizační operace je atomická, aby byl konfigurační soubor každého serveru správně aktualizován.
Scénář 4: Poskytnout funkce opravy poruch pro distribuované systémy. Správa clusteru je obtížná a přidání služby zookeeper do distribuovaného systému nám usnadňuje správu clusteru. Nejproblematičtější věcí ve správě clusteru je správa chyb uzlů, zookeeper umožňuje clusteru vybrat zdravý uzel jako mastera, hlavní uzel zná aktuální stav každého serveru v clusteru, a jakmile uzel selže, master upozorní ostatní servery v clusteru, aby mohl přerozdělit výpočetní úkoly různých uzlů. Zookeeper může nejen najít chyby, ale také zkontrolovat vadný server, zjistit, o jaký typ závady jde server, pokud lze chybu opravit, Zookeeper může automaticky opravit nebo sdělit správci systému příčinu chyby, aby správce mohl rychle najít problém a opravit chybu uzlu. Možná máte stále otázku, co mám dělat, pokud je hlavní disk vadný? Zookeeper to také bere v potaz, Zookeeper má interní "algoritmus pro volbu vůdců", pány lze dynamicky vybírat a když mistr selže, může okamžitě vybrat nového pána pro správu clusteru.
Pojďme si povídat o vlastnostech Zookeeper:
ZooKeeper je zjednodušený souborový systém. Je to trochu podobné Hadoopu, ale souborový systém ZooKeeper spravuje malé soubory, zatímco Hadoop spravuje velmi velké soubory.
Zookeeper poskytuje bohatství "artefaktů", které umožňují mnoha operacím koordinovat datové struktury a protokoly. Například: distribuované fronty, distribuované zámky a algoritmus "volby lídra" skupiny uzlů na stejné úrovni.
ZooKeeper je vysoce dostupný, jeho vlastní stabilita je velmi dobrá, distribuované clustery se mohou spoléhat na správu Zookeeper clusterů a ZooKeeper se používá k předejít problému selhání jednoho bodu distribuovaných systémů.
Zookeeper používá volně propojený interakční režim. To je nejvíce patrné v tom, že zookeeper poskytuje distribuované zámky, které lze použít jako mechanismus jmenování, aby zúčastněné procesy mohly objevovat a interagovat navzájem, aniž by znaly ostatní procesy (nebo síť), a zúčastněné strany nemusí existovat současně, pokud zanechají zprávu v Zookeeperu, a po skončení procesu může tuto zprávu přečíst jiný proces, čímž se vztah mezi uzly oddělí.
ZooKeeper poskytuje sdílené úložiště pro cluster, ze kterého může cluster centrálně číst a zapisovat sdílené informace, čímž se eliminuje programování sdílených operací pro každý uzel a snižuje se obtížnost vývoje distribuovaných systémů.
Zookeeper je především zodpovědný za ukládání a správu dat, na kterých všem záleží, a následné přijímání registrace pozorovatelů; jakmile se stav těchto dat změní, bude Zookeeper odpovědný za upozornění těch pozorovatelů, kteří se na Zookeeperu registrovali, aby odpovídali, aby dosáhli režimu master/slave podobného clusteru.
Je vidět, že Zookeeper je velmi přínosný pro rozvoj distribuovaných systémů, což může učinit distribuované systémy robustnějšími a efektivnějšími.
Nedávno jsem se účastnil zájmové skupiny oddělení o hadoop, kde jsem nainstaloval Hadoop, MapReduce, Hive a Hbase v testovacím prostředí a Zookeeper jsem instaloval předem při instalaci Hbase. Zookeeper může poskytovat služby, takže více než polovina ze 3 je 2 a více než polovina ze 4 je také dva, takže instalace tří serverů může dosáhnout efektu 4 serverů. Při učení Hadoopu mám pocit, že Zookeeper je nejtěžší podprojekt na pochopení, důvodem není jeho technická odpovědnost, ale že jeho směr aplikace je pro mě velmi matoucí, takže můj první článek o technologii Hadoop začíná u Zookeeperu a nemluví o konkrétní technické implementaci, ale z aplikačních scénářů Zookeeperu chápu oblast aplikace Zookeeperu, myslím, že učení Zookeeperu bude efektivnější s polovičním úsilím.
Důvod, proč dnes chci mluvit o Zookeeperu, je doplnit framework distribuovaných webových stránek v mém předchozím článku. Ačkoliv jsem architekturu webu navrhl jako distribuovanou strukturu, vytvořil jsem také jednoduchý mechanismus pro zpracování chyb, například heartbeat mechanismus, ale stále neexistuje způsob, jak vyřešit jediný bod selhání clusteru, pokud je server rozbitý, klient se pokusí připojit k tomuto serveru, což vede k blokování některých požadavků a také k plýtvání zdroji serveru. Momentálně ale nechci upravovat svůj framework, protože mám pocit, že přidání služby zookeeper k existujícím službám ovlivní efektivitu webu. Naštěstí náš odbor také narazil na podobný problém, vyvine silný rámec pro vzdálené hovory, oddělí správu clusteru a správu komunikace a poskytne efektivní a dostupné služby centrálně.
Převedeno z ttp://www.cnblogs.com/sharpxiajun/archive/2013/06/02/3113923.html |
Zveřejněno 18.07.2017 14:19:01
|
|
|
