Zookeeper is een subproject van Hadoop, en hoewel het is afgeleid van Hadoop, heb ik gemerkt dat Zookeeper steeds vaker gedistribueerde frameworks buiten Hadoop gebruikt. Vandaag wil ik het hebben over Zookeeper; dit artikel zal niet inspreken over hoe je Zookeeper gebruikt, maar wat de praktische toepassingen van Zookeeper zijn, welke soorten toepassingen de voordelen van Zookeeper kunnen benutten, en tot slot welke rol Zookeeper kan spelen in de gedistribueerde websitearchitectuur.
Zookeeper is een zeer betrouwbaar coördinatiesysteem voor grote gedistribueerde systemen. Uit deze definitie weten we dat Zookeeper een gecoördineerd systeem is dat werkt op gedistribueerde systemen. Waarom hebben gedistribueerde systemen een coördinatiesysteem nodig? De redenen hiervoor zijn als volgt:
Het ontwikkelen van een gedistribueerd systeem is een zeer moeilijke opgave, en de moeilijkheid komt vooral tot uiting in het "gedeeltelijke falen" van het gedistribueerde systeem. "Gedeeltelijke fout" verwijst naar het verzenden van informatie tussen twee knooppunten in het netwerk; als het netwerk faalt, kan de zender niet weten of de ontvanger het bericht heeft ontvangen, en de oorzaak van deze storing complex is, de ontvanger het bericht mogelijk wel of niet heeft ontvangen vóór de netwerkfout, of het proces van de ontvanger is dood. De enige manier waarop de zender het echte beeld kan krijgen, is door opnieuw verbinding te maken met de ontvanger en te vragen waarom de fout is opgetreden, wat het "gedeeltelijke falen"-probleem is bij de ontwikkeling van gedistribueerde systemen.
Zookeeper is het raamwerk voor het oplossen van de "gedeeltelijke falen" van gedistribueerde systemen. Zookeeper stelt gedistribueerde systemen niet in staat om "gedeeltelijke storingen" te vermijden, maar stelt gedistribueerde systemen wel in staat dergelijke problemen correct te behandelen bij gedeeltelijke storingen, zodat gedistribueerde systemen normaal kunnen functioneren.
Laten we het hebben over het praktische gebruik van Zookeeper:
Scenario 1: Er is een groep servers die een bepaalde dienst aan de client leveren (bijvoorbeeld, de serverzijde van de eerder gemaakte gedistribueerde website is een cluster bestaande uit vier servers om diensten te leveren aan de front-end cluster), en we hopen dat de client elke keer dat de client erom vraagt een server in de servercluster kan vinden, zodat de server de client de diensten kan leveren die de client nodig heeft. Voor dit scenario moeten we een lijst van servers in ons programma hebben, waaruit we elke keer dat de client erom vraagt de lijst lezen. Dan kan deze sublijst uiteraard niet op één enkele nodeserver worden opgeslagen, anders hangt de node op en faalt de hele cluster, en we hopen dat deze lijst dan zeer beschikbaar zal zijn. Als een server in de opslaglijst kapot is, kunnen andere servers onmiddellijk de kapotte server vervangen, en kan de kapotte server uit de lijst worden verwijderd, zodat de defecte server zich kan terugtrekken uit de werking van de hele cluster, en al deze bewerkingen niet door de mislukte server worden uitgevoerd, maar door de normale server in de cluster. Dit is een actieve gedistribueerde datastructuur die actief de status van data-items kan aanpassen wanneer externe omstandigheden veranderen. Het Zookeeper-framework biedt deze dienst. De naam van deze dienst is: Unified Naming Service, wat sterk lijkt op de JNDI-dienst in javaEE.
Scenario 2: Gedistribueerde slotservice. Wanneer een gedistribueerd systeem data manipuleert, zoals het lezen van data, het analyseren van data en uiteindelijk het wijzigen van data. In het gedistribueerde systeem kunnen deze bewerkingen worden verspreid over verschillende knooppunten in de cluster, dan ontstaat er een consistentieprobleem in het proces van databewerking; als het inconsistent is, krijgen we een verkeerde operatie, in één procesprogramma is het consistentieprobleem eenvoudig op te lossen, maar het is moeilijker om het gedistribueerde systeem te bereiken, omdat de bewerkingen van verschillende servers in het gedistribueerde systeem in onafhankelijke processen plaatsvinden en de tussenliggende resultaten en processen van de operatie via het netwerk moeten worden verzonden. Dan is het veel moeilijker om consistentie in data-operaties te bereiken. Zookeeper biedt een slotservice die dit probleem oplost, waardoor we de consistentie van databewerkingen kunnen waarborgen bij het uitvoeren van gedistribueerde databewerkingen.
Scenario 3: Configuratiebeheer. In een gedistribueerd systeem deployen we een serviceapplicatie op n servers apart, en de configuratiebestanden van deze servers zijn hetzelfde (bijvoorbeeld, in het gedistribueerde websiteframework dat ik heb ontworpen zijn er 4 servers aan de serverzijde, de programma's op de 4 servers zijn hetzelfde, en de configuratiebestanden zijn hetzelfde), als de configuratieopties van de configuratiebestanden veranderen, moeten we deze configuratiebestanden één voor één aanpassen, als we de servers moeten veranderen zijn relatief klein, zijn deze bewerkingen niet al te lastig, Als we een groot aantal gedistribueerde servers hebben, zoals de Hadoop-cluster van een groot internetbedrijf met duizenden servers, dan kan het veranderen van configuratieopties lastig en gevaarlijk zijn. Op dit moment kan Zookeeper handig zijn, we kunnen Zookeeper gebruiken als een zeer beschikbaar configuratiegeheugen, zoiets overdragen aan Zookeeper voor beheer, we kopiëren het configuratiebestand van de cluster naar een knooppunt in het bestandssysteem van de Zookeeper, en vervolgens Zookeeper gebruiken om de status van het configuratiebestand in alle gedistribueerde systemen te monitoren, zodra blijkt dat het configuratiebestand is veranderd, Elke server ontvangt een melding van Zookeeper om de configuratiebestanden in Zookeeper te synchroniseren, en de Zookeeper-service zorgt er ook voor dat de synchronisatieoperatie atomair is om te zorgen dat het configuratiebestand van elke server correct wordt bijgewerkt.
Scenario 4: Bied foutreparatiefuncties voor gedistribueerde systemen. Clusterbeheer is moeilijk, en het toevoegen van de zookeeper-service aan het gedistribueerde systeem maakt het voor ons eenvoudig om het cluster te beheren. Het meest problematische bij clusterbeheer is het beheer van knooppuntfouten; Zookeeper kan de cluster een gezonde knoop laten selecteren als master, de hoofdknoop weet de huidige gezondheidsstatus van elke server in de cluster, zodra een knoop faalt, zal de meester de andere servers in de cluster informeren om de rekentaken van verschillende knooppunten te herverdelen. Zookeeper kan niet alleen fouten vinden, maar ook de defecte server screenen, zien wat voor fout de foutserver is; als de fout kan worden opgelost, kan Zookeeper automatisch de systeembeheerder de reden van de fout oplossen of doorgeven, zodat de beheerder snel het probleem kan lokaliseren en de fout van de node kan repareren. Misschien heb je nog steeds een vraag: wat moet ik doen als de master defect is? Zookeeper houdt hier ook rekening mee: Zookeeper heeft een intern "algoritme voor het kiezen van leiders", masters kunnen dynamisch worden geselecteerd, en wanneer de master faalt, kan Zookeeper direct een nieuwe master selecteren om de cluster te beheren.
Laten we het hebben over de kenmerken van Zookeeper:
ZooKeeper is een gestroomlijnd bestandssysteem. Dit lijkt een beetje op Hadoop, maar het ZooKeeper-bestandssysteem beheert kleine bestanden, terwijl Hadoop zeer grote bestanden beheert.
Zookeeper biedt een schat aan "artefacten" die het mogelijk maken om veel operaties te gebruiken om datastructuren en protocollen te coördineren. Bijvoorbeeld: gedistribueerde wachtrijen, gedistribueerde locks en het "leiderverkiezing"-algoritme van een groep knopen op hetzelfde niveau.
ZooKeeper is zeer beschikbaar, de eigen stabiliteit is behoorlijk goed, gedistribueerde clusters kunnen vertrouwen op het beheer van Zookeeper-clusters, en ZooKeeper wordt gebruikt om het probleem van single point failure van gedistribueerde systemen te vermijden.
Zookeeper hanteert een losjes gekoppelde interactiemodus. Dit blijkt vooral uit het feit dat Zookeeper gedistribueerde sloten biedt, die kunnen worden gebruikt als een afspraakmechanisme om deelnemende processen in staat te stellen elkaar te ontdekken en met elkaar te communiceren zonder de andere processen (of het netwerk) te kennen, en de deelnemende partijen hoeven niet eens tegelijk te bestaan, zolang ze een bericht achterlaten in Zookeeper, en nadat het proces is beëindigd, kan een ander proces dit bericht lezen, waardoor de relatie tussen knooppunten wordt losgekoppeld.
ZooKeeper biedt een gedeelde repository voor de cluster, waaruit de cluster gedeelde informatie centraal kan lezen en schrijven, waardoor het programmeren van gedeelde bewerkingen voor elke knoop wordt voorkomen en de ontwikkelingsmoeilijkheden van gedistribueerde systemen worden verminderd.
Zookeeper is voornamelijk verantwoordelijk voor het opslaan en beheren van de data waar iedereen om geeft, en accepteert vervolgens de registratie van waarnemers; zodra de status van deze data verandert, zal Zookeeper verantwoordelijk zijn voor het informeren van de waarnemers die zich op Zookeeper hebben geregistreerd om dienovereenkomstig te reageren, zodat een master/slave managementmodus wordt bereikt vergelijkbaar met de cluster.
Uit te zien is dat Zookeeper zeer bevorderlijk is voor de ontwikkeling van gedistribueerde systemen, wat gedistribueerde systemen robuuster en efficiënter kan maken.
Niet zo lang geleden deed ik mee aan de hadoop interessegroep van de afdeling, en ik installeerde hadoop, mapreduce, Hive en Hbase in de testomgeving, en ik installeerde Zookeeper van tevoren bij de installatie van hbase. Zookeeper kan diensten leveren, dus meer dan de helft van de 3 is 2, en meer dan de helft van de 4 is ook twee, dus het installeren van drie servers kan het effect van 4 servers bereiken. Tijdens het leren van Hadoop vind ik dat Zookeeper het moeilijkst te begrijpen subproject is, de reden is niet dat het technisch verantwoordelijk is, maar dat de toepassingsrichting voor mij erg verwarrend is, dus mijn eerste artikel over Hadoop-technologie begint met Zookeeper en bespreekt geen specifieke technische implementatie, maar uit de toepassingsscenario's van Zookeeper begrijp ik het vakgebied van Zookeeper-toepassingen; ik denk dat het leren van Zookeeper effectiever zal zijn met de helft van de inspanning.
De reden dat ik het vandaag over Zookeeper wil hebben, is om het distributed website-framework uit mijn vorige artikel aan te vullen. Hoewel ik de websitearchitectuur als een gedistribueerde structuur heb ontworpen, heb ik ook een eenvoudig foutafhandelingsmechanisme gemaakt, zoals het heartbeat-mechanisme, maar er is nog steeds geen manier om het single point of failure van de cluster op te lossen; als een server kapot is, probeert de client verbinding te maken met deze server, wat resulteert in het blokkeren van sommige verzoeken en ook tot verspilling van serverbronnen. Toch wil ik mijn framework op dit moment niet aanpassen, omdat ik altijd het gevoel heb dat het toevoegen van Zookeeper-diensten aan bestaande diensten de efficiëntie van de website zal beïnvloeden. Gelukkig heeft onze afdeling dit probleem ook gevonden; onze afdeling zal een krachtig raamwerk voor afstandsgesprekken ontwikkelen, het clusterbeheer en communicatiebeheer scheiden, en efficiënte en beschikbare diensten centraal leveren.
Overgeplaatst van ttp://www.cnblogs.com/sharpxiajun/archive/2013/06/02/3113923.html |
Geplaatst op 18-07-2017 14:19:01
|
|
|
