Javaslom, hogy olvassa el a "Hadoop. ZooKeeper" előadás átiratát a "Módszerek nagy mennyiségű adat elosztott feldolgozására a Hadoopban" sorozatból.
Mi az a ZooKeeper, a helye a Hadoop ökoszisztémában. Valótlanságok az elosztott számítástechnikával kapcsolatban. Egy szabványos elosztott rendszer diagramja. Nehézségek az elosztott rendszerek koordinálásában. Tipikus koordinációs problémák. A ZooKeeper tervezésének alapelvei. ZooKeeper adatmodell. znode zászlók. Munkamenetek. Kliens API. Primitívek (konfiguráció, csoporttagság, egyszerű zárak, vezetőválasztás, zárás falkahatás nélkül). ZooKeeper architektúra. ZooKeeper DB. ZAB. Kérelemkezelő.
Ma a ZooKeeperről fogunk beszélni. Ez a dolog nagyon hasznos. Mint minden Apache Hadoop terméknek, van logója. Egy férfit ábrázol.
Előtte főleg arról beszéltünk, hogy hogyan lehet ott adatokat feldolgozni, tárolni, vagyis valahogyan felhasználni és valahogy dolgozni velük. És ma szeretnék egy kicsit beszélni az elosztott alkalmazások létrehozásáról. A ZooKeeper pedig az egyik olyan dolog, amely lehetővé teszi az ügy egyszerűsítését. Ez egy olyan szolgáltatás, amely az elosztott rendszerekben, elosztott alkalmazásokban zajló folyamatok interakciójának valamilyen koordinációját szolgálja.
Napról napra egyre nagyobb az igény az ilyen jellegű pályázatokra, erről szól tanfolyamunk. Egyrészt a MapReduce és ez a kész keretrendszer lehetővé teszi ennek a komplexitásnak a kiegyenlítését, és megszabadítja a programozót az olyan primitívek írásától, mint az interakció és a folyamatok koordinálása. De másrészt senki sem garantálja, hogy ezt úgysem kell megtenni. A MapReduce vagy más kész keretrendszerek nem mindig helyettesítenek teljesen bizonyos eseteket, amelyeket ezzel nem lehet megvalósítani. Magát a MapReduce-t és egy csomó más Apache-projektet is beleértve; valójában ezek is elosztott alkalmazások. És hogy könnyebb legyen az írás, megírták a ZooKeeper-t.
Mint minden Hadoophoz kapcsolódó alkalmazást, ezt is a Yahoo! Immár hivatalos Apache alkalmazás is. Nem olyan aktívan fejlesztik, mint a HBase. Ha a JIRA HBase-re mész, akkor minden nap jön egy rakás hibajelentés, egy csomó javaslat valami optimalizálására, vagyis folyamatosan zajlik az élet a projektben. A ZooKeeper pedig egyrészt egy viszonylag egyszerű termék, másrészt ez biztosítja a megbízhatóságát. Használata pedig meglehetősen egyszerű, ezért vált szabványossá a Hadoop ökoszisztémán belüli alkalmazásokban. Ezért úgy gondoltam, hogy hasznos lenne átnézni, hogy megértsük, hogyan működik és hogyan kell használni.
Ez egy kép egy előadásunkról. Azt mondhatjuk, hogy ortogonális mindarra, amit eddig figyelembe vettünk. És minden, ami itt van feltüntetve, valamilyen szinten működik a ZooKeeperrel, vagyis ez egy olyan szolgáltatás, amely ezeket a termékeket használja. Sem a HDFS, sem a MapReduce nem ír saját hasonló szolgáltatásokat, amelyek kifejezetten nekik működnének. Ennek megfelelően a ZooKeeper-t használják. Ez pedig leegyszerűsíti a fejlesztést és néhány, a hibákkal kapcsolatos dolgot.
Honnan jön mindez? Úgy tűnik, hogy párhuzamosan elindítottunk két alkalmazást különböző számítógépeken, összekapcsoltuk őket egy karakterlánccal vagy egy hálóban, és minden működik. De a probléma az, hogy a hálózat megbízhatatlan, és ha beszippantja a forgalmat, vagy alacsony szinten megnézi, hogy mi történik ott, hogyan működnek együtt a kliensek a hálózaton, gyakran láthatja, hogy egyes csomagok elvesznek vagy újra elküldik. Nem véletlenül találták ki a TCP protokollokat, amelyek lehetővé teszik egy bizonyos munkamenet létrehozását és az üzenetek kézbesítését. De mindenesetre még a TCP sem tudja mindig megmenteni. Mindennek van időkorlátja. Előfordulhat, hogy a hálózat egy időre egyszerűen megszakad. Lehet, hogy csak villog. És mindez ahhoz a tényhez vezet, hogy nem bízhat a hálózat megbízhatóságában. Ez a fő különbség az egy számítógépen vagy egy szuperszámítógépen futó párhuzamos alkalmazások írásától, ahol nincs Hálózat, ahol megbízhatóbb adatcserebusz van a memóriában. És ez alapvető különbség.
Többek között a hálózat használatakor mindig van egy bizonyos késleltetés. A lemezen is van, de a Hálózaton több van belőle. A késleltetés némi késleltetési idő, amely lehet kicsi vagy meglehetősen jelentős.
A hálózati topológia megváltozik. Mi a topológia - ez a hálózati berendezéseink elhelyezése. Vannak adatközpontok, vannak állványok, amelyek ott állnak, vannak gyertyák. Mindez visszaköthető, áthelyezhető stb. Mindezt szintén figyelembe kell venni. Változnak az IP-nevek, megváltozik az útvonal, amelyen a forgalmunk halad. Ezt is figyelembe kell venni.
A hálózat felszereltsége is változhat. A gyakorlatból azt mondhatom, hogy hálózatmérnökeink nagyon szeretnek rendszeresen frissíteni valamit a gyertyákon. Hirtelen kijött egy új firmware, és nem különösebben érdekelte őket valami Hadoop-fürt. Saját munkájuk van. Számukra az a fő, hogy a Hálózat működjön. Ennek megfelelően oda akarnak újra feltölteni valamit, flashelést csinálni a hardverükön, és a hardver is időszakosan változik. Mindezt valahogy figyelembe kell venni. Mindez kihat az elosztott alkalmazásunkra.
Általában azok az emberek, akik valamilyen okból nagy mennyiségű adattal kezdenek dolgozni, azt hiszik, hogy az internet határtalan. Ha van ott egy több terabájtos fájl, akkor viheti a szerverére vagy a számítógépére, és megnyithatja a segítségével hogyan és figyelj. Egy másik hiba van benne életkedv nézd meg a rönköket. Soha ne tedd ezt, mert rossz. Mert a Vim mindent megpróbál pufferelni, mindent betölteni a memóriába, különösen akkor, amikor elkezdünk mozogni ezen a naplón, és keresünk valamit. Ezek olyan dolgok, amelyeket elfelejtenek, de érdemes megfontolni.
Könnyebb olyan programot írni, amely egy számítógépen, egy processzorral fut.
Amikor a rendszerünk növekszik, az egészet párhuzamosítani akarjuk, és nem csak számítógépen, hanem klaszteren is párhuzamosítani szeretnénk. Felmerül a kérdés: hogyan lehet ezt az ügyet koordinálni? Alkalmazásaink talán nem is interakcióba lépnek egymással, de több folyamatot futtattunk párhuzamosan több szerveren. És hogyan lehet nyomon követni, hogy minden jól menjen-e nekik? Például küldenek valamit az interneten keresztül. Valahol meg kell írniuk állapotukat, például valamilyen adatbázisban vagy naplóban, majd ezt a naplót összesíteniük, majd valahol elemezniük kell. Ráadásul azt is figyelembe kell venni, hogy a folyamat működött és működött, hirtelen valami hiba jelent meg benne, vagy lefagyott, akkor milyen gyorsan fogunk rájönni?
Nyilvánvaló, hogy mindez gyorsan nyomon követhető. Ez is jó, de a monitorozás egy korlátozott dolog, amely lehetővé teszi bizonyos dolgok legmagasabb szintű megfigyelését.
Amikor azt akarjuk, hogy folyamataink kölcsönhatásba lépjenek egymással, például küldjenek egymásnak néhány adatot, akkor szintén felmerül a kérdés – hogyan fog ez megtörténni? Lesz-e valamilyen versenyállapot, felülírják egymást, helyesen érkeznek az adatok, elveszik valami útközben? Valamilyen protokollt kell kidolgoznunk stb.
Mindezen folyamatok összehangolása nem triviális dolog. És arra kényszeríti a fejlesztőt, hogy menjen le még alacsonyabb szintre, és írja meg a rendszereket vagy a semmiből, vagy nem egészen a semmiből, de ez nem ilyen egyszerű.
Ha kitalál egy kriptográfiai algoritmust, vagy akár megvalósítod, akkor azonnal dobd el, mert nagy valószínűséggel nem fog működni. Valószínűleg egy csomó hibát tartalmaz, amelyeket elfelejtett megadni. Soha ne használja semmi komolyra, mert nagy valószínűséggel instabil lesz. Mert az összes létező algoritmust már nagyon régóta tesztelte az idő. A közösség megzavarja. Ez egy külön téma. És ez itt is ugyanaz. Ha lehetséges, hogy ne hajtson végre valamilyen folyamatszinkronizálást, akkor jobb, ha ezt nem teszi meg, mert ez meglehetősen bonyolult, és a folyamatos hibakeresés ingatag útjára vezet.
Ma a ZooKeeperről beszélünk. Egyrészt egy keretrendszer, másrészt egy olyan szolgáltatás, amely megkönnyíti a fejlesztő életét, és amennyire csak lehetséges, leegyszerűsíti a logika megvalósítását és a folyamataink koordinációját.
Emlékezzünk arra, hogyan nézhet ki egy szabványos elosztott rendszer. Erről beszéltünk - HDFS, HBase. Létezik egy Master folyamat, amely kezeli a dolgozókat és a rabszolga folyamatokat. Feladata a feladatok koordinálása, elosztása, a dolgozók újraindítása, újak indítása, a terhelés elosztása.
Fejlettebb dolog a Coordination Service, vagyis magát a koordinációs feladatot helyezzük át egy külön folyamatba, plusz futtassunk párhuzamosan valamilyen backup vagy készenléti Mastert, mert a Master meghibásodhat. És ha a Mester elesik, akkor a rendszerünk nem fog működni. Biztonsági mentést futtatunk. Egyes kijelentések szerint a mestert replikálni kell a biztonsági mentéshez. Ezzel a Koordinációs Szolgálatot is meg lehet bízni. De ezen a diagramon maga a Mester felelős a dolgozók koordinálásáért, itt a szolgáltatás koordinálja az adatreplikációs tevékenységeket.
Fejlettebb lehetőség, ha minden koordinációt a mi szolgáltatásunk intéz, ahogyan általában. Felelősséget vállal azért, hogy minden működjön. És ha valami nem működik, tájékozódunk róla, és megpróbáljuk megkerülni ezt a helyzetet. Mindenesetre marad nekünk egy Mester, aki valamilyen módon kapcsolatba lép a rabszolgákkal, és valamilyen szolgáltatáson keresztül adatokat, információkat, üzeneteket stb.
Létezik egy még fejlettebb séma, amikor nincs mesterünk, akkor minden csomópont master slave, eltérő viselkedésű. De továbbra is kölcsönhatásba kell lépniük egymással, így még mindig maradt néhány szolgáltatás ezeknek a tevékenységeknek a koordinálására. Valószínűleg Cassandra, amely ezen az elven dolgozik, illeszkedik ehhez a sémához.
Nehéz megmondani, hogy ezek közül a rendszerek közül melyik működik jobban. Mindegyiknek megvannak a maga előnyei és hátrányai.
És a Mesternél nem kell félni néhány dologtól, mert amint azt a gyakorlat mutatja, nem annyira fogékony az állandó szolgálatra. Itt a lényeg az, hogy a megfelelő megoldást válasszuk ki ennek a szolgáltatásnak egy külön nagy teljesítményű csomóponton való tárolására, hogy elegendő erőforrással rendelkezzen, hogy lehetőleg ne férhessenek hozzá a felhasználók, nehogy véletlenül megöljék ezt a folyamatot. Ugyanakkor egy ilyen sémában sokkal könnyebb kezelni a dolgozókat a Mester folyamatból, vagyis ez a séma egyszerűbb a megvalósítás szempontjából.
És ez a séma (fent) valószínűleg összetettebb, de megbízhatóbb.
A fő probléma a részleges hibák. Például amikor üzenetet küldünk a hálózaton keresztül, akkor valamiféle baleset történik, és az üzenetet küldő nem tudja, hogy az üzenete megérkezett-e, és mi történt a címzett oldalán, nem tudja, hogy az üzenetet megfelelően dolgozták-e fel. , azaz nem kap semmilyen visszaigazolást.
Ennek megfelelően ezt a helyzetet fel kell dolgoznunk. A legegyszerűbb pedig az, hogy újra elküldjük ezt az üzenetet, és megvárjuk, amíg választ kapunk. Ebben az esetben nem veszik figyelembe, hogy a vevő állapota megváltozott-e. Üzenetet küldhetünk, és ugyanazokat az adatokat kétszer hozzáadhatjuk.
A ZooKeeper módszereket kínál az ilyen visszautasítások kezelésére, ami szintén megkönnyíti az életünket.
Mint egy kicsit korábban említettük, ez hasonló a többszálú programok írásához, de a fő különbség az, hogy az elosztott alkalmazásokban, amelyeket különböző gépekre építünk, a kommunikáció egyetlen módja a Hálózat. Lényegében ez egy megosztott-semmi architektúra. Minden folyamatnak vagy szolgáltatásnak, amely egy gépen fut, saját memóriája, saját lemeze, saját processzora van, amit nem oszt meg senkivel.
Ha többszálas programot írunk egy számítógépre, akkor az osztott memóriát használhatjuk adatcserére. Ott van egy kontextuskapcsolónk, a folyamatok válthatnak. Ez befolyásolja a teljesítményt. Egyrészt klaszteren a programban nincs ilyen, de a Hálózattal vannak gondok.
Ennek megfelelően az elosztott rendszerek írásakor felmerülő fő problémák a konfiguráció. Valamilyen pályázatot írunk. Ha egyszerű, akkor mindenféle számot keményen kódolunk a kódban, de ez kényelmetlen, mert ha úgy döntünk, hogy fél másodperces időkorlát helyett egy másodperces időt akarunk, akkor újra kell fordítani az alkalmazást és mindent kidobunk újra. Az egy dolog, ha egy gépen van, amikor csak újra lehet indítani, de ha sok gépünk van, akkor folyamatosan mindent másolnunk kell. Meg kell próbálnunk konfigurálhatóvá tenni az alkalmazást.
Itt a rendszerfolyamatok statikus konfigurációjáról beszélünk. Ez nem teljesen, talán operációs rendszer szempontjából, lehet, hogy ez egy statikus konfiguráció a folyamatainkhoz, vagyis ez egy olyan konfiguráció, amelyet nem lehet egyszerűen átvenni és frissíteni.
Létezik dinamikus konfiguráció is. Ezek azok a paraméterek, amelyeket menet közben szeretnénk megváltoztatni, hogy ott felvegyék őket.
Mi itt a probléma? Frissítettük a konfigurációt, kiadtuk, akkor mi van? A probléma az lehet, hogy egyrészt kigördítettük a konfigot, de az új dolgot elfelejtettük, ott maradt a konfig. Másodszor, a bevezetés közben a konfigurációt egyes helyeken frissítették, máshol viszont nem. És az alkalmazásunk egyes folyamatai, amelyek egy gépen futnak, újraindultak egy új konfigurációval, valahol pedig egy régivel. Ez azt eredményezheti, hogy az elosztott alkalmazásunk konfigurációs szempontból inkonzisztens. Ez a probléma gyakori. Dinamikus konfiguráció esetén ez relevánsabb, mert azt jelenti, hogy menet közben módosítható.
A másik probléma a csoporttagság. Mindig vannak munkásaink, mindig tudni akarjuk, melyikük él, melyikük halt meg. Ha van Mester, akkor neki meg kell értenie, hogy mely dolgozókat lehet átirányítani az ügyfelekhez, hogy számításokat végezzenek vagy adatokkal dolgozzanak, és melyeket nem. Folyamatosan felmerülő probléma, hogy tudnunk kell, ki dolgozik a klaszterünkben.
Egy másik tipikus probléma a vezetőválasztás, amikor tudni akarjuk, ki a felelős. Az egyik példa a replikáció, amikor van valamilyen folyamatunk, amely írási műveleteket kap, majd más folyamatok között replikálja azokat. Ő lesz a vezető, mindenki más engedelmeskedik neki, követni fogja. Olyan folyamatot kell kiválasztani, hogy az mindenki számára egyértelmű legyen, nehogy két vezető kerüljön kiválasztásra.
Létezik kölcsönösen kizáró hozzáférés is. A probléma itt összetettebb. Létezik olyan dolog, mint a mutex, amikor többszálú programokat írunk, és hozzáférést szeretnénk elérni valamilyen erőforráshoz, például egy memóriacellához, amelyet csak egy szál korlátozna és hajtana végre. Itt az erőforrás lehetne valami elvontabb. És a hálózatunk különböző csomópontjaiból származó különböző alkalmazások csak egy adott erőforráshoz kapjanak kizárólagos hozzáférést, és nem azért, hogy mindenki módosíthassa vagy írhasson oda valamit. Ezek az úgynevezett zárak.
A ZooKeeper lehetővé teszi, hogy ezeket a problémákat valamilyen szinten megoldja. És példákkal mutatom be, hogyan teszi ezt lehetővé.
Nincsenek blokkoló primitívek. Amikor elkezdünk valamit használni, ez a primitív nem várja meg az esemény bekövetkeztét. Valószínűleg ez a dolog aszinkron módon fog működni, így lehetővé teszi, hogy a folyamatok ne lógjanak le, miközben várnak valamire. Ez egy nagyon hasznos dolog.
Minden ügyfélkérelem feldolgozása az általános várakozási sor sorrendjében történik.
Az ügyfeleknek pedig lehetőségük van értesítést kapni az egyes állapotok változásairól, az adatok változásairól, mielőtt az ügyfél maga látná a megváltozott adatokat.
A ZooKeeper két módban tud működni. Az első önálló, egy csomóponton. Ez kényelmes a teszteléshez. Fürt módban is működhet tetszőleges számú kiszolgálón. Ha van egy 100 gépből álló klaszterünk, akkor nem szükséges, hogy 100 gépen működjön. Elég több gépet kiválasztani, ahol a ZooKeeper futtatható. És a magas rendelkezésre állás elvét vallja. A ZooKeeper minden futó példányon az adatok teljes másolatát tárolja. Később elmondom, hogyan csinálja. Nem törli fel az adatokat és nem particionálja azokat. Egyrészt mínusz, hogy nem tudunk sokat tárolni, másrészt erre nincs szükség. Nem erre tervezték, nem adatbázis.
Az adatok a kliens oldalon gyorsítótárazhatók. Ez egy általános elv, hogy ne szakítsuk meg a szolgáltatást, és ne töltsük be ugyanazokkal a kérésekkel. Az okos kliens általában tud erről, és gyorsítótárazza.
Például itt valami megváltozott. Van valamilyen alkalmazás. Új vezetőt választottak, aki például az írási műveletek feldolgozásáért felel. És szeretnénk reprodukálni az adatokat. Az egyik megoldás az, hogy hurokba helyezzük. És folyamatosan megkérdőjelezzük szolgáltatásunkat – változott valami? A második lehetőség az optimálisabb. Ez egy figyelési mechanizmus, amely lehetővé teszi, hogy értesítse az ügyfeleket, ha valami megváltozott. Ez az erőforrások szempontjából olcsóbb módszer, és kényelmesebb az ügyfelek számára.
Az ügyfél az a felhasználó, aki a ZooKeeper-t használja.
A szerver maga a ZooKeeper folyamat.
A Znode a legfontosabb dolog a ZooKeeperben. Az összes znode-ot a ZooKeeper a memóriában tárolja, és hierarchikus diagramba, fa formájában rendezi őket.
Kétféle művelet létezik. Az első a frissítés/írás, amikor valamilyen művelet megváltoztatja a fánk állapotát. A fa gyakori.
És lehetséges, hogy az ügyfél nem teljesít egy kérést, és megszakad a kapcsolat, de létrehozhat egy munkamenetet, amelyen keresztül kapcsolatba lép a ZooKeeperrel.
A ZooKeeper adatmodellje egy fájlrendszerhez hasonlít. Van egy szabványos gyökér, majd úgy mentünk végig, mintha a gyökérből induló könyvtárakon mentünk volna keresztül. És akkor az első szint, a második szint katalógusa. Ez mind znodes.
Minden znode tárolhat néhány adatot, általában nem túl nagy, például 10 kilobájtot. És minden znode-nak bizonyos számú gyermeke lehet.
A znodok többféle típusban kaphatók. Létrehozhatók. A znode létrehozásakor pedig megadjuk, hogy melyik típushoz tartozzon.
Két típusa van. Az első az efemer zászló. A Znode egy munkameneten belül él. Például az ügyfél munkamenetet hozott létre. És amíg ez a munkamenet él, addig létezik. Erre azért van szükség, hogy ne jöjjön létre valami felesleges. Ez olyan pillanatokban is megfelelő, amikor fontos számunkra, hogy egy munkameneten belül adatprimitíveket tároljunk.
A második típus a szekvenciális zászló. Növeli a számlálót a znode felé vezető úton. Például volt egy könyvtárunk az 1_5 alkalmazással. És amikor létrehoztuk az első csomópontot, az p_1-et kapott, a második - p_2. És amikor ezt a metódust minden alkalommal meghívjuk, a teljes elérési utat átadjuk, csak az út egy részét jelezve, és ez a szám automatikusan növekszik, mivel a csomópont típusát jelezzük - szekvenciális.
Rendszeres znode. Mindig élni fog, és az lesz a neve, amit mondunk neki.
Egy másik hasznos dolog az óra zászló. Ha telepítjük, akkor a kliens előfizethet bizonyos eseményekre egy adott csomóponthoz. Később egy példával mutatom meg, hogyan kell ezt csinálni. A ZooKeeper maga értesíti az ügyfelet, hogy a csomóponton lévő adatok megváltoztak. Az értesítések azonban nem garantálják, hogy új adatok érkeztek. Egyszerűen azt mondják, hogy valami megváltozott, így később is össze kell hasonlítani az adatokat külön hívásokkal.
És ahogy már mondtam, az adatok sorrendjét kilobájtok határozzák meg. Nem kell ott nagy szöveges adatokat tárolni, mert ez nem adatbázis, hanem akciókoordinációs szerver.
Mesélek egy kicsit a foglalkozásokról. Ha több szerverünk van, akkor a munkamenet azonosító segítségével transzparens módon tudunk szerverről szerverre mozogni. Elég kényelmes.
Minden munkamenetnek van valamilyen időkorlátja. A munkamenetet az határozza meg, hogy az ügyfél küld-e valamit a kiszolgálónak a munkamenet során. Ha nem küldött semmit az időkorlát alatt, akkor a munkamenet megszakad, vagy az ügyfél maga is bezárhatja.
Nem rendelkezik annyi funkcióval, de ezzel az API-val különféle dolgokat tehet. Az általunk létrehozott hívás létrehoz egy znode-ot, és három paramétert vesz fel. Ez a znode elérési útja, és a gyökértől kezdve teljes egészében meg kell adni. És ez is néhány adat, amelyet át akarunk vinni oda. És a zászló típusa. És a létrehozás után visszaadja az utat a znode-hoz.
Másodszor, törölheti. A trükk itt az, hogy a második paraméter a znode elérési útja mellett megadhatja a verziót. Ennek megfelelően az a znode törlődik, ha az általunk átvitt verziója megegyezik a ténylegesen létezővel.
Ha nem akarjuk ellenőrizni ezt a verziót, akkor egyszerűen átadjuk a "-1" argumentumot.
Harmadszor, ellenőrzi a znode létezését. Igaz értéket ad vissza, ha a csomópont létezik, hamis értéket egyébként.
Ezután megjelenik a zászló óra, amely lehetővé teszi ennek a csomópontnak a figyelését.
Ezt a jelzőt még nem létező csomóponton is beállíthatja, és értesítést kaphat, amikor megjelenik. Ez is hasznos lehet.
Van még néhány kihívás getData. Nyilvánvaló, hogy a znode-on keresztül tudunk adatokat fogadni. Használhatja a zászlós órát is. Ebben az esetben nem települ, ha nincs csomópont. Ezért meg kell értenie, hogy létezik, majd adatokat kell fogadnia.
Van még SetData. Itt átadjuk a verziót. És ha ezt továbbadjuk, akkor egy bizonyos verzió znode-ján az adatok frissülnek.
Az ellenőrzés kizárásához megadhatja a "-1" értéket is.
Egy másik hasznos módszer az getChildren. Kaphatunk egy listát is az összes hozzá tartozó znode-ról. Ezt a zászlóóra beállításával tudjuk nyomon követni.
És módszer szinkronizálni lehetővé teszi az összes módosítás egyidejű elküldését, ezzel biztosítva, hogy azok mentésre kerülnek, és minden adat teljesen megváltozott.
Ha a szokásos programozással vonunk analógiákat, akkor amikor olyan metódusokat használunk, mint például az írás, amely valamit a lemezre ír, és miután az visszaküldi Önnek a választ, nincs garancia arra, hogy az adatokat lemezre írta. És még akkor is, ha az operációs rendszer biztos abban, hogy mindent megírt, magában a lemezen vannak olyan mechanizmusok, amelyek során a folyamat pufferrétegeken megy keresztül, és csak ezután kerül az adatok a lemezre.
Többnyire aszinkron hívásokat használnak. Ez lehetővé teszi az ügyfél számára, hogy párhuzamosan dolgozzon a különböző kérésekkel. Használhatja a szinkron megközelítést, de kevésbé produktív.
A két művelet, amiről beszéltünk, a frissítés/írás, ami megváltoztatja az adatokat. Ezek a Create, setData, sync, delete. Az olvasás pedig létezik, getData, getChildren.
Most néhány példa arra, hogyan készíthet primitíveket az elosztott rendszerben való munkavégzéshez. Például valaminek a konfigurációjával kapcsolatban. Új dolgozó jelent meg. Hozzáadtuk a gépet és elindítottuk a folyamatot. És ott van a következő három kérdés. Hogyan kérdezi le a ZooKeepert a konfigurációhoz? És ha meg akarjuk változtatni a konfigurációt, hogyan változtassuk meg? És miután megváltoztattuk, hogyan kapják meg azok a munkások, akiknek voltunk?
A ZooKeeper ezt viszonylag egyszerűvé teszi. Például ott van a znode-fánk. Itt van egy csomópont az alkalmazásunkhoz, ebben hozunk létre egy további csomópontot, amely a konfiguráció adatait tartalmazza. Ezek lehetnek különálló paraméterek, vagy nem. Mivel a méret kicsi, a konfiguráció mérete is általában kicsi, így itt el lehet tárolni.
Ön a módszert használja getData hogy a csomópontból megkapja a dolgozó konfigurációját. Állítsa igazra. Ha ez a csomópont valamilyen oknál fogva nem létezik, akkor értesítést kapunk róla, amikor megjelenik, vagy amikor megváltozik. Ha tudni akarjuk, hogy valami megváltozott, akkor igazítjuk. És ha ebben a csomópontban megváltoznak az adatok, akkor tudni fogunk róla.
SetData. Beállítjuk az adatokat, állítsuk be a „-1”-et, azaz nem ellenőrizzük a verziót, feltételezzük, hogy mindig egy konfigurációnk van, nem kell sok konfigurációt tárolnunk. Ha sokat kell tárolnia, akkor egy újabb szintet kell hozzáadnia. Itt úgy gondoljuk, hogy csak egy van, ezért csak a legújabbat frissítjük, így nem ellenőrizzük a verziót. Ebben a pillanatban minden olyan ügyfél, aki korábban előfizetett, értesítést kap arról, hogy valami megváltozott ebben a csomópontban. És miután megkapták, újra kell kérniük az adatokat. Az értesítés az, hogy magát az adatot nem kapják meg, csak a változásokról szóló értesítést. Ezt követően új adatokat kell kérniük.
A második lehetőség a primitív használatára csoporttagság. Van egy elosztott alkalmazásunk, van egy csomó dolgozó, és szeretnénk megérteni, hogy mindegyik a helyén van. Ezért regisztrálniuk kell magukat, hogy az alkalmazásunkban dolgoznak. És azt is szeretnénk megtudni, akár a Mester folyamatból, akár valahol máshol, az összes aktív dolgozóról, akik jelenleg vannak.
Hogyan csináljuk ezt? Az alkalmazáshoz létrehozunk egy dolgozó csomópontot, és hozzáadunk egy alszintet a Create metódussal. Hiba van a dián. Itt kell egymás utáni adja meg, akkor az összes dolgozó egyenként jön létre. És az alkalmazás, amely minden adatot lekér ennek a csomópontnak a gyermekeiről, megkapja az összes létező aktív dolgozót.
Ez egy szörnyű megvalósítása annak, hogyan lehet ezt megtenni Java kódban. Kezdjük a végéről, a fő módszerrel. Ez a mi osztályunk, hozzuk létre a metódusát. Első argumentumként a hostot használjuk, ahol kapcsolódunk, azaz argumentumként állítjuk be. A második érv pedig a csoport neve.
Hogyan történik a kapcsolat? Ez egy egyszerű példa a használt API-ra. Itt minden viszonylag egyszerű. Van egy standard osztályú ZooKeeper. Házigazdákat adunk át neki. És állítsa be például az időtúllépést 5 másodpercre. És van egy connectSignal nevű tagunk. Lényegében egy csoportot hozunk létre a továbbított útvonal mentén. Nem írunk oda adatokat, bár lehetett volna írni valamit. És a csomópont itt állandó típusú. Lényegében ez egy közönséges szabályos csomópont, amely mindig létezni fog. Itt jön létre a munkamenet. Ez maga az ügyfél megvalósítása. Ügyfelünk időszakos üzeneteket küld, jelezve, hogy a munkamenet él. És amikor befejezzük a foglalkozást, bezárjuk, és ennyi, az ülés leesik. Ez arra az esetre van, ha valami leesne nekünk, hogy a ZooKeeper megtudja, és megszakítja a munkamenetet.
Hogyan lehet zárolni egy erőforrást? Itt minden egy kicsit bonyolultabb. Van egy sor dolgozónk, van néhány erőforrás, amit le akarunk zárni. Ehhez külön csomópontot hozunk létre, például lock1 néven. Ha sikerült létrehozni, akkor itt kaptunk egy zárat. Ha pedig nem tudtuk létrehozni, akkor a worker innen próbálja megszerezni a getData-t, és mivel a csomópont már létrejött, akkor ide teszünk egy figyelőt, és abban a pillanatban, amikor ennek a csomópontnak az állapota megváltozik, tudni fogunk róla. És megpróbálhatunk időt hagyni az újraalkotásra. Ha ezt a csomópontot vettük, ezt a zárat vettük, akkor miután már nincs szükségünk a zárra, elhagyjuk, mivel a csomópont csak a munkameneten belül létezik. Ennek megfelelően el fog tűnni. Egy másik ügyfél pedig egy másik munkamenet keretein belül felveheti a zárolást ezen a csomóponton, vagy inkább értesítést kap, hogy valami megváltozott, és időben megpróbálhatja megtenni.
Egy másik példa arra, hogyan választhatja ki a fő vezetőt. Ez egy kicsit bonyolultabb, de viszonylag egyszerű is. Mi folyik itt? Van egy fő csomópont, amely az összes dolgozót összesíti. Megpróbálunk adatokat szerezni a vezetőről. Ha ez sikeresen megtörtént, azaz kaptunk néhány adatot, akkor a dolgozónk követni kezdi ezt a vezetőt. Úgy véli, hogy már van vezető.
Ha a vezető valamilyen okból meghalt, például leesett, akkor megpróbálunk új vezetőt létrehozni. És ha sikerül, akkor a dolgozónk lesz a vezető. És ha valakinek ebben a pillanatban sikerült új vezetőt létrehoznia, akkor megpróbáljuk megérteni, ki az, és utána követni őt.
Itt jön létre az úgynevezett csordaeffektus, vagyis a csordaeffektus, mert ha egy vezér meghal, az lesz a vezér, aki időben első.
Az erőforrás rögzítésekor megpróbálhat egy kicsit más megközelítést alkalmazni, ami a következő. Például egy zárat szeretnénk kapni, de a hert hatás nélkül. Ez abból fog állni, hogy az alkalmazásunk egy már létező, zárral ellátott csomópont összes csomópontazonosítójának listáját kéri. És ha korábban az a csomópont, amelyhez zárolást hoztunk létre, a legkisebb a kapott halmaz közül, akkor ez azt jelenti, hogy rögzítettük a zárat. Ellenőrizzük, hogy megkaptuk-e a zárat. Ellenőrzésként lesz egy feltétel, hogy az új zár létrehozásakor kapott azonosító minimális legyen. És ha megkaptuk, akkor dolgozunk tovább.
Ha van egy bizonyos azonosító, amely kisebb, mint a zárunk, akkor figyelőt helyezünk erre az eseményre, és várjuk az értesítést, amíg valami megváltozik. Vagyis megkaptuk ezt a zárat. És amíg le nem esik, addig nem leszünk a minimum id és nem kapjuk meg a minimális zárat, és így tudunk majd bejelentkezni. És ha ez a feltétel nem teljesül, akkor azonnal idemegyünk és megpróbáljuk újra megszerezni ezt a zárat, mert ez idő alatt valami megváltozhatott.
Miből áll a ZooKeeper? 4 fő dolog van. Ez feldolgozási folyamat - Kérelem. És a ZooKeeper Atomic Broadcast is. Van egy véglegesítési napló, amely minden műveletet rögzít. És maga az In-memory Replicated DB, vagyis maga az adatbázis, ahol ez a teljes fa tárolva van.
Érdemes megjegyezni, hogy minden írási művelet a Request Processoron megy keresztül. Az olvasási műveletek pedig közvetlenül az In-memory adatbázisba kerülnek.
Maga az adatbázis teljesen replikált. A ZooKeeper minden példánya tárolja az adatok teljes másolatát.
Az adatbázis összeomlás utáni visszaállításához van egy véglegesítési napló. Az általános gyakorlat az, hogy mielőtt az adatok a memóriába kerülnének, oda írják, hogy ha összeomlik, akkor ez a napló lejátszható és visszaállítható a rendszer állapota. És az adatbázis időszakos pillanatfelvételeit is használják.
A ZooKeeper Atomic Broadcast egy olyan dolog, amelyet replikált adatok karbantartására használnak.
A ZAB belsőleg kiválaszt egy vezetőt a ZooKeeper csomópont szempontjából. Más csomópontok a követőivé válnak, és bizonyos lépéseket várnak tőle. Ha beérkeznek hozzájuk a bejegyzések, mindet továbbítják a vezetőnek. Először egy írási műveletet hajt végre, majd üzenetet küld követőinek arról, hogy mi változott. Ezt tulajdonképpen atomosan kell végrehajtani, vagyis az egész felvételi és sugárzási műveletét atomosan kell végrehajtani, ezzel garantálva az adatok konzisztenciáját.
Csak az írási kéréseket dolgozza fel. Fő feladata, hogy a műveletet tranzakciós frissítéssé alakítsa. Ez egy speciálisan generált kérés.
És itt érdemes megjegyezni, hogy ugyanazon művelet frissítéseinek idempotenciája garantált. Ami? Ennek a dolognak, ha kétszer hajtjuk végre, ugyanaz lesz az állapota, azaz maga a kérés nem változik. Ezt pedig azért kell megtenni, hogy összeomlás esetén újraindíthassuk a műveletet, ezzel visszagörgetve a pillanatnyilag kiesett változtatásokat. Ebben az esetben a rendszer állapota azonos lesz, vagyis nem fordulhat elő, hogy ugyanazon, például frissítési folyamatok sorozata a rendszer különböző végső állapotaihoz vezetett.
Forrás: will.com