Otázka: Jeden servisný server, jedna databáza, operácia: vyžiadajte aktuálny zostatok používateľa, odpočítajte 3 % zo súčasného zostatku ako poplatok za spracovanie
synchronizované
zámok
DB Lock
Otázka: Dva servisné servery, jedna databáza, prevádzka: dotazovať sa na aktuálny zostatok používateľa, odpočítať 3 % zo súčasného zostatku ako poplatok za spracovanie
Distribuované zámky
Aký typ distribuovaného zámku potrebujeme?
Môže zabezpečiť, že v distribuovanom klastru aplikácií môže rovnakú metódu vykonať len jedno vlákno na jednom stroji súčasne.
Ak je tento zámok reentrantný (vyhnite sa deadlockom)
Tento zámok je najlepšie ako blokovací zámok (zvážte, či ho chcete podľa potrieb vášho podnikania)
Tento zámok je najlepší, ak je to spravodlivý zámok (zvážte, či ho chcete podľa potrieb firmy)
Existujú vysoko dostupné funkcie zámku získavania a uvoľnenia
Výkon zámkov na získavanie a uvoľnenie je lepší
1. Distribuované zámky založené na databázach
Distribuované zámky založené na implementáciách založených na tabuľkách
Keď chceme uzamknúť metódu, spustíme nasledujúce SQL:
vložte do methodLock(method_name,desc) hodnoty ('method_name','desc')
Keďže sme na method_name vytvorili obmedzenie jedinečnosti, ak je do databázy naraz odoslaných viacero požiadaviek, databáza zabezpečí, že úspešná môže byť len jedna operácia, potom môžeme predpokladať, že vlákno, ktoré úspešne získalo zámok metódy, môže vykonať obsah tela metódy.
Keď sa metóda vykoná, ak chcete uvoľniť zámok, musíte vykonať nasledujúce Sql:
delete from methodLock, kde method_name ='method_name'
Táto jednoduchá implementácia vyššie má nasledujúce problémy:
- Tento zámok závisí od dostupnosti databázy, ktorá je jedným bodom a spôsobí, že podnikový systém bude nedostupný po zaseknutí databázy.
- Tento zámok nemá čas vypršania platnosti a ak operácia odomknutia zlyhá, záznam zámku zostane v databáze a ostatné vlákna už nebudú schopné zámok získať.
- Tento zámok môže byť len neblokujúci, pretože operácia vkladania dát priamo hlási chybu, keď vloženie zlyhá. Vlákna, ktoré nezískajú zámky, nevstúpia do fronty a budú musieť operáciu získania zámku spustiť znova, aby zámok získali znova.
- Zámok je nevstupujúci a tá istá niť nemôže zámok získať znova, kým nie je uvoľnený. Pretože údaje v dátach už existujú.
- Tento zámok je nespravodlivý a všetky vlákna čakajúce na zámok súperia o zámok vďaka šťastiu.
Samozrejme, vyššie uvedené problémy môžeme riešiť aj inými spôsobmi.
- Je databáza len jeden bod? Vytvorte dve databázy a dáta budú synchronizované v oboch smeroch. Keď ju zavesíte, rýchlo prepnite na zálohovaciu knižnicu.
- Žiadna doba expirácie? Jednoducho vykonajte naplánovanú úlohu na pravidelné čistenie dát o časovom limite v databáze.
- Neblokujúce? Robte dlhú slučku, kým vloženie neuspeje, a potom vráťte úspech.
- Ne-reentrant? Pridajte pole do databázovej tabuľky na zaznamenávanie informácií o hostiteľovi a vlákne stroja, ktorý momentálne dostáva zámok, potom nabudúce, keď ho získate, najskôr sa opýtajte na databázu, ak sa informácie o hostiteľovi a vlákne aktuálneho stroja dajú nájsť v databáze, môžete mu zámok priamo priradiť.
- Nespravodlivé? Vytvorte ďalšiu medzilôžkovú tabuľku na zaznamenávanie všetkých vlákien čakajúcich na zámok a zoradíte ich podľa času vytvorenia, pričom len prvé vytvorené vlákno môže zámok získať
Distribuované zámky založené na exkluzívnych zámkoch
Okrem pridávania a mazania záznamov v dátovej tabuľke je možné distribuované zámky implementovať aj pomocou zámkov, ktoré sú súčasťou dát.
Používame tiež databázovú tabuľku, ktorú sme práve vytvorili. Distribuované zámky môžu byť implementované prostredníctvom exkluzívnych zámkov v databázach. Engine InnoDB založený na MySQL môže použiť nasledujúce metódy na implementáciu operácií uzamknutia:
Ak pridáte na aktualizáciu po príkaze dotazu, databáza počas procesu dotazu pridá exkluzívny zámok do tabuľky databázy. Keď sa k záznamu pridá exkluzívny zámok, ostatné vlákna už nemôžu pridať exkluzívny zámok do záznamu na danom riadku.
Môžeme si myslieť, že vlákno, ktoré získa exkluzívny zámok, môže získať distribuovaný zámok, a keď je zámok získaný, obchodná logika metódy môže byť vykonaná a následne odomknutá pomocou nasledujúcich metód:
public void unlock(){ connection.commit(); }
via connection.commit(); Operácia na uvoľnenie zámku.
Táto metóda môže účinne vyriešiť vyššie uvedené problémy týkajúce sa nemožnosti uvoľniť a zablokovať zámok.
Blokovanie zámkov? Príkaz for update sa okamžite po úspešnom vykonaní vráti a zostáva zablokovaný, kým neuspeje.
Služba po uzamknutí nefunkčná, nedá sa uvoľniť? Týmto spôsobom databáza sama uvoľní zámok po výpadku služby.
Napriek tomu to priamo nerieši problém databázového jediného bodu, reentrancie a spravodlivého uzamknutia.
Na zhrnutie spôsobu použitia databázy na implementáciu distribuovaných zámkov, pričom oba závisia od tabuľky v databáze, jedným je zistiť, či zámok existuje, na základe existencie záznamov v tabuľke, a druhým je implementovať distribuované zámky prostredníctvom exkluzívneho zámku databázy.
Výhody distribuovaného zamykania databáz
Priamo s pomocou databázy je to ľahko pochopiteľné.
Nevýhody implementácie distribuovaných zámkov v databázach
Objaví sa množstvo problémov a celé riešenie sa v procese riešenia problému stáva čoraz zložitejším.
Prevádzka databázy si vyžaduje určité režijné náklady a je potrebné zvážiť aj výkonnostné otázky.
2. Distribuované zámky založené na cache
V porovnaní s databázovým distribuovaným riešením zamykania bude implementácia založená na cache výkonnostne výkonnejšia.
V súčasnosti existuje mnoho vyspelých caching produktov, vrátane Redis, memcached a podobne. Tu vezmeme Redis ako príklad na analýzu schémy použitia cache na implementáciu distribuovaných zámkov.
Na internete existuje mnoho súvisiacich článkov o implementácii distribuovaných zámkov založených na Reduis a hlavnou metódou implementácie je použitie metódy Jedis.setNX.
Existuje tiež niekoľko problémov s vyššie uvedenou implementáciou:
1. Problém s jedným bodom.
2. Tento zámok nemá čas vypršania, ak operácia odomykania zlyhá, spôsobí, že záznam zámku bude stále v redis a ostatné vlákna už zámok nezískajú.
3. Tento zámok môže byť len neblokujúci a vráti sa priamo bez ohľadu na úspech alebo neúspech.
4. Tento zámok nie je reentrantný, po získaní zámku niťou nemôže zámok získať späť pred jeho uvoľnením, pretože použitý kľúč už existuje v redis. operácie setNX už nie je možné vykonávať.
5. Tento zámok je nespravodlivý, všetky čakajúce vlákna začínajú operácie setNX súčasne a šťastné vlákna môžu získať zámok.
Samozrejme, existujú aj spôsoby, ako to vyriešiť.
- V súčasnosti hlavné cacheové služby podporujú nasadenie klastrov na riešenie problémov s jedným bodom prostredníctvom klastrovania.
- Žiadna doba expirácie? Metóda setExpire v redis podporuje prichádzajúci čas expirácie a dáta sa po dosiahnutí tohto času automaticky vymažu.
- Neblokujúce? pričom bol opakovane popravovaný.
- Nie je možné znovu vstúpiť? Po získaní zámku vláknom si uložte aktuálne informácie o hostiteľovi a vlákne a skontrolujte, či ste vlastníkom aktuálneho zámku, než ho nabudúce získate.
- Nespravodlivé? Všetky čakajúce vlákna dajte do fronty predtým, než vlákno získa zámok, a potom získajte zámok na princípe prvý dnu, prvý von.
Synchronizačná politika redis klastra trvá čas a je možné, že vlákno A získa zámok po úspešnom nastavení NX, ale táto hodnota nebola aktualizovaná na serveri, kde vlákno B vykonáva setNX, čo spôsobí problémy so súbežnosťou.
Salvatore Sanfilippo, autor redis, navrhol algoritmus Redlock, ktorý implementuje distribuovanú správu zámkov (DLM), ktorá je bezpečnejšia a spoľahlivejšia než jeden uzol.
Algoritmus Redlock predpokladá, že existuje N uzlov, ktoré sú nezávislé jeden od druhého, zvyčajne nastavených na N=5, a týchto N uzlov beží na rôznych strojoch, aby si zachovali fyzickú nezávislosť.
Kroky algoritmu sú nasledovné:
1. Klient získa aktuálny čas v milisekundách.
2. Klient sa snaží získať zámok N uzlov (každý uzol získa zámok rovnakým spôsobom ako spomenutý cache zámok) a N uzlov získa zámok s rovnakým kľúčom a hodnotou. Klient musí nastaviť časový limit prístupu k rozhraniu a čas vypršania rozhrania musí byť oveľa kratší ako časový limit zámku, napríklad čas automatického uvoľnenia zámku je 10 sekúnd, potom je časový limit rozhrania nastavený na približne 5-50 ms. To vám umožní čo najskôr vypršať čas pri prístupe k redis uzlu po jeho výpadku a znižuje bežné používanie zámku.
3. Klient vypočíta, koľko času trvá na získanie zámku, odpočítaním času získaného v kroku 1 od aktuálneho času, iba keď klient získa viac ako 3 uzly zámku a čas na získanie zámku je menší ako čas vypršania zámku, klient získa distribuovaný zámok.
4. Čas klienta na získanie zámku je časový limit nastaveného zámku mínus čas potrebný na získanie zámku vypočítaný v kroku 3.
5. Ak klient nezíska zámok, klient postupne vymaže všetky zámky.
Použitím algoritmu Redlock je zaručené, že distribuovaná služba zámku môže fungovať aj pri zavesení až 2 uzlov, čo výrazne zlepšuje dostupnosť v porovnaní s predchádzajúcim zámkom a cache zámkom databázy.
Avšak distribuovaný expert napísal článok "Ako robiť distribuované zamykanie", v ktorom spochybňoval správnosť Redlocku.
Odborník spomenul, že pri posudzovaní distribuovaných zámkov treba zvážiť dva aspekty: výkon a správnosť.
Ak používate vysokovýkonný distribuovaný zámok a správnosť nie je potrebná, potom je použitie cache zámku postačujúce.
Ak používate vysoko spoľahlivý distribuovaný zámok, musíte zvážiť prísne otázky spoľahlivosti. Redlock naopak nespĺňa správnosť. Prečo nie? Odborníci uvádzajú niekoľko aspektov.
V súčasnosti mnohé programovacie jazyky používajú virtuálne stroje s GC funkciami, pri Full GC program prestane spracovávať GC, niekedy Full GC trvá dlho a dokonca aj program má niekoľko minút oneskorenia, článok uvádza príklad HBase, HBase, niekedy GC na pár minút, čo spôsobí vypršanie prenájmu. Napríklad na obrázku nižšie klient 1 dostane zámok a chystá sa spracovať zdieľaný zdroj, a keď sa chystá spracovať zdieľaný zdroj, nastáva plná GC, kým zámok nevyprší. Týmto spôsobom klient 2 opäť získa zámok a začne pracovať na zdieľanom zdroji. Keď klient 2 spracováva, klient 1 dokončí plnú GC a začne spracovávať zdieľané zdroje, takže obaja klienti spracovávajú zdieľané zdroje.
Odborníci navrhli riešenie, ako je znázornené na obrázku nižšie, vyzerá to tak: MVCC, priniesť token k zámku, token je koncept verzie, zakaždým, keď je operácia locku dokončená, token sa pridá 1, prinesiete token pri spracovaní zdieľaných zdrojov, iba špecifikovaná verzia tokenu môže spracovať zdieľaný zdroj.
Expert tiež povedal, že algoritmus sa spolieha na lokálny čas a že Redis sa spolieha na metódu getTimeOfDay na získanie času namiesto monotónnych hodín pri spracovaní expirácie kľúča, čo tiež vedie k časovým nepresnostiam. Napríklad v scenári majú dvaja klienti 1 a klient 2 5 redis uzlov (A, B, C, D a E).
1. Klient 1 úspešne získa zámok od A, B a C a získa časový limit siete zámkov od D a E.
2. Hodiny uzla C sú nepresné, čo spôsobuje časový limit zámku.
3. klient 2 úspešne získa zámok od C, D a E a zabezpečí časový limit siete zámkov od A a B.
4. Týmto spôsobom majú klient 1 aj klient 2 zámok.
Na zhrnutie dvoch bodov, ktoré odborníci hovoria o Redlockovej nedostupnosti:
1. GC a iné scenáre môžu nastať kedykoľvek, čo spôsobí, že klient získa zámok, a časový limit spracovania spôsobí, že iný klient získa zámok. Odborníci tiež ponúkli riešenie na používanie samo-inkrementujúcich tokenov.
2. Algoritmus sa spolieha na lokálny čas a hodiny budú nepresné, čo spôsobí, že dvaja klienti získajú zámky súčasne.
Preto odborníci dospeli k záveru, že Redlock môže normálne fungovať len v obmedzenom sieťovom oneskorení, obmedzenom prerušení programu a obmedzenom rozsahu chýb hodin, ale hranice týchto troch scenárov nie je možné potvrdiť, preto odborníci neodporúčajú použitie Redlocku. Pre scenáre s vysokými požiadavkami na správnosť odborníci odporúčajú Zookeeper, o ktorom sa bude neskôr diskutovať s použitím Zookeeperu ako distribuovaného zámku.
Odpoveď autora knihy Redis
Autor Redis reagoval napísaním blogu po prečítaní článku odborníka. Autor zdvorilo poďakoval odborníkovi a potom vyjadril nesúhlas s jeho názorom.
Diskusiu autora REDIS o použití tokenov na riešenie problému timeoutu možno zhrnúť do nasledujúcich piatich bodov:
Bod 1, použitie distribuovaných zámkov spočíva vo všeobecnosti v tom, že nemáte iný spôsob, ako ovládať zdieľané zdroje, odborníci používajú tokeny na zabezpečenie spracovania zdieľaných zdrojov, potom nie je potrebné distribuované zámky.
Bod 2: Pri generovaní tokenov, aby sa zabezpečila spoľahlivosť tokenov získaných rôznymi klientmi, služba, ktorá tokeny generuje, stále potrebuje distribuované zámky na zabezpečenie spoľahlivosti služby.
Bod 3, pokiaľ ide o spôsob, akým odborníci hovoria o samoinkrementujúcich sa tokenoch, autor redis verí, že je to úplne zbytočné, každý klient môže vygenerovať jedinečný uuid ako token a nastaviť zdieľaný zdroj do stavu, ktorý môže spracovať len klient s uuid, takže ostatní klienti nemôžu spracovať zdieľaný zdroj, kým klient, ktorý zámok získa, zámok neuvoľní.
Ako je znázornené na obrázku vyššie, ak klient tokenu 34 počas zápisu pošle GC a spôsobí vypršanie zámku, iný klient môže získať zámok tokenu 35 a začať znova zapisovať, čo vedie ku konfliktu zámku. Preto poradie tokenov nemožno kombinovať so zdieľanými zdrojmi.
Bod 5, autor redis verí, že vo väčšine scenárov sa distribuované zámky používajú na riešenie problémov s aktualizáciami v netransakčných scenároch. Autor by mal myslieť na to, že existujú situácie, kde je ťažké kombinovať tokeny na spracovanie zdieľaných zdrojov, takže sa musíte spoliehať na zámky na uzamknutie zdrojov a ich spracovanie.
Ďalší problém s hodinami, o ktorom odborníci hovoria, autori Redis tiež poskytujú vysvetlenie. Ak je čas potrebný na získanie zámku príliš dlhý a presahuje predvolený časový limit zámku, klient v tomto čase zámok získať a odborníci nebudú navrhovať žiadne príklady.
Osobné pocity
Prvým problémom, ktorý zhrňujem, je, že po získaní distribuovaného zámku klientom sa zámok môže uvoľniť po časovom limite počas spracovania klienta. Predtým, keď sa hovorilo o časovom limite nastavenom zámokom databázy na 2 minúty, ak úloha zaberá zámok príkazu dlhšie ako 2 minúty, druhé obchodné centrum môže tento zámok získať, takže obe obchodné centrá môžu spracovať rovnakú objednávku súčasne. Za normálnych okolností sa úloha spracuje za sekundy, ale niekedy, keď je časový limit nastavený pripojením sa k požiadavke RPC príliš dlhý a v úlohe je viacero takýchto požiadaviek na časový limit, je pravdepodobné, že čas automatického odomykania bude prekročený. Ak píšeme v Jave, môže byť Full GC uprostred, takže po odomknutí zámku po timeoute ho klient nemôže vnímať, čo je veľmi vážna vec. Nemyslím si, že je to problém samotného zámku, pokiaľ má akýkoľvek spomenutý distribuovaný zámok vlastnosti uvoľnenia časového limitu, takýto problém nastane. Ak použijete funkciu timeoutu zámku, klient musí časový limit nastaviť a podľa toho konať, namiesto pokračovania v spracovaní zdieľaného zdroja. Redlockov algoritmus vráti čas zamknutia, ktorý klient môže obsadiť po získaní zámku, a klient musí tento čas spracovať, aby úlohu po uplynutí tejto doby zastavil.
Druhým problémom je, že distribuovaní experti Redlocku nerozumejú. Kľúčovou vlastnosťou Redlocku je, že čas potrebný na získanie zámku je celkový čas, ktorý zámok automaticky prejde na časový limit mínus čas potrebný na získanie zámku, takže čas, ktorý klient spracuje, je relatívny bez ohľadu na lokálny čas.
Z tohto pohľadu možno správnosť Redlocku dobre zaručiť. Dôkladná analýza Redlocku, v porovnaní s redis uzla, je hlavnou vlastnosťou Redlocku vyššia spoľahlivosť, čo je v niektorých scenároch dôležitá vlastnosť. Ale myslím si, že Redlock minul príliš veľa peňazí na dosiahnutie spoľahlivosti.
- Najprv musí byť nasadených 5 uzlov, aby bol Redlock spoľahlivejší.
- Potom musíte požiadať o 5 uzlov, aby ste získali zámok, a cez metódu Future môžete najprv žiadať 5 uzlov súčasne a potom získať výsledok odpovede, čo môže skrátiť čas odozvy, ale stále to trvá dlhšie ako jedno-node redis lock.
- Keďže je potrebné získať viac ako 3 z 5 uzlov, môže dôjsť ku konfliktu zámkov, teda všetci získali 1-2 zámky, a v dôsledku toho nikto nemôže získať zámok, tento problém autor Redis preberá podstatu algoritmu raft, prostredníctvom kolízie v náhodnom čase môže byť čas konfliktu výrazne znížený, ale tomuto problému sa nedá veľmi dobre vyhnúť, najmä keď je zámok získaný prvýkrát, takže časové náklady na získanie zámku sa zvyšujú.
- Ak sú 2 z 5 uzlov nefunkčné, dostupnosť zámku sa výrazne zníži, najprv musíte počkať, kým výsledky týchto dvoch padnutých uzlov vypršia pred návratom, a sú len 3 uzly, a klient musí získať zámky všetkých 3 uzlov, aby mal zámok, čo je tiež náročnejšie.
- Ak existuje sieťová partícia, môže nastať situácia, keď klient nikdy nebude schopný získať zámok.
Po analýze mnohých dôvodov si myslím, že najkritickejším bodom problému Redlocku je, že Redlock vyžaduje, aby klienti zabezpečovali konzistentnosť zápisov, pričom backendových 5 uzlov je úplne nezávislých a všetci klienti musia prevádzkovať týchto 5 uzlov. Ak je leader medzi 5 uzlom, klient môže synchronizovať dáta leadera, pokiaľ klient získa zámok od leadera, takže nedôjde k problémom ako partitioning, timeouty a konflikty. Preto, aby sa zabezpečila správnosť distribuovaných zámkov, myslím si, že použitie distribuovanej koordinačnej služby so silnou konzistenciou môže problém lepšie vyriešiť.
Opäť vyvstáva otázka, ako dlho by som mal nastaviť čas expirácie? Nastavenie času na zneplatnenie je príliš krátke a zámok sa automaticky uvoľní pred vykonaním metódy, potom vzniknú problémy so súbežnosťou. Ak to trvá príliš dlho, ostatné vlákna, ktoré sa zamknú, môžu musieť dlho čakať.
Tento problém existuje aj pri používaní databáz na implementáciu distribuovaných zámkov.
Súčasný bežný prístup k tomuto problému je nastaviť krátky časový limit pre každý získaný zámok a začať vlákno na obnovenie času zámku vždy, keď sa blíži k tomuto limitu. Ukončite túto diskusiu súčasne s uvoľnením zámku. Napríklad redisson, oficiálna komponenta distribuovaného zámku v redis, používa toto riešenie.
Výhody použitia cache na implementáciu distribuovaných zámkov
Dobrý výkon.
Nevýhody použitia cache na implementáciu distribuovaných zámkov
Implementácia je príliš zodpovedná, je tu príliš veľa faktorov na zváženie.
Distribuované zámky založené na implementácii Zookeeper
Distribuované zámky založené na dočasne usporiadaných uzloch Zookeeper.
Všeobecná myšlienka je, že keď každý klient zamkne metódu, v adresári špecifikovaného uzla zodpovedajúceho metóde na zookeeper sa vygeneruje jedinečný instantne usporiadaný uzol. Spôsob, ako určiť, či získať zámok, je jednoduchý – stačí určiť ten s najmenším sériovým číslom v usporiadanom uzde. Keď sa zámok uvoľní, jednoducho vymažte okamžitý uzol. Zároveň sa môže vyhnúť problému zablokovaní spôsobených výpadkami služieb, ktoré nie je možné uvoľniť.
Pozrime sa, či Zookeeper dokáže vyriešiť spomínané problémy.
- Zámok sa neuvoľní? Použitie Zookeeperu môže efektívne vyriešiť problém neuvoľnenia zámkov, pretože pri vytváraní zámku klient vytvorí dočasný uzol v ZK, a keď klient zámok získa a náhle ho zasekne (relácia je prerušená), dočasný uzol sa automaticky vymaže. Iní klienti môžu zámok získať znova.
- Neblokujúce zámky? Keď sa uzol zmení, Zookeeper upozorní klienta a klient môže skontrolovať, či vytvorený uzol je najmenším ordinálnym číslom spomedzi všetkých uzlov.
- Nedá sa znovu vstúpiť? Keď klient vytvorí uzol, priamo zapíše informácie o hostiteľovi a vlákne aktuálneho klienta do tohto uzla a nabudúce, keď chcete získať zámok, môžete ho porovnať s dátami v aktuálne najmenšom uzle. Ak sú informácie rovnaké ako vaše, môžete zámok priamo získať, a ak je iný, vytvoriť dočasný sekvenčný uzol na účasť vo fronte.
Otázka opäť vyvstáva, vieme, že Zookeeper musí byť nasadený v klastroch – budú tam problémy so synchronizáciou dát ako v Redis klastroch?
Zookeeper je distribuovaná komponenta, ktorá zaručuje slabú konzistenciu, teda konečnú konzistenciu.
Zookeeper používa protokol na synchronizáciu dát nazývaný Quorum Based Protocol. Ak je v klastri Zookeeper N serverov Zookeeper (N je zvyčajne nepárne, 3 môžu spĺňať spoľahlivosť dát a mať vysoký výkon čítania a zápisu, a 5 má najlepší pomer medzi spoľahlivosťou dát a výkonom čítania a zápisu), potom sa najprv synchronizuje zápisová operácia používateľa na N/2 + 1 servery a potom sa vráti používateľovi, čím sa používateľ úspešne zapíše. Protokol synchronizácie dát založený na protokole Quorum Based Protocol určuje konzistenciu sily, ktorú Zookeeper dokáže podporiť.
V distribuovanom prostredí je ukladanie dát, ktoré dosahuje silnú konzistenciu, prakticky neexistujúce a vyžaduje, aby všetky uzly boli aktualizované synchronne pri aktualizácii dát jedného uzla. Táto stratégia synchronizácie sa objavuje v databáze master-slave synchronnej replikácie. Táto synchronizačná stratégia však má príliš veľký vplyv na výkon zápisu a v praxi sa zriedka vyskytuje. Keďže Zookeeper zapisuje N/2+1 uzlov synchronne a N/2 uzly sa neaktualizujú synchronne, Zookeeper nie je silne konzistentný.
Operácia aktualizácie dát používateľom nezaručuje, že ďalšie čítania prečítajú aktualizovanú hodnotu, ale nakoniec vykazujú konzistentnosť. Obetovanie konzistencie neznamená úplné ignorovanie konzistencie dát, inak sú dáta chaotické, takže bez ohľadu na to, aká vysoká je dostupnosť systému, bez ohľadu na to, aké dobré je rozdelenie, nemá to žiadnu hodnotu. Obetovanie konzistencie znamená, že silná konzistencia v relačných databázach už nie je potrebná, ale pokiaľ systém dosiahne konečnú konzistenciu.
Otázka na jeden bod? Použitie Zookeeper dokáže efektívne vyriešiť problém jedného bodu, ZK je nasadený v klastroch a pokiaľ prežije viac ako polovica strojov v klastri, služba môže byť poskytovaná aj vonkajšiemu svetu.
Problémy so spravodlivosťou? Použitie Zookeeperu môže vyriešiť problém spravodlivých zámkov, dočasné uzly vytvorené klientom v ZK sú usporiadané a pri každom uvoľnení zámku môže ZK upozorniť najmenší uzol, aby zámok získal, čím zabezpečí spravodlivosť.
Otázka opäť vyvstáva, vieme, že Zookeeper musí byť nasadený v klastroch – budú tam problémy so synchronizáciou dát ako v Redis klastroch?
Zookeeper je distribuovaná komponenta, ktorá zaručuje slabú konzistenciu, teda konečnú konzistenciu.
Zookeeper používa protokol na synchronizáciu dát nazývaný Quorum Based Protocol. Ak je v klastri Zookeeper N serverov Zookeeper (N je zvyčajne nepárne, 3 môžu spĺňať spoľahlivosť dát a mať vysoký výkon čítania a zápisu, a 5 má najlepší pomer medzi spoľahlivosťou dát a výkonom čítania a zápisu), potom sa najprv synchronizuje zápisová operácia používateľa na N/2 + 1 servery a potom sa vráti používateľovi, čím sa používateľ úspešne zapíše. Protokol synchronizácie dát založený na protokole Quorum Based Protocol určuje konzistenciu sily, ktorú Zookeeper dokáže podporiť.
V distribuovanom prostredí je ukladanie dát, ktoré dosahuje silnú konzistenciu, prakticky neexistujúce a vyžaduje, aby všetky uzly boli aktualizované synchronne pri aktualizácii dát jedného uzla. Táto stratégia synchronizácie sa objavuje v databáze master-slave synchronnej replikácie. Táto synchronizačná stratégia však má príliš veľký vplyv na výkon zápisu a v praxi sa zriedka vyskytuje. Keďže Zookeeper zapisuje N/2+1 uzlov synchronne a N/2 uzly sa neaktualizujú synchronne, Zookeeper nie je silne konzistentný.
Operácia aktualizácie dát používateľom nezaručuje, že ďalšie čítania prečítajú aktualizovanú hodnotu, ale nakoniec vykazujú konzistentnosť. Obetovanie konzistencie neznamená úplné ignorovanie konzistencie dát, inak sú dáta chaotické, takže bez ohľadu na to, aká vysoká je dostupnosť systému, bez ohľadu na to, aké dobré je rozdelenie, nemá to žiadnu hodnotu. Obetovanie konzistencie znamená, že silná konzistencia v relačných databázach už nie je potrebná, ale pokiaľ systém dosiahne konečnú konzistenciu.
Či Zookeeper spĺňa kauzálnu konzistenciu, závisí od toho, ako je klient naprogramovaný.
Praktiky, ktoré nespĺňajú kauzálnu konzistenciu
- Proces A zapíše dáta do /z Zookeeperu a úspešne vráti
- Proces A informuje proces B, že A upravil údaje /z
- B číta údaje z /z Zookeepera
- Keďže server Zookeepera pripojený k B nemusel byť aktualizovaný zapísanými údajmi A, B nebude schopný čítať zapísané údaje A
Praktiky, ktoré spĺňajú kauzálnu konzistenciu
- Proces B počúva zmeny dát v /z na Zookeeper
- Proces A zapíše dáta do /z Zookeepera a predtým, než sa úspešne vráti, musí Zookeeper zavolať poslucháča registrovaného na /z a vedúci upozorní B na zmenu dát
- Po odpovedi na reakciu na udalosť procesu B prijme zmenené dáta, takže B určite získa zmenenú hodnotu
- Kauzálna konzistencia tu označuje kauzálnu konzistenciu medzi lídrom a B, teda lídrom oznamuje údaje o zmene
Druhý mechanizmus počúvania udalostí je tiež metóda, ktorá by sa mala použiť na správne programovanie Zookeepera, takže Zookeeper by mal spĺňať kauzálnu konzistenciu
Preto, keď implementujeme distribuované zámky založené na Zookeepere, mali by sme použiť prax uspokojenia kauzálnej konzistencie, teda vlákna čakajúce na zámok počúvajú zmeny v zámku Zookeepera a keď sa zámok uvoľní, Zookeeper upozorní čakajúce vlákno, ktoré spĺňa podmienky spravodlivého zámku.
Môžete priamo použiť klienta Zookeeper tretej strany, ktorý zapuzdrí službu reentrant lock.
Distribuované zámky implementované pomocou ZK presne zodpovedajú tomu, čo sme od distribuovaného zámku očakávali na začiatku tohto článku. Nie je to však tak, a distribuovaný zámok implementovaný Zookeeperom má v skutočnosti nevýhodu, a to že výkon nemusí byť taký vysoký ako u cacheovacej služby. Pretože pri každom procese vytvárania a uvoľňovania zámku musia byť okamžité uzly dynamicky vytvorené a zničené, aby sa zrealizovala funkcia zámku. Vytváranie a mazanie uzlov v ZK je možné vykonávať iba cez vedúci server, a potom sa dáta zdieľajú so všetkými nasledujúcimi strojmi.
Výhody použitia Zookeeperu na implementáciu distribuovaných zámkov
Efektívne riešiť problémy s jedným bodom, problémy bez návratu do atmosféry, problémy bez blokovania a zlyhanie uvoľnenia zámku. Je to relatívne jednoduché na implementáciu.
Nevýhody použitia Zookeepera na implementáciu distribuovaných zámkov
Výkon nie je taký dobrý ako pri používaní cache na implementáciu distribuovaných zámkov. Je potrebné pochopenie princípov ZK.
Porovnanie troch možností
Z pohľadu jednoduchosti pochopenia (od nízkej po vysokú)
Databáza > Cache > Zookeeper
Z pohľadu zložitosti implementácie (od nízkej po vysokú)
Zookeeper > cache > databázy
Z pohľadu výkonu (od vysokého po nízke)
Cacheovanie > Zookeeper >= databáza
Z hľadiska spoľahlivosti (od vysokej po nízku)
Zookeeper > cache > databázy
|
Zverejnené 30. 8. 2018 15:04:32
|
|
|
|
Prenajímateľ|
Zverejnené 22. 9. 2020 17:34:33
|
