K: Egy szolgáltatási szerver, egy adatbázis, művelet: kérdezd le a felhasználó aktuális egyenlegét, levond a jelenlegi egyenlegből 3%-ot kezelési díjként
szinkronizált
zár
DB zár
K: Két szolgáltatási szerver, egy adatbázis, működés: kérdezze le a felhasználó aktuális egyenlegét, levonja a jelenlegi egyenleg 3%-át a kezelési díjként
Elosztott zárak
Milyen elosztott zárra van szükségünk?
Biztosíthatja, hogy egy elosztott alkalmazásklaszterben ugyanazt a módszert egyszerre csak egyetlen szál hajtsa végre egyetlen gépen.
Ha ez a zár visszatérő zár (kerüld el a holtzárakat)
Ez a zár a legjobb, ha blokkoló zár (gondold át, hogy ezt a vállalkozásod igényeinek megfelelően szeretnéd-e)
Ez a zár a legjobb, ha tisztességes zár (gondold át, hogy ezt szeretnéd-e az üzleti igények szerint)
Nagyon elérhető felvásárlási és feloldó zár funkciók is rendelkezésre állnak
A felvásárlási és feloldó zárak teljesítménye jobb
1. Adatbázisok alapján elosztott zárak
Táblázatalapú megvalósítások alapján elosztott zárak
Amikor egy metódust le akarunk zárni, hajtsuk végre a következő SQL-t:
insert in methodLock(method_name,desc) értékek ('method_name','desc')
Mivel egyediségi korlátozást állítottunk be az method_name-re, ha egyszerre több kérést küldenek be az adatbázisba, az adatbázis biztosítja, hogy csak egy művelet sikeres, így feltételezhetjük, hogy a szál, amely sikeresen megkapta a metóduszárolást, és képes végrehajtani a metódus törzstartalmát.
Amikor a metódus végrehajtása alatt a zárolást szeretnéd feloldani, a következő SQL rendszert kell végrehajtani:
töröld a methodLock-ból, ahol method_name ='method_name'
Ez az egyszerű megvalósítás a következő problémákkal jár:
- Ez a zár az adatbázis elérhetőségétől függ, amely egyetlen pontból áll, és az üzleti rendszer elérhetetlenné válik, miután az adatbázis leáll.
- Ennek a zárnak nincs lejárati ideje, és ha a feloldás meghiúsul, a zárolási rekord az adatbázisban marad, és más szálak már nem tudják megszerezni a zárolást.
- Ez a zár csak nem blokkolható, mert az adat beillesztési művelete közvetlenül hibát jelent, ha a belépés meghibázik. Azok a szálak, amelyek nem szereznek zárat, nem lépnek be a sorba, és újra el kell indítaniuk a zár beszerzési műveletet, hogy újra megkapják a zárat.
- A zár nem visszatérő, és ugyanaz a szál nem tudja újra megszerezni a zárat, amíg ki nem engedik. Mert az adatokban lévő adatok már léteznek.
- Ez a zár igazságtalan, és minden szál, ami a zárra vár, szerencsével verseng a zárért.
Természetesen a fent említett problémákat más módokon is meg lehet oldani.
- Az adatbázis egyetlen pont? Két adatbázist építs, és az adatok mindkét irányban szinkronizálódnak. Ha lezártad, gyorsan válts a biztonsági mentési könyvtárba.
- Nincs lejárati idő? Csak csinálj egy ütemezett feladatot, hogy rendszeres időközönként tisztítsd meg az időkérési adatokat az adatbázisban.
- Nem blokkoló? Csinálj egy időhurkot, amíg a betétek sikeressé nem válik, majd vissza nem tér sikerre.
- Nem visszatér? Adj egy mezőt az adatbázis táblához, hogy rögzítsd a gép gépének és száladatainak rögzítését, majd legközelebb, amikor megkapod a zárolást, először kérdezd meg az adatbázist, ha a jelenlegi gép hászadat- és száladatai megtalálhatók az adatbázisban, közvetlenül hozzá rendelheted a zárolást.
- Igazságtalan? Készíts egy másik köztes táblázatot, amely rögzíti az összes zárra váró szálat, és rendezze őket a létrehozási idő szerint, így csak az első létrehozott szál szerezheti meg a zárat
Kizárólagos zárak alapján elosztott zárak
Az adattáblában lévő rekordok hozzáadása és törlése mellett elosztott zárak is megvalósíthatók az adatokhoz tartozó zárak segítségével.
Mi is használjuk az imént létrehozott adatbázis-táblát. Az elosztott zárak exkluzív zárakon keresztül valósíthatók meg adatbázisokban. A MySQL alapú InnoDB motor a következő módszereket képes használni a lock-up műveletek megvalósítására:
Ha frissítéshez hozzáadsz egy lekérdezési utasítás után, az adatbázis exkluzív zárolást ad az adatbázis táblájához a lekérdezési folyamat során. Ha exkluzív zárat adnak egy rekordba, más szálak már nem tudnak exkluzív zárolót hozzáadni a lemezhez azon a vonalon.
Gondolhatjuk, hogy az exkluzív zárat megszerző szál megszerezheti az elosztott zárat, és amikor a zárat megszerzik, a módszer üzleti logikája végrehajtható, majd a következő módszerekkel feloldható:
public void unlock(){ connection.commit(); }
a connection.commit(); A zár feloldásának művelete.
Ez a módszer hatékonyan megoldhatja a fent említett problémákat, amelyek a zár feloldásának és a zár blokkolásának képtelenségével kapcsolatosak.
Zárak blokkolása? A for update utasítás azonnal visszatér a sikeres végrehajtás után, és blokkolva marad, amíg sikerül.
A szolgáltatás leállt a zárás után, nem lehet elengedni? Így az adatbázis önállóan engedi el a zárolást, miután a szolgáltatás leáll.
Ugyanakkor ez még mindig nem oldja meg közvetlenül az adatbázis egyetlen pont, a reentrancia és a tisztességes zárolás problémáját.
Összefoglalva, hogyan lehet az adatbázist elosztott zárak megvalósítására, amelyek mindkettő támaszkod az adatbázisban: az egyik a táblában lévő rekordok alapján határozzuk meg, hogy van-e zárolódás, a másik pedig elosztott zárolásokat az adatbázis exkluzív zárolásával valósítunk meg.
Az adatbázisokban elosztott zárolás előnyei
Közvetlenül az adatbázis segítségével könnyen érthető.
Az elosztott zárak adatbázisokban történő bevezetésének hátrányai
Számos probléma lesz, és az egész megoldás egyre összetettebbé válik a probléma megoldásának folyamatában.
Az adatbázis működtetése bizonyos többletköltségeket igényel, és teljesítményproblémákat is figyelembe kell venni.
2. Gyorsítótár alapú elosztott zárak
Az adatbázis-alapú elosztott zárolási megoldáshoz képest a gyorsítótár-alapú megvalósítás jobban teljesít a teljesítmény szempontjából.
Jelenleg számos érett gyorsítótározó termék létezik, például a Redis, a memcached stb. Itt példaként vesszük a Redis-t, hogy elemezzük a cache használatával elosztott zárak megvalósítására.
Számos kapcsolódó cikk található az interneten a Redis-alapú elosztott zárok megvalósításáról, és a fő megvalósítási módszer a Jedis.setNX módszer.
A fenti megvalósítással több probléma is felmerül:
1. Egypontos probléma.
2. Ennek a zárnak nincs lejárati ideje, ha a feloldás meghiúsul, a zárolás rekordja állandóan redis állapotban lesz, és más szálak már nem tudják megszerezni a zárolást.
3. Ez a zár csak nem blokkoló lehet, és közvetlenül visszatér, függetlenül a sikertől vagy kudarctól.
4. Ez a zár nem visszatérő, miután egy szál megszerzi a zárat, nem tudja újra megszerezni a zárat, mielőtt kiengedné a zárat, mert a használt kulcs már létezik a redisben. a setNX műveletek már nem hajthatók le.
5. Ez a zár igazságtalan, minden várakozó szál egyszerre indítja el a setNX műveleteket, és a szerencsés szálak is képesek lezárni.
Természetesen vannak megoldások is.
- Manapság a hagyományos gyorsítótározó szolgáltatások támogatják a klaszterek telepítését az egypontos problémák megoldására klaszterezéssel.
- Nincs lejárati idő? A redis setExpire módszere támogatja a bejövő lejárati időt, és az adatok automatikusan törlődnek az idő elérése után.
- Nem blokkoló? miközben ismételten kivégezték.
- Nem lehetséges újra belépni? Miután egy szál megszerezte a zárolást, mentsd el a jelenlegi hosztinformációt és szál információt, és ellenőrizd, hogy te vagy a jelenlegi zár tulajdonosa, mielőtt legközelebb megszerzed.
- Igazságtalan? Tedd be az összes várakozó szálat egy sorba, mielőtt egy szál zárolni fog, majd először be, elsőként ki-be ment.
A redis klaszter szinkronizálási politikája időigényes, és előfordulhat, hogy az A szál zárolódik az NX sikeres beállítása után, de ez az érték nem frissült arra a szerverre, ahol a B szál végrehajtja a setNX-et, ami párhuzamossági problémákat okozhat.
Salvatore Sanfilippo a redis szerzője javasolta a Redlock algoritmust, amely egy elosztott zárkezelést (DLM) valósít meg, amely biztonságosabb és megbízhatóbb, mint egyetlen csomópont.
A Redlock algoritmus feltételezi, hogy N Redis csomópont létezik, amelyek egymástól függetlenek, általában N=5-re vannak beállítva, és ezek az N csomópont különböző gépeken futnak a fizikai függetlenség fenntartása érdekében.
Az algoritmus lépései a következők:
1. Az ügyfél milliszekundumokban kapja meg az aktuális időt.
2. Az ügyfél megpróbálja megszerezni N csomópont zárát (minden csomópont ugyanúgy kapja meg a zárat, mint a korábban említett cache zár), és N csomópont ugyanazzal a kulmánnyal és értékkel kapja meg a zárat. Az ügyfélnek be kell állítania az interfész hozzáférési időkorlátját, és az interfész időkorlátjának sokkal rövidebbnek kell lennie, mint a zár időkorlátja, például a zár automatikus kiengedési ideje 10 másodperc, majd az interfész időkorlátja körülbelül 5-50 ms lesz. Ez lehetővé teszi, hogy minél hamarabb időlezárj egy redis csomóponthoz való hozzáférés után, és csökkented a zár normál használatát.
3. Az ügyfél kiszámítja, mennyi időbe telik a zár megszerzése, az 1. lépésben elért időt a jelenlegi idővel levonva, csak akkor számít ki, ha a zár több mint 3 csomópontot szerzett, és a zár megszerzésének ideje kevesebb, mint a zár időkorlátja, akkor megkapja az elosztott zárat.
4. Az ügyfél ideje, amíg a zár megszerzi, a beállított zár időkorlátja mínusz a 3. lépésben kiszámított zár megszerzésére fordított idő.
5. Ha az ügyfél nem tudja megszerezni a zárolást, az ügyfél sorra törli az összes zárat.
A Redlock algoritmus segítségével garantálható, hogy az elosztott zárolás szolgáltatás még mindig működik, ha akár 2 csomópontot is csatlakoztatnak, ami jelentősen javítja a rendelkezésre állást a korábbi adatbázis-zároláshoz és gyorsítótár-zárhoz képest.
Egy elosztott szakértő azonban írt egy cikket "Hogyan csináljuk elosztott zárolást", amelyben megkérdőjelezte a Redlock helyességét.
A szakértő megemlítette, hogy két szempontot kell figyelembe venni az elosztott zárak esetében: a teljesítményt és a helyességet.
Ha nagy teljesítményű elosztott zárat használsz, és a helyesség nem szükséges, akkor gyorsítótár zárolás elegendő.
Ha nagyon megbízható, elosztott zárat használsz, akkor szigorú megbízhatósági problémákat kell figyelembe venni. A Redlock viszont nem felel meg a helyességnek. Miért ne? A szakértők több szempontot is felsorolnak.
Manapság sok programozási nyelv használ virtuális gépeket GC funkciókkal, Full GC-ben a program leállítja a GC feldolgozását, néha a Full GC hosszú időbe telik, és még a program is néhány perc késleltetést mutat, a cikk például HBase, HBase, néha GC néhány percre, ami miatt a bérleti szerződés időlejár a lejárás. Például az alábbi ábrán az 1-es kliens zárolást kap, és éppen egy megosztott erőforrást dolgozik fel, és amikor éppen feldolgozni készül egy megosztott erőforrást, a teljes GC addig érvényesül, amíg a zár lejár. Így a 2-es ügyfél újra megkapja a zárolást, és elkezd dolgozni a megosztott erőforráson. Amikor a 2-es kliens feldolgozást végez, az 1-es kliens teljes GC-t teljesít, és elkezdi a megosztott erőforrásokat feldolgozni, így mindkét kliens megosztott erőforrásokat dolgoz fel.
A szakértők megoldást adtak fel, ahogy az alábbi ábrán látható: úgy néz ki, mint az MVCC, hozz egy tokent a zároláshoz, token a verzió fogalma, minden alkalommal, amikor a műveleti zár befejeződik, a token hozzáadódik 1, hozza be a tokent a megosztott erőforrások feldolgozásakor, csak a megadott token verzió tudja kezelni a megosztott erőforrást.
Ezután a szakértő azt is mondta, hogy az algoritmus helyi időre támaszkodik, és hogy a Redis a kulcslejárat kezelése során a getTimeOfDay módszerre támaszkodik az idő megszerzéséhez, nem pedig a monoton órajelhez, ami időbeli pontatlanságokhoz vezet. Például egy helyzetben két kliens 1 és 2 kliens 5 redis csomóponttal rendelkezik (A, B, C, D és E).
1. Az 1. ügyfél sikeresen megszerzi a zárat A-tól, B-től és C-től, és megszerzi a zár hálózati időtúllépését D-től és E-től.
2. C csomópont órajere pontatlan, ami a zárolás időtúllépését okozza.
3. a 2-es ügyfél sikeresen megszerzi a zárat C-től, D-től és E-től, és megkapja a zár hálózati időkivonást A-tól és B-től.
4. Így mind az 1-es, mind a 2-es ügyfél zárol.
Összefoglalva a két pontot, amit a szakértők mondanak Redlock elérhetetlenségéről:
1. GC és más helyzetek bármikor előfordulhatnak, ami miatt az ügyfél zárolást kap, és a feldolgozási időkorlát miatt egy másik kliens kapja meg a zárat. A szakértők megoldást is kínáltak az önnövelő tokenek használatára.
2. Az algoritmus helyi időre támaszkodik, és az óra pontatlan, így két kliens egyszerre kap zárolást.
Ezért a szakértők következtetése az, hogy a Redlock csak a korlátolt hálózati késleltetésben, a programmegállásban és a korlátozott órajel hibatartományban működik, de e három forgatókönyv határai nem igazolhatók, ezért a szakértők nem javasolják a Redlock használatát. Magas pontossági követelményeket igénylő helyzeteknél a szakértők a Zookeeper-t ajánlják, amelyről később beszélünk a Zookeeper elosztott zárként való használatáról.
Válasz a Redis szerzőjétől
A Redis szerzője válaszul blogot írt a szakértő cikkének megtekintése után. A szerző udvariasan megköszönte a szakértőnek, majd kifejezte nem egyet a szakértő véleményével.
A REDIS szerző vitája a tokenek használatáról a zár időkilépési problémájának megoldására az alábbi öt pontban foglalható össze:
Az 1. pont, az elosztott zárak használata általában abban van, hogy nincs más módja a megosztott erőforrások irányításának, a szakértők tokeneket használnak a megosztott erőforrások feldolgozásának biztosítására, így nincs szükség elosztott zárakra.
2. pont: Token generálásához, hogy biztosítsuk a különböző ügyfelek által megszerzett tokenek megbízhatóságát, a tokeneket generáló szolgáltatásnak továbbra is elosztott zárakra van szüksége a szolgáltatás megbízhatósága érdekében.
3. pont: ahogy a szakértők szerint az önnövelő tokenek esetében a redis szerzője úgy véli, hogy ez teljesen felesleges, minden kliens generálhat egy egyedi uuid-et tokenként, és beállíthatja a megosztott erőforrást olyan állapotra, amit csak az uuid-vel rendelkező kliens tud kezelni, így más ügyfelek nem dolgozhatják fel a megosztott erőforrást, amíg a zárat megszerző kliens fel nem engedi a zárat.
Ahogy a fenti ábrán látható, ha a 34-es token kliense GC-t küld az írás során, és a zár időlejárását okozza, egy másik kliens megkaphatja a 35-ös token zárját, és újra elkezdhet írni, ami zár ütközéshez vezethet. Ezért a tokenek sorrendje nem kombinálható megosztott erőforrásokkal.
Az 5. pont szerint a redis szerzője úgy véli, hogy a legtöbb esetben elosztott zárakat használnak a frissítési problémák kezelésére nem tranzakciós helyzetekben. A szerzőnek azt kell mondania, hogy vannak olyan helyzetek, amikor nehéz a tokeneket kombinálni a megosztott erőforrások kezelésére, ezért a zárakra kell támaszkodni az erőforrások lezárásához és feldolgozásához.
Egy másik óraprobléma, amelyről a szakértők beszélnek, a Redis szerzői is magyarázatot adnak. Ha a zár megszerzéséhez szükséges idő túl hosszú és meghaladja az alapértelmezett időtúli időt, akkor az ügyfél jelenleg nem tudja megszerezni a zárat, és szakértők nem javasolnak példákat.
Személyes érzések
Az első probléma, amit összefoglalok, hogy miután egy kliens elosztott zárat szerzett, a zár egy időkorlát után feloldódhat az ügyfél feldolgozása során. Korábban, amikor az adatbázis zárolása által 2 perces időkorlátról beszéltünk, ha egy feladat több mint 2 percig foglal el egy megbízási zárat, akkor a másik kereskedési központ megszerezheti ezt a megbízási zárat, így a két kereskedési központ egyszerre dolgozhatja fel ugyanazt a megbízást. Normál körülmények között a feladat másodpercek alatt feldolgozásra kerül, de néha az RPC kéréshez való csatlakozással beállított időkilépés túl hosszú, és több ilyen időkérés is van egy feladatban, akkor valószínű, hogy az automatikus feloldási idő túllép. Ha java-ban írunk, lehet, hogy a középen Full GC van, így miután a zár kioldódik a zár időkorlátja után, az ügyfél nem érzékelheti azt, ami nagyon komoly dolog. Nem hiszem, hogy ez magával a zárral lenne gond, amíg bármely fent említett elosztott zár rendelkezik az időtúli felszabadítás jellemzőivel, ilyen probléma előfordul. Ha a zárolás időtúllépését használod, az ügyfélnek be kell állítania a zár időkorlátját, és ennek megfelelően kell cselekednie, ahelyett, hogy tovább dolgozná a megosztott erőforrást. A Redlock algoritmusa visszaadja azt a zárolási időt, amelyet az ügyfél elfoglalhat, miután megszerezte a zárat, és ezt az időt a feladat megállításához kell feldolgoznia.
A második probléma, hogy a megosztott szakértők nem értik a Redlockot. A Redlock egyik kulcsfontosságú jellemzője, hogy a zár megszerzésének ideje az alapértelmezett időkérés összesen az idő, ami leszámítva a zár megszerzéséhez szükséges idő, így az ügyfél feldolgozásához szükséges idő relatív idő, függetlenül a helyi időtől.
Ebből a szempontból Redlock helyessége biztos. A Redlock alapos elemzése: egy csomópont rediséhez képest a Redlock fő jellemzője a magasabb megbízhatóság, ami bizonyos helyzetekben fontos jellemző. De szerintem a Redlock túl sok pénzt költött a megbízhatóság elérésére.
- Először 5 csomópontot kell telepíteni, hogy a Redlock megbízhatóbb legyen.
- Ezután 5 csomópontot kell kérned a zároláshoz, és a Future módszerrel először egyszerre kérhetsz 5 csomópontot, majd összegyűjtheted a válasz eredményét, ami lerövidítheti a válaszidőt, de így is több időt vesz igénybe, mint egy egycsomópontos redis zár.
- Mivel az 5 csomópontból több mint 3-at kell szerezni, zárütközés alakulhat ki, vagyis mindenki 1-2 zárat szerzett, és ennek eredményeként senki sem tudja megszerezni a zárat, ezt a problémát a Redis szerzője kölcsönveszi a tutaj algoritmus lényegét, a véletlenszerű ütközésen keresztül jelentősen csökkenthető az ütközési idő, de ezt a problémát nem lehet nagyon jól elkerülni, különösen amikor a zárat először szerzik meg, így a zár megszerzésének időköltsége nő.
- Ha az 5 csomópontból kettő leáll, a zár elérhetősége jelentősen csökken, először is várnod kell, hogy a két leesett csomópont eredménye időlejárjon, mielőtt visszatérsz, és csak 3 csomópont van, és az ügyfélnek meg kell szereznie mindhárom csomópont zárlatait, hogy megkapja a zárolást, ami szintén nehezebb.
- Ha van hálózati partíció, akkor előfordulhat, hogy az ügyfél soha nem tudja elérni a zárolást.
Ennyi ok elemzése után úgy gondolom, hogy a Redlock problémájának legkritikusabb pontja az, hogy a Redlock megköveteli az ügyfeleket az írások konzisztenciájának biztosítására, és a backend 5 csomópontok teljesen függetlenek, és minden kliensnek kezelnie kell ezeket az 5 csomópontot. Ha 5 csomópont között van vezető, az ügyfél szinkronizálhatja a vezető adatait, amíg az ügyfél a vezetőtől szerezi meg a zárolást, így nem lesznek problémák olyan partíciók, időkorlátok vagy konfliktusok. Ezért az elosztott zárak helyességének biztosítása érdekében úgy gondolom, hogy egy erős konzisztenciájú elosztott koordinációs szolgáltatás használata jobban megoldhatja a problémát.
Újra felmerül a kérdés, mennyi ideig kellene beállítanom a lejárati időt? Az invalidálási idő beállítása túl rövid, és a zárolás automatikusan feloldódik, mielőtt a metódus végrehajtaná, akkor párhuzamos problémák lesznek. Ha túl sokáig tart, más szálaknak, amelyek zárolják, sokáig kell várniuk.
Ez a probléma az adatbázisok elosztott zárak megvalósításához való alkalmazásával is fennáll.
A jelenlegi általános megközelítés erre a problémára, hogy minden megszerzett zár számára rövid időkorlátot állítunk be, és indítunk egy szálat, hogy minden alkalommal frissítsék a zár időlejárási idejét, amikor az hamarosan eléri az időkérést. Fejezd be ezt a témát egy időben a zár feloldásával. Például a redisson, a redis hivatalos elosztott zár komponense, ezt a megoldást használja.
A gyorsítótározás előnyei elosztott zárak megvalósításához
Jó teljesítmény.
A gyorsítótározás elosztott zárak megvalósításának hátrányai
A megvalósítás túl felelősségteljes, túl sok tényezőt kell figyelembe venni.
Zookeeper implementáció alapján elosztott zárak
Osztott zárak az állatkertész ideiglenes megrendelt csomópontjai alapján.
Az általános elképzelés az, hogy amikor minden kliens zárol egy metódust, egy egyedi, azonnali rendezett csomópontot generálnak a megadott csomópont könyvtárában, amely megfelel a Zookeeper metódusának. A zárolás eldöntésének módja egyszerű: csak azt kell meghatározni, amelyiknek a legkisebb sorozatszáma a rendezett csomópontban. Amikor a zár feloldódik, egyszerűen töröld az azonnali csomópontot. Ugyanakkor elkerülheti a szolgáltatás leállása okozta holtpont problémáját, amelyeket nem lehet feloldani.
Nézzük meg, vajon az állattenhemész meg tudja-e oldani a korábban említett problémákat.
- A zár nem szabadul? A Zookeeper használata hatékonyan megoldhatja a zárak feloldásának problémáját, mert zár létrehozása során a kliens ideiglenes csomópontot hoz létre a ZK-ban, és amint a kliens megszerzi a zárolást és hirtelen leakasztja (a munkafolyamat-kapcsolat megszakad), akkor az ideiglenes csomópont automatikusan törlődik. Más ügyfelek újra megkaphatják a zárolást.
- Nem blokkoló zárak? Amint a csomópont megváltozik, a Zookeeper értesíti az ügyfelet, és az ügyfél ellenőrizheti, hogy az általa létrehozott csomópont a legkisebb szám-e a csomópontok között.
- Nem lehet újra belépni? Amikor a kliens létrehoz egy csomópontot, közvetlenül a jelenlegi kliens hosztinformációit és száladatait írja a csomóponthoz, és legközelebb, amikor a zárolást szeretnéd megszerezni, összehasonlíthatod a jelenlegi legkisebb csomópont adataival. Ha az információ megegyezik a sajátoddal, akkor közvetlenül megszerezheted a zárolást, és ha más, létrehozhatsz egy ideiglenes szekvenciális csomópontot, hogy részt vegyél a sorban.
Ismét felmerül a kérdés: tudjuk, hogy a Zookeeper-t klaszterekben kell telepíteni, lesznek-e adatszinkronizációs problémák, mint a Redis klaszterekben?
A Zookeeper egy elosztott komponens, amely garantálja a gyenge konzisztenciát, azaz végső konzisztenciát.
A Zookeeper egy Quorum Based Protocol nevű adatszinkronizációs protokollt alkalmaz. Ha a Zookeeper klaszterben van N Zookeeper szerver (N általában páratlan, 3 képes az adatmegbízhatóságot és magas olvasási és írási teljesítményt nyújtani, 5 pedig a legjobb egyensúlyt biztosítja az adatmegbízhatóság és az olvasás-írás teljesítménye között), akkor a felhasználó írási műveletét először szinkronizálják N/2 + 1 szerverekkel, majd visszaküldik a felhasználónak, ami a felhasználót sikeresen írni készteti. Az adatszinkronizációs protokoll, amely a Quorum Based Protocolon alapul, meghatározza, hogy a Zookeeper által támogatható erősség konzisztenciája van.
Egy elosztott környezetben az erős konzisztenciát elérő adattárolás gyakorlatilag nem létezik, és minden csomópontot szinkronban kell frissíteni, amikor egy csomópont adatait frissítik. Ez a szinkronizációs stratégia megjelenik a master-slave szinkron replikációs adatbázisban. Azonban ez a szinkronizációs stratégia túl nagy hatással van az írási teljesítményre, és ritkán fordul elő a gyakorlatban. Mivel a Zookeeper szinkronosan ír N/2+1 csomópontokat, és az N/2 csomópontok nem frissülnek szinkronon, a Zookeeper nem erősen következetes.
A felhasználó adatfrissítési művelete nem garantálja, hogy a következő olvasások felolvassák a frissített értéket, de végül konzisztenciát mutat. A konzisztencia feláldozása nem jelenti azt, hogy teljesen figyelmen kívül hagyjuk az adatok konzisztenciáját, különben az adatok kaotikusak, így bármilyen magas a rendszer elérhetősége, bármilyen jó is az eloszlás, semmi értéke nincs. A konzisztencia feláldozása csak azt jelenti, hogy a relációs adatbázisokban már nem szükséges erős konzisztencia, de amíg a rendszer végül képes konzisztensre elképzelni.
Egy egypontos kérdés? A Zookeeper használata hatékonyan megoldhat egyetlen pontot is, a ZK-t klaszterekben telepítik, amíg a klaszter gépeinek több mint fele túléli, a szolgáltatás a külvilág számára is elérhető.
Igazságossági problémák? A Zookeeper használata megoldhatja a fair lockok problémáját, a kliens által ZK-ban létrehozott ideiglenes csomópontok rendezettek, és minden alkalommal, amikor a zárat feloldják, ZK értesítheti a legkisebb csomópontot a zár megszerzésére, biztosítva a méltányosságot.
Ismét felmerül a kérdés: tudjuk, hogy a Zookeeper-t klaszterekben kell telepíteni, lesznek-e adatszinkronizációs problémák, mint a Redis klaszterekben?
A Zookeeper egy elosztott komponens, amely garantálja a gyenge konzisztenciát, azaz végső konzisztenciát.
A Zookeeper egy Quorum Based Protocol nevű adatszinkronizációs protokollt alkalmaz. Ha a Zookeeper klaszterben van N Zookeeper szerver (N általában páratlan, 3 képes az adatmegbízhatóságot és magas olvasási és írási teljesítményt nyújtani, 5 pedig a legjobb egyensúlyt biztosítja az adatmegbízhatóság és az olvasás-írás teljesítménye között), akkor a felhasználó írási műveletét először szinkronizálják N/2 + 1 szerverekkel, majd visszaküldik a felhasználónak, ami a felhasználót sikeresen írni készteti. Az adatszinkronizációs protokoll, amely a Quorum Based Protocolon alapul, meghatározza, hogy a Zookeeper által támogatható erősség konzisztenciája van.
Egy elosztott környezetben az erős konzisztenciát elérő adattárolás gyakorlatilag nem létezik, és minden csomópontot szinkronban kell frissíteni, amikor egy csomópont adatait frissítik. Ez a szinkronizációs stratégia megjelenik a master-slave szinkron replikációs adatbázisban. Azonban ez a szinkronizációs stratégia túl nagy hatással van az írási teljesítményre, és ritkán fordul elő a gyakorlatban. Mivel a Zookeeper szinkronosan ír N/2+1 csomópontokat, és az N/2 csomópontok nem frissülnek szinkronon, a Zookeeper nem erősen következetes.
A felhasználó adatfrissítési művelete nem garantálja, hogy a következő olvasások felolvassák a frissített értéket, de végül konzisztenciát mutat. A konzisztencia feláldozása nem jelenti azt, hogy teljesen figyelmen kívül hagyjuk az adatok konzisztenciáját, különben az adatok kaotikusak, így bármilyen magas a rendszer elérhetősége, bármilyen jó is az eloszlás, semmi értéke nincs. A konzisztencia feláldozása csak azt jelenti, hogy a relációs adatbázisokban már nem szükséges erős konzisztencia, de amíg a rendszer végül képes konzisztensre elképzelni.
Az, hogy az állatkert megfelel-e az oksági konzisztenciának, attól függ, hogyan programozzák az ügyfél.
Olyan gyakorlatok, amelyek nem felelnek meg az oksági konzisztenciának
- Az A folyamat egy adatdarabot ír az állatkerti /z fiókba, és sikeresen visszaadja
- Az A folyamat tájékoztatja a B folyamatot, hogy A módosította /z adatait
- B olvassa az állatkertész /z adatait
- Mivel a B-hez csatlakoztatott állatkerti őrök szervere nem lett frissítve A írott adataival, akkor B nem tudja olvasni A írott adatait
Olyan gyakorlatok, amelyek megfelelnek az oksági konzisztenciának
- A B folyamat meghallgatja az adatváltozásokat /z betűben a Zookeeperen
- Az A folyamat egy adatdarabot ír az Állatkertész /z-jére, és mielőtt az sikeresen visszatérne, az Állatkezelőnek hívnia kell a /z-re regisztrált hallgatót, és a vezető értesíti a B-t az adatváltozásról
- Miután a B folyamat eseményválasz módszerét választ kap, a megváltozott adatokat veszi át, így B biztosan meg tudja kapni a megváltoztatott értéket
- Az oksági konzisztencia itt a vezető és B közötti oksági konzisztenciát jelenti, vagyis a vezető értesíti az adatokat egy változásról
A második eseménymeghallgatási mechanizmus az a módszer is, amelyet a Zookeeper megfelelő programozásához kell használni, így a Zookeepernek meg kell felelnie az oksági konzisztenciának
Ezért, amikor elosztott zárokat valósítunk meg a Zookeeper alapján, alkalmazzuk az oksági konzisztencia kielégítését, vagyis a zárra váró szálak meghallgatják a Zookeeper zár változásait, és amikor a zárat feloldják, a Zookeeper értesíti azt a várakozó szálat, amely megfelel a fair lock feltételeknek.
Közvetlenül használhatod a Zookeeper harmadik féltől származó könyvtári klienst, amely egy reentrant lock szolgáltatást kapszulazik.
A ZK-val megvalósított elosztott zárak pontosan megfelelnek annak, amit a cikk elején elosztott zártól vártunk. Azonban nem az, és a Zookeeper által bevezetett elosztott zárnak valójában van hátránya, vagyis a teljesítmény nem feltétlenül olyan magas, mint a gyorsítótár szolgáltatásé. Mert minden alkalommal, amikor egy zár létrehozása és feloldása során azonnal létrejönnek és megsemmisülnek, hogy a zár funkcióját megvalósítsuk. A csomópontok létrehozása és törlése a ZK-ban csak a vezető szerveren keresztül történik, majd az adatokat minden követő géppel megosztják.
A Zookeeper használatának előnyei elosztott zárak megvalósításához
Hatékonyan oldják meg az egypontos problémákat, a nem visszatérési problémákat, a nem blokkolási problémákat és a zár feloldásának hibáit. Viszonylag egyszerű megvalósítani.
A Zookeeper használatának hátrányai elosztott zárak megvalósításához
A teljesítmény nem olyan jó, mint gyorstárral elosztott zárak megvalósítására. A ZK elveinek megértése szükséges.
A három lehetőség összehasonlítása
A könnyebb megértés szempontjából (alacsonytól magasig)
Adatbázis > gyorsítótár > Zookeeper
A megvalósítás összetettsége szempontjából (alacsonytól magasig)
Zookeeper > cache > adatbázisok
Teljesítmény szempontjából (magastól mélyre)
Gyorsítótár > Zookeeper >= adatbázis
Megbízhatósági szempontból (magastól alacsonyig)
Zookeeper > cache > adatbázisok
|
Közzétéve 2018. 08. 30. 15:04:32
|
|
|
|
Háziúr|
Közzétéve 2020. 09. 22. 17:34:33
|
