Zookeeper este un subproiect al Hadoop și, deși derivă din hadoop, am descoperit că zookeeper folosește tot mai mult cadre distribuite în afara Hadoop. Astăzi vreau să vorbesc despre zookeeper, acest articol nu va vorbi despre cum să folosești zookeeper, ci despre aplicațiile practice ale zookeeper, ce tipuri de aplicații pot juca avantajele zookeeper și, în final, despre rolul pe care zookeeper îl poate juca în arhitectura distribuită a site-urilor web.
Zookeeper este un sistem de coordonare extrem de fiabil pentru sisteme distribuite mari. Din această definiție, știm că îngrijitorul de grădini zoologice este un sistem coordonat care acționează asupra sistemelor distribuite. De ce au nevoie sistemele distribuite de un sistem de coordonare? Motivele sunt următoarele:
Dezvoltarea unui sistem distribuit este un lucru foarte dificil, iar dificultatea se reflectă în principal în "eșecul parțial" al sistemului distribuit. "Eșec parțial" se referă la transmiterea informației între două noduri ale rețelei; dacă rețeaua eșuează, emițătorul nu poate ști dacă receptorul a primit mesajul, iar cauza acestei efecțiuni este complexă, receptorul poate sau nu să fi primit mesajul înainte de eroarea rețelei, sau procesul receptorului este mort. Singura modalitate prin care emițătorul poate obține imaginea reală este să se reconecteze la receptor și să întrebe receptorul de ce a apărut eroarea, ceea ce reprezintă problema "eșecului parțial" în dezvoltarea sistemelor distribuite.
Zookeeper este cadrul pentru rezolvarea "eșecului parțial" al sistemelor distribuite. Zookeeper nu permite sistemelor distribuite să evite problemele de "defecțiune parțială", dar permite sistemelor distribuite să gestioneze corect astfel de probleme atunci când întâlnesc defecțiuni parțiale, astfel încât sistemele distribuite să poată funcționa normal.
Să vorbim despre utilizarea practică a sistemului de îngrijire a grădinii zoologice:
Scenariul 1: Există un grup de servere care oferă un anumit serviciu clientului (de exemplu, partea de server a site-ului distribuit pe care l-am creat anterior este un cluster compus din patru servere pentru a furniza servicii clusterului front-end), și sperăm ca clientul să poată găsi un server în clusterul de servere de fiecare dată când clientul îl solicită, astfel încât serverul să poată oferi clientului serviciile necesare clientului. Pentru acest scenariu, trebuie să avem o listă de servere în programul nostru, din care citim lista serverelor de fiecare dată când clientul o solicită. Atunci, această sublistă evident nu poate fi stocată pe un singur server nod, altfel nodul se va bloca și întregul cluster va eșua, iar sperăm ca această listă să fie foarte disponibilă atunci. Dacă un server din lista de stocare este defect, alți servere pot înlocui imediat serverul defect, iar serverul defect poate fi eliminat din listă, astfel încât serverul defect să se poată retrage din funcționarea întregului cluster, iar toate aceste operațiuni nu vor fi operate de serverul defect, ci de serverul normal din cluster. Aceasta este o structură de date distribuită activă care poate modifica activ starea elementelor de date atunci când condițiile externe se schimbă. Cadrul Zookeeper oferă acest serviciu. Numele acestui serviciu este: Unified Naming Service, care este foarte asemănător cu serviciul JNDI din javaEE.
Scenariul 2: Serviciu de încuietori distribuiți. Când un sistem distribuit manipulează date, cum ar fi citirea datelor, analiza datelor și, în final, modificarea datelor. În sistemul distribuit, aceste operații pot fi dispersate către diferite noduri din cluster, iar atunci apare o problemă de consistență în procesul de operare a datelor; dacă este inconsistent, vom obține un rezultat greșit al operației; într-un singur program de proces, problema consistenței este ușor de rezolvat, dar este mai dificil să ajungi la sistemul distribuit, deoarece operațiunile diferiților servere din sistemul distribuit sunt în procese independente, iar rezultatele intermediare și procesele operațiunii trebuie transmise prin rețea. Atunci devine mult mai dificil să se obțină consistența operațiunilor de date. Zookeeper oferă un serviciu de blocare care rezolvă această problemă, permițându-ne să asigurăm consistența operațiunilor de date atunci când efectuăm operațiuni distribuite.
Scenariul 3: Managementul configurației. Într-un sistem distribuit, vom implementa o aplicație de serviciu pe n servere separat, iar fișierele de configurare ale acestor servere sunt aceleași (de exemplu, în cadrul de site-uri distribuite pe care l-am proiectat, sunt 4 servere pe partea de server, programele de pe cele 4 servere sunt aceleași, iar fișierele de configurare sunt aceleași), dacă opțiunile de configurare ale fișierelor de configurare se schimbă, atunci trebuie să schimbăm aceste fișiere de configurare unul câte unul, dacă trebuie să schimbăm serverele sunt relativ mici, aceste operațiuni nu sunt prea problematice, Dacă avem un număr mare de servere distribuite, cum ar fi clusterul Hadoop al unei companii mari de internet cu mii de servere, atunci schimbarea opțiunilor de configurare poate fi un lucru problematic și periculos. În acest moment, zookeeper poate fi util, putem folosi zookeeper ca o memorie de configurare foarte disponibilă, să predăm un astfel de lucru către zookeeper pentru management, să copiem fișierul de configurare al clusterului într-un nod din sistemul de fișiere al zookeeper, apoi să folosim zookeeper pentru a monitoriza starea fișierului de configurare în toate sistemele distribuite, odată ce se constată că fișierul de configurare s-a schimbat, Fiecare server va primi o notificare de la Zookeeper pentru a sincroniza fișierele de configurare din Zookeeper, iar serviciul Zookeeper va asigura, de asemenea, că operațiunea de sincronizare este atomică pentru a asigura actualizarea corectă a fiecărui fișier de configurare.
Scenariul 4: Furnizarea de funcții de reparare a defecțiunilor pentru sistemele distribuite. Gestionarea clusterului este dificilă, iar adăugarea serviciului de îngrijire a grădinii zoologice în sistemul distribuit ne ușurează gestionarea clusterului. Cel mai problematic lucru în gestionarea clusterului este gestionarea erorilor nodurilor, zookeeper poate permite clusterului să selecteze un nod sănătos ca master, nodul master va cunoaște starea actuală de sănătate a fiecărui server din cluster, iar când un nod eșuează, masterul va notifica celelalte servere din cluster pentru a redistribui sarcinile de calcul ale diferitelor noduri. Zookeeper nu doar că poate găsi defecte, dar poate și verifica serverul defect, să vadă ce tip de defect este, dacă defectul poate fi reparat, zookeeper poate corecta automat sau spune administratorului de sistem motivul eroării, astfel încât administratorul să poată localiza rapid problema și să repare defectul nodului. S-ar putea să ai totuși o întrebare: ce ar trebui să fac dacă masterul este defect? Zookeeper ia în considerare și acest lucru, zookeeper are un "algoritm intern pentru alegerea liderilor", stăpânii pot fi selectați dinamic, iar când masterul eșuează, zookeeper poate selecta imediat un nou master pentru a gestiona clusterul.
Să vorbim despre caracteristicile îngrijitorilor de grădină zoologică:
ZooKeeper este un sistem de fișiere simplificat. Este puțin similar cu Hadoop, dar sistemul de fișiere ZooKeeper gestionează fișiere mici, în timp ce Hadoop gestionează fișiere foarte mari.
Zookeeper oferă o bogăție de "artefacte" care permit multor operațiuni să coordoneze structuri de date și protocoale. De exemplu: cozi distribuite, blocaje distribuite și algoritmul de "alegere a liderului" al unui grup de noduri la același nivel.
ZooKeeper este foarte disponibil, stabilitatea sa este destul de bună, clusterele distribuite se pot baza pe gestionarea clusterelor Zookeeper, iar ZooKeeper este folosit pentru a evita problema eșecului punctual al sistemelor distribuite.
Zookeeper adoptă un mod de interacțiune slab cuplat. Acest lucru este cel mai evident în faptul că zookeeper oferă blocaje distribuite, care pot fi folosite ca mecanism de programare pentru a permite proceselor participante să se descopere și să interacționeze între ele fără a cunoaște celelalte procese (sau rețeaua), iar părțile participante nici măcar nu trebuie să existe în același timp, atâta timp cât lasă un mesaj în zookeeper, iar după încheierea procesului, un alt proces poate citi acest mesaj, decuplând astfel relația dintre noduri.
ZooKeeper oferă un depozit partajat pentru cluster, de unde clusterul poate citi și scrie informații partajate centralizat, evitând programarea operațiunilor partajate pentru fiecare nod și reducând dificultatea dezvoltării sistemelor distribuite.
Zookeeper este responsabil în principal pentru stocarea și gestionarea datelor care contează pentru toată lumea, iar apoi acceptarea înregistrării observatorilor; odată ce starea acestor date se schimbă, Zookeeper va fi responsabil să notifice observatorii care s-au înregistrat pe Zookeeper să răspundă corespunzător, astfel încât să obțină un mod de management master/slave similar cu clusterul.
Se poate observa că Zookeeper este foarte favorabil dezvoltării sistemelor distribuite, ceea ce poate face sistemele distribuite mai robuste și mai eficiente.
Nu demult, am participat la grupul de interese hadoop al departamentului și am instalat hadoop, mapreduce, Hive și Hbase în mediul de testare, iar zookeeper am instalat dinainte când am instalat hbase. Zookeeper poate oferi servicii, deci mai mult de jumătate din cele 3 sunt 2, iar mai mult de jumătate din cele 4 sunt și două, deci instalarea a trei servere poate avea efectul a 4 servere. În procesul de învățare a Hadoop, simt că Zookeeper este cel mai dificil subproiect de înțeles, motivul nu este că este tehnic responsabil, ci că direcția sa de aplicare este foarte confuză pentru mine, așa că primul meu articol despre tehnologia Hadoop începe cu Zookeeper și nu vorbește despre implementări tehnice specifice, dar din scenariile de aplicare ale Zookeeper, înțeleg domeniul aplicațiilor Zookeeper, cred că învățarea Zookeeper va fi mai eficientă cu jumătate din efort.
Motivul pentru care vreau să vorbesc astăzi despre zookeeper este pentru a completa cadrul distribuit al site-ului web din articolul meu anterior. Deși am proiectat arhitectura site-ului să fie o structură distribută, am creat și un mecanism simplu de gestionare a erorilor, cum ar fi mecanismul heartbeat, dar tot nu există o modalitate de a rezolva punctul unic de eșec al clusterului; dacă un server este defect, clientul va încerca să se conecteze la acel server, ceea ce va duce la blocarea unor cereri și la risipa de resurse ale serverului. Totuși, nu vreau să-mi modific cadrul momentan, pentru că simt mereu că adăugarea serviciului de îngrijire zoologică la serviciile existente va afecta eficiența site-ului. Din fericire, departamentul nostru a identificat și el o astfel de problemă: va dezvolta un cadru puternic pentru apeluri la distanță, va separa managementul clusterului de cel al comunicațiilor și va oferi servicii eficiente și disponibile centralizat.
Transferat de la ttp://www.cnblogs.com/sharpxiajun/archive/2013/06/02/3113923.html |
Postat pe 18.07.2017 14:19:01
|
|
|
