Zookeeper är ett delprojekt till Hadoop, och även om det härstammar från Hadoop har jag märkt att Zookeeper i allt högre grad använder distribuerade ramverk utanför Hadoop. Idag vill jag prata om Zookeeper, den här artikeln kommer inte att handla om hur man använder Zookeeper, utan vilka praktiska tillämpningar Zookeeper har, vilka typer av applikationer som kan utnyttja fördelarna med Zookeeper, och slutligen om vilken roll Zookeeper kan spela i distribuerad webbplatsarkitektur.
Zookeeper är ett mycket pålitligt samordningssystem för stora distribuerade system. Utifrån denna definition vet vi att zookeeper är ett koordinerat system som agerar på distribuerade system. Varför behöver distribuerade system ett samordningssystem? Anledningarna är följande:
Att utveckla ett distribuerat system är mycket svårt, och svårigheten återspeglas främst i det "partiella felet" i det distribuerade systemet. "Partiellt fel" avser överföring av information mellan två noder i nätverket; om nätverket fallerar kan sändaren inte veta om mottagaren har mottagit meddelandet, och orsaken till detta fel är komplex, mottagaren kan ha mottagit meddelandet före nätverksfelet, eller mottagarens process är död. Det enda sättet för avsändaren att få den verkliga bilden är att återansluta till mottagaren och fråga mottagaren varför felet uppstod, vilket är "partiellt fel"-problemet vid utveckling av distribuerade system.
Zookeeper är ramverket för att lösa "partiella fel" i distribuerade system. Zookeeper tillåter inte distribuerade system att undvika "partiella fel"-problem, men tillåter distribuerade system att korrekt hantera sådana problem vid partiella fel, så att distribuerade system kan fungera normalt.
Låt oss prata om den praktiska användningen av djurskötare:
Scenario 1: Det finns en grupp servrar som tillhandahåller en viss tjänst till klienten (till exempel är serversidan av den distribuerade webbplatsen jag skapade tidigare ett kluster bestående av fyra servrar för att tillhandahålla tjänster till front-end-klustret), och vi hoppas att klienten kan hitta en server i serverklustret varje gång klienten begär det, så att servern kan tillhandahålla klienten de tjänster som klienten behöver. För detta scenario måste vi ha en lista över servrar i vårt program, från vilken vi läser listan varje gång klienten begär den. Då kan denna dellista uppenbarligen inte lagras på en enda nodserver, annars kommer noden att lägga på och hela klustret kommer att misslyckas, och vi hoppas att denna lista då kommer att vara mycket tillgänglig. Om en server i lagringslistan är trasig kan andra servrar omedelbart ersätta den trasiga servern, och den trasiga servern kan tas bort från listan, så att den misslyckade servern kan dra sig ur driften av hela klustret, och alla dessa operationer kommer inte att styras av den misslyckade servern, utan av den vanliga servern i klustret. Detta är en aktiv distribuerad datastruktur som aktivt kan ändra tillståndet för dataobjekt när yttre förhållanden förändras. Zookeeper-ramverket tillhandahåller denna tjänst. Namnet på denna tjänst är: Unified Naming Service, vilket är mycket likt JNDI-tjänsten i javaEE.
Scenario 2: Distribuerad låstjänst. När ett distribuerat system manipulerar data, såsom att läsa data, analysera data och slutligen ändra data. I det distribuerade systemet kan dessa operationer spridas till olika noder i klustret, då uppstår ett problem med konsistens i dataoperationen, om den är inkonsekvent får vi ett felaktigt operationsresultat, i ett enda processprogram är konsistensproblemet lätt att lösa, men det är svårare att nå det distribuerade systemet eftersom operationerna för olika servrar i det distribuerade systemet sker i oberoende processer, och de mellanliggande resultaten och processerna i operationen måste överföras genom nätverket. Då är det mycket svårare att uppnå enhetlig dataoperation. Zookeeper tillhandahåller en låstjänst som löser detta problem, vilket gör att vi kan säkerställa konsekvens i dataoperationerna när vi utför distribuerade dataoperationer.
Scenario 3: Konfigurationshantering. I ett distribuerat system distribuerar vi en tjänsteapplikation till n servrar separat, och konfigurationsfilerna för dessa servrar är desamma (till exempel, i det distribuerade webbplatsramverket jag designade finns det 4 servrar på serversidan, programmen på de 4 servrarna är desamma och konfigurationsfilerna är desamma), om konfigurationsalternativen för konfigurationsfilerna ändras måste vi ändra dessa konfigurationsfiler en efter en, om vi behöver ändra servrarna är de relativt små är dessa operationer inte alltför besvärliga, Om vi har ett stort antal distribuerade servrar, som ett stort internetföretags Hadoop-kluster med tusentals servrar, kan det vara besvärligt och farligt att ändra konfigurationsalternativ. Vid denna tidpunkt kan Zookeeper vara användbart, vi kan använda Zookeeper som ett mycket tillgängligt konfigurationsminne, lämna över något sådant till Zookeeper för hantering, vi kopierar konfigurationsfilen för klustret till en nod i Zookeepers filsystem, och sedan använda Zookeeper för att övervaka statusen för konfigurationsfilen i alla distribuerade system, när det väl har upptäckts att konfigurationsfilen har ändrats, Varje server får en notis från Zookeeper om att synkronisera konfigurationsfilerna i Zookeeper, och Zookeeper-tjänsten säkerställer också att synkroniseringsoperationen är atomär för att säkerställa att varje servers konfigurationsfil uppdateras korrekt.
Scenario 4: Tillhandahålla felreparationsfunktioner för distribuerade system. Klusterhantering är svårt, och att lägga till zookeeper-tjänsten i det distribuerade systemet gör det enkelt för oss att hantera klustret. Det mest besvärliga med klusterhantering är nodfelhantering, zookeeper kan låta klustret välja en frisk nod som master, masternoden känner till den aktuella hälsostatusen för varje server i klustret, när en nod misslyckas meddelar mastern de andra servrarna i klustret för att omfördela beräkningsuppgifterna för olika noder. Zookeeper kan inte bara hitta fel, utan även granska den felaktiga servern, se vilken typ av fel det är som gäller för felservern, om felet kan åtgärdas kan Zookeeper automatiskt åtgärda eller berätta orsaken till felet för systemadministratören, så att administratören snabbt kan hitta problemet och reparera nodens fel. Du kanske fortfarande har en fråga, vad ska jag göra om mastern är defekt? Zookeeper tar också hänsyn till detta, zookeeper har en intern "algoritm för att välja ledare", mästare kan valas dynamiskt, och när mästaren misslyckas kan djurvårdaren omedelbart välja en ny mästare för att hantera klustret.
Låt oss prata om zookeepers funktioner:
ZooKeeper är ett strömlinjeformat filsystem. Detta liknar lite Hadoop, men ZooKeeper-filsystemet hanterar små filer, medan Hadoop hanterar mycket stora filer.
Zookeeper tillhandahåller en mängd "artefakter" som möjliggör många operationer för att samordna datastrukturer och protokoll. Till exempel: distribuerade köer, distribuerade lås och "ledarval"-algoritmen för en grupp noder på samma nivå.
ZooKeeper är mycket tillgängligt, dess egen stabilitet är ganska god, distribuerade kluster kan förlita sig på hanteringen av Zookeeper-kluster, och ZooKeeper används för att undvika problemet med enskilda felpunkter i distribuerade system.
Zookeeper använder ett löst kopplat interaktionsläge. Detta är mest tydligt i att Zookeeper tillhandahåller distribuerade lås, som kan användas som en bokningsmekanism för att låta deltagande processer upptäcka och interagera med varandra utan att känna till de andra processerna (eller nätverket), och de deltagande parterna behöver inte ens existera samtidigt, så länge de lämnar ett meddelande i Zookeeper, och efter att processen avslutats kan en annan process läsa detta meddelande, vilket därmed frikopplar relationen mellan noderna.
ZooKeeper tillhandahåller ett delat arkiv för klustret, från vilket klustret kan läsa och skriva delad information centralt, vilket undviker programmering av delade operationer för varje nod och minskar utvecklingssvårigheterna för distribuerade system.
Zookeeper ansvarar främst för att lagra och hantera den data som alla bryr sig om, och sedan acceptera registreringen av observatörer; när statusen för dessa data ändras kommer Zookeeper att meddela de observatörer som har registrerat sig på Zookeeper att de ska agera därefter, för att uppnå ett master/slave-hanteringsläge liknande klustret.
Det kan ses att zookeeper är mycket gynnsamt för utveckling av distribuerade system, vilket kan göra distribuerade system mer robusta och effektiva.
För inte så länge sedan deltog jag i avdelningens hadoop-intressegrupp, och jag installerade hadoop, mapreduce, Hive och Hbase i testmiljön, och jag installerade Zookeeper i förväg när jag installerade hbase. Zookeeper kan tillhandahålla tjänster, så mer än hälften av de tre är 2, och mer än hälften av de 4 är också två, så installation av tre servrar kan uppnå effekten av 4 servrar. När jag lär mig Hadoop känner jag att Zookeeper är det svåraste delprojektet att förstå, anledningen är inte att det är tekniskt ansvarsfullt, utan att dess applikationsriktning är väldigt förvirrande för mig, så min första artikel om Hadoop-teknologi börjar med Zookeeper och handlar inte om specifik teknisk implementation, men utifrån applikationsscenarierna för Zookeeper förstår jag området Zookeeper-applikationer, jag tror att det blir mer effektivt att lära sig Zookeeper med halva ansträngningen.
Anledningen till att jag vill prata om Zookeeper idag är för att komplettera ramverket för distribuerade webbplatser i min tidigare artikel. Även om jag designade webbplatsarkitekturen som en distribuerad struktur, gjorde jag också en enkel felhanteringsmekanism, som heartbeat-mekanismen, men det finns fortfarande inget sätt att lösa klustrets enda felpunkt; om en server är trasig kommer klienten att försöka ansluta till denna server, vilket leder till blockering av vissa förfrågningar och även slöseri med serverresurser. Men jag vill inte ändra mitt ramverk just nu, eftersom jag alltid känner att tillägg av Zookeeper-tjänster till befintliga tjänster kommer att påverka webbplatsens effektivitet. Lyckligtvis har vår avdelning också hittat ett sådant problem, vår avdelning kommer att utveckla ett kraftfullt ramverk för fjärrsamtal, separera klusterhantering och kommunikationshantering, samt tillhandahålla effektiva och tillgängliga tjänster centralt.
Överförd från ttp://www.cnblogs.com/sharpxiajun/archive/2013/06/02/3113923.html |
Publicerad på 2017-07-18 14:19:01
|
|
|
