Zookeeper ir Hadoop apakšprojekts, un, lai gan tas ir atvasināts no hadoop, esmu atklājis, ka zookeeper arvien vairāk izmanto sadalītus ietvarus ārpus hadoop. Šodien es gribu runāt par zookeeper, šajā rakstā netiks runāts par to, kā izmantot zookeeper, bet kādi ir zookeeper praktiskie pielietojumi, kāda veida lietojumprogrammas var spēlēt zookeeper priekšrocības, un visbeidzot runāt par to, kāda loma zookeeper var būt izplatītajā tīmekļa vietnes arhitektūrā.
Zookeeper ir ļoti uzticama koordinācijas sistēma lielām izkliedētām sistēmām. No šīs definīcijas mēs zinām, ka zoodārza turētājs ir koordinēta sistēma, kas darbojas uz sadalītām sistēmām. Kāpēc izkliedētām sistēmām ir nepieciešama koordinācijas sistēma? Iemesli ir šādi:
Izkliedētas sistēmas izstrāde ir ļoti sarežģīta lieta, un grūtības galvenokārt atspoguļojas sadalītās sistēmas "daļējā kļūmē". "Daļēja kļūme" attiecas uz informācijas pārraidi starp diviem tīkla mezgliem, ja tīkls neizdodas, sūtītājs nevar zināt, vai saņēmējs ir saņēmis ziņojumu, un šīs kļūmes cēlonis ir sarežģīts, uztvērējs var būt saņēmis ziņojumu pirms tīkla kļūdas vai uztvērēja process ir miris. Vienīgais veids, kā sūtītājs var iegūt reālo attēlu, ir atkārtoti izveidot savienojumu ar uztvērēju un jautāt saņēmējam, kāpēc radās kļūda, kas ir "daļējas kļūmes" problēma izkliedētās sistēmas izstrādē.
Zookeeper ir sistēma sadalīto sistēmu "daļējas neveiksmes" risināšanai. Zookeeper neļauj izplatītajām sistēmām izvairīties no "daļējas kļūmes" problēmām, bet ļauj izplatītajām sistēmām pareizi risināt šādas problēmas, saskaroties ar daļējām kļūmēm, lai sadalītās sistēmas varētu normāli darboties.
Runāsim par zoodārza turētāja praktisko izmantošanu:
1. scenārijs: Ir serveru grupa, kas klientam sniedz noteiktu pakalpojumu (piemēram, iepriekš izveidotās izplatītās vietnes servera puse ir klasteris, kas sastāv no četriem serveriem, lai sniegtu pakalpojumus priekšgala klasterim), un mēs ceram, ka klients var atrast serveri serveru klasterī katru reizi, kad klients to pieprasa, lai serveris varētu sniegt klientam nepieciešamos pakalpojumus. Šim scenārijam mūsu programmā ir jābūt serveru sarakstam, no kura mēs lasām serveru sarakstu katru reizi, kad klients to pieprasa. Tad šo apakšsarakstu acīmredzot nevar saglabāt vienā mezgla serverī, pretējā gadījumā mezgls uzkarsies un viss klasteris neizdosies, un mēs ceram, ka šis saraksts tajā laikā būs ļoti pieejams. Ja serveris krātuves sarakstā ir bojāts, citi serveri var nekavējoties aizstāt salauzto serveri, un salauzto serveri var noņemt no saraksta, lai neveiksmīgais serveris varētu atteikties no visa klastera darbības, un visas šīs darbības nedarbosies neveiksmīgais serveris, bet gan parastais klastera serveris. Šī ir aktīva sadalīta datu struktūra, kas var aktīvi modificēt datu vienumu stāvokli, mainoties ārējiem apstākļiem. Zookeeper sistēma nodrošina šo pakalpojumu. Šī pakalpojuma nosaukums ir: Vienotais nosaukumu pakalpojums, kas ir ļoti līdzīgs JNDI pakalpojumam javaEE.
2. scenārijs: izkliedēts bloķēšanas pakalpojums. Kad izkliedēta sistēma manipulē ar datiem, piemēram, nolasa datus, analizē datus un visbeidzot modificē datus. Izplatītajā sistēmā šīs operācijas var izkliedēt uz dažādiem klastera mezgliem, tad datu darbības procesā ir konsekvences problēma, ja tā ir nekonsekventa, mēs iegūsim nepareizu darbības rezultātu, vienā procesa programmā konsekvences problēmu ir viegli atrisināt, bet ir grūtāk sasniegt sadalīto sistēmu, jo dažādu serveru darbība sadalītajā sistēmā notiek neatkarīgos procesos, un operācijas starpposma rezultāti un procesi ir jāpārraida caur tīklu. Tad ir daudz grūtāk sasniegt datu darbības konsekvenci. Zookeeper nodrošina bloķēšanas pakalpojumu, kas atrisina šo problēmu, ļaujot mums nodrošināt datu operāciju konsekvenci, veicot izkliedētas datu operācijas.
3. scenārijs: konfigurācijas pārvaldība. Izplatītā sistēmā mēs izvietosim pakalpojumu lietojumprogrammu n serveriem atsevišķi, un šo serveru konfigurācijas faili ir vienādi (piemēram, manis izstrādātajā izplatītajā tīmekļa vietnes sistēmā servera pusē ir 4 serveri, 4 serveru programmas ir vienādas, un konfigurācijas faili ir vienādi), ja mainās konfigurācijas failu konfigurācijas iespējas, tad mums ir jāmaina šie konfigurācijas faili pa vienam, ja mums ir jāmaina serveri ir salīdzinoši mazi, šīs darbības nav pārāk apgrūtinošas, Ja mums ir liels skaits izplatītu serveru, piemēram, liela interneta uzņēmuma Hadoop klasteris ar tūkstošiem serveru, tad konfigurācijas opciju maiņa var būt apgrūtinoša un bīstama lieta. Šajā laikā zookeeper var noderēt, mēs varam izmantot zookeeper kā ļoti pieejamu konfigurācijas atmiņu, nodot šādu lietu zookeeper pārvaldībai, mēs kopējam klastera konfigurācijas failu uz zookeeper failu sistēmas mezglu un pēc tam izmantojam zookeeper, lai uzraudzītu konfigurācijas faila statusu visās izplatītajās sistēmās, tiklīdz tiek konstatēts, ka konfigurācijas fails ir mainījies, Katrs serveris saņems paziņojumu no Zookeeper, lai sinhronizētu konfigurācijas failus Zookeeper, un Zookeeper pakalpojums arī nodrošinās, ka sinhronizācijas darbība ir atomiska, lai nodrošinātu, ka katra servera konfigurācijas fails tiek pareizi atjaunināts.
4. scenārijs: nodrošiniet kļūdu labošanas funkcijas izplatītajām sistēmām. Klasteru pārvaldība ir sarežģīta, un zoodārza uzturētāja pakalpojuma pievienošana izplatītajai sistēmai ļauj mums viegli pārvaldīt klasteri. Visapgrūtinošākā lieta klastera pārvaldībā ir mezglu kļūdu pārvaldība, zookeeper var ļaut klasterim izvēlēties veselīgu mezglu kā galveno, galvenais mezgls zinās katra klastera servera pašreizējo veselības stāvokli, tiklīdz mezgls neizdodas, kapteinis paziņos pārējiem klastera serveriem, lai pārdalītu dažādu mezglu skaitļošanas uzdevumus. Zookeeper var ne tikai atrast kļūdas, bet arī pārbaudīt bojāto serveri, redzēt, kāda veida kļūda ir kļūdas serveris, ja kļūdu var novērst, zookeeper var automātiski novērst vai pateikt sistēmas administratoram kļūdas iemeslu, lai administrators varētu ātri atrast problēmu un novērst mezgla kļūdu. Jums joprojām var rasties jautājums, kas man jādara, ja kapteinis ir bojāts? Zookeeper to arī ņem vērā, zookeeper ir iekšējs "līderu ievēlēšanas algoritms", meistarus var dinamiski izvēlēties, un, ja kapteinis neizdodas, zoodārza turētājs var nekavējoties izvēlēties jaunu meistaru, lai pārvaldītu klasteri.
Runāsim par zoodārza turētāja īpašībām:
ZooKeeper ir racionalizēta failu sistēma. Tas ir nedaudz līdzīgs Hadoop, bet ZooKeeper failu sistēma pārvalda mazus failus, bet Hadoop pārvalda ļoti lielus failus.
Zookeeper nodrošina daudz "artefaktu", kas ļauj daudzām operācijām koordinēt datu struktūras un protokolus. Piemēram: sadalītās rindas, sadalītās slēdzenes un viena līmeņa mezglu grupas "līdera vēlēšanas" algoritms.
ZooKeeper ir ļoti pieejams, tā stabilitāte ir diezgan laba, izplatītie klasteri var paļauties uz Zookeeper klasteru pārvaldību, un ZooKeeper tiek izmantots, lai izvairītos no izkliedēto sistēmu viena punkta kļūmes problēmas.
Zookeeper pieņem brīvi savienotu mijiedarbības režīmu. Tas ir visredzamākais faktā, ka zookeeper nodrošina izkliedētas slēdzenes, kuras var izmantot kā iecelšanas mehānismu, lai ļautu iesaistītajiem procesiem atklāt un mijiedarboties savā starpā, nezinot citus procesus (vai tīklu), un iesaistītajām pusēm pat nav jāpastāv vienlaicīgi, ja vien tās atstāj ziņojumu zookeeper, un pēc procesa beigām cits process var nolasīt šo ziņojumu, tādējādi atsaistot attiecības starp mezgliem.
ZooKeeper nodrošina koplietojamu klastera repozitoriju, no kura klasteris var centralizēti lasīt un rakstīt kopīgo informāciju, izvairoties no koplietošanas operāciju programmēšanas katram mezglam un samazinot sadalīto sistēmu izstrādes grūtības.
Zookeeper galvenokārt ir atbildīgs par visiem rūpošo datu glabāšanu un pārvaldību, un pēc tam par novērotāju reģistrācijas pieņemšanu, tiklīdz šo datu statuss mainīsies, Zookeeper būs atbildīgs par to novērotāju paziņošanu, kuri ir reģistrējušies Zookeeper, lai attiecīgi reaģētu, lai panāktu klasterim līdzīgu meistara/vergu pārvaldības režīmu.
Var redzēt, ka zookeeper ir ļoti labvēlīgs izkliedētas sistēmas attīstībai, kas var padarīt sadalītās sistēmas stabilākas un efektīvākas.
Pirms neilga laika es piedalījos departamenta hadoop interešu grupā, un testa vidē es instalēju hadoop, mapreduce, Hive un Hbase, un es iepriekš instalēju zookeeper, instalējot hbase. Zookeeper var sniegt pakalpojumus, tāpēc vairāk nekā puse no 3 ir 2, un vairāk nekā puse no 4 ir arī divi, tāpēc trīs serveru instalēšana var sasniegt 4 serveru efektu. Hadoop apguves procesā es uzskatu, ka zookeeper ir visgrūtāk saprotamais apakšprojekts, iemesls nav tas, ka tas ir tehniski atbildīgs, bet gan tas, ka tā pielietojuma virziens man ir ļoti mulsinošs, tāpēc mans pirmais raksts par hadoop tehnoloģiju sākas ar zookeeper un nerunā par konkrētu tehnisko ieviešanu, bet no zookeeper pielietojuma scenārijiem es saprotu zookeeper pielietojuma jomu, es domāju, ka zookeeper apguve būs efektīvāka ar pusi pūļu.
Iemesls, kāpēc es šodien vēlos runāt par zookeeper, ir papildināt izplatīto vietnes ietvaru manā iepriekšējā rakstā. Lai gan es izstrādāju vietnes arhitektūru kā izplatītu struktūru, es arī izveidoju vienkāršu kļūdu apstrādes mehānismu, piemēram, sirdsdarbības mehānismu, taču joprojām nav iespējams atrisināt klastera vienoto kļūmes punktu, ja serveris ir bojāts, klients mēģinās izveidot savienojumu ar šo serveri, kā rezultātā tiek bloķēti daži pieprasījumi, kā arī tiek izšķērdēti servera resursi. Tomēr šobrīd es nevēlos mainīt savu sistēmu, jo es vienmēr uzskatu, ka zoodārza uzturētāja pakalpojuma pievienošana esošajiem pakalpojumiem ietekmēs vietnes efektivitāti. Par laimi, arī mūsu nodaļa ir atradusi šādu problēmu, mūsu nodaļa izstrādās jaudīgu attālināto zvanu sistēmu, nodalīs klastera pārvaldību un komunikācijas pārvaldību un centralizēti nodrošinās efektīvus un pieejamus pakalpojumus.
Pārcelts no ttp://www.cnblogs.com/sharpxiajun/archive/2013/06/02/3113923.html |
Publicēts 18.07.2017 14:19:01
|
|
|
