V: En servisni strežnik, ena podatkovna baza, operacija: poizvedba o trenutnem stanju uporabnika, odšteje 3 % trenutnega stanja kot pristojbino za obdelavo
sinhronizirano
ključavnica
DB Lock
V: Dva servisna strežnika, ena podatkovna baza, operacija: poizvedba o trenutnem stanju uporabnika, odštevanje 3 % trenutnega stanja kot stroškov obdelave
Distribuirane ključavnice
Kakšno razpršeno ključavnico potrebujemo?
Lahko zagotovi, da lahko v porazdeljenem aplikacijskem gruči isto metodo izvede le ena nit na enem računalniku hkrati.
Če je ta ključavnica reentrantna (izogibajte se mrtvim zaklepom)
Ta ključavnica je najboljša kot zaporna ključavnica (premislite, ali jo želite glede na potrebe vašega podjetja)
Ta ključavnica je najboljša, če je poštena ključavnica (premislite, ali jo želite glede na poslovne potrebe)
Na voljo so zelo razpoložljive funkcije zajetja in zaklepanja sprostitve
Uspešnost zaklepov za pridobivanje in sprostitev je boljša
1. Porazdeljene ključavnice na podlagi podatkovnih baz
Porazdeljene ključavnice na podlagi implementacij na osnovi tabel
Ko želimo zakleniti metodo, izvedemo naslednji SQL:
vstavi v methodLock(method_name,desc) vrednosti ('method_name','desc')
Ker smo na method_name postavili omejitev edinstvenosti, če je v bazo hkrati vloženih več zahtevkov, bo baza zagotovila, da lahko uspe le ena operacija, lahko predpostavimo, da nit, ki je uspešno zaklenila metodo, lahko izvede vsebino telesa metode.
Ko se metoda izvede, če želite sprostiti zaklep, morate izvesti naslednji SQL:
delete from methodLock, kjer method_name ='method_name'
Ta preprosta izvedba zgoraj ima naslednje težave:
- Ta zaklep je odvisen od razpoložljivosti baze podatkov, ki je ena sama točka in bo povzročila, da poslovni sistem ne bo dosegljiv, ko je baza podatkov zamrznjena.
- Ta zaklep nima časa poteka, in ko operacija odklepanja ne uspe, zapis o zaklepu ostane v bazi podatkov in druge niti ga ne bodo več mogle pridobiti.
- Ta zaklep je lahko neblokirajoč le, ker operacija vstavljanja podatkov neposredno poroča o napaki, ko vstavljanje ne uspe. Niti, ki ne pridobijo ključavnic, ne vstopijo v vrsto in morajo ponovno sprožiti operacijo pridobivanja ključavnice, da ponovno pridobijo zaklep.
- Ključavnica je nepovratna in ista nit ne more ponovno pridobiti ključavnice, dokler ni sprostena. Ker podatki v podatkih že obstajajo.
- Ta ključavnica je nepoštena, in vse niti, ki čakajo na ključavnico, tekmujejo za ključavnico po sreči.
Seveda lahko zgoraj omenjene probleme rešimo tudi na druge načine.
- Ali je baza podatkov ena sama točka? Zgradite dve bazi podatkov in podatki bodo sinhronizirani v obe smeri. Ko se odloži, hitro preklopite na rezervno knjižnico.
- Ni časa trajanja? Preprosto opravite načrtovano nalogo za redno čiščenje podatkov o časovni omejitvi v bazi.
- Ne blokira? Naredi dolgo zanko, dokler vstavljanje ne uspe, nato pa vrneš uspeh.
- Ne-ponovni vstopnik? Dodaj polje v tabelo baze podatkov, da zabeležiš informacije o gostitelju in nit računalnika, ki trenutno prejema zaklep, nato naslednjič, ko dobiš zaklep, najprej poizvediš po bazi, če so informacije o gostitelju in niti trenutne naprave v bazi, lahko neposredno dodeliš zaklep njemu.
- Nepravično? Ustvarite drugo vmesno tabelo za beleženje vseh niti, ki čakajo na zaklep, in jih razvrstite glede na čas ustvarjanja, pri čemer lahko zaklep pridobi le prva ustvarjena
Distribuirane ključavnice na podlagi ekskluzivnih ključavnic
Poleg dodajanja in brisanja zapisov v podatkovni tabeli je mogoče distribuirane ključavnice implementirati tudi s pomočjo zaklepov, ki so priložene podatkom.
Uporabljamo tudi tabelo baze podatkov, ki smo jo pravkar ustvarili. Porazdeljene zaklepe je mogoče implementirati z ekskluzivnimi zaklepi na bazah podatkov. Pogon InnoDB, ki temelji na MySql, lahko uporablja naslednje metode za izvajanje operacij zaklepanja:
Če dodate za posodobitev po poizvedbenem stavku, bo baza podatkov med poizvedbo dodala ekskluzivno zaklepanje tabele baze. Ko se zapisu doda ekskluzivna ključavnica, druge niti ne morejo več dodati ekskluzivne ključavnice zapisu na tej vrstici.
Lahko si mislimo, da lahko nit, ki pridobi ekskluzivno zaklepanje, pridobi porazdeljeno zaklepanje, in ko je zaklep dosežen, se lahko izvrši poslovna logika metode in jo nato odklene z naslednjimi metodami:
public void unlock(){ connection.commit(); }
via connection.commit(); Operacija za sprostitev ključavnice.
Ta metoda lahko učinkovito reši zgoraj omenjene težave, povezane z nezmožnostjo sprostitve in blokiranja ključavnice.
Blokiranje ključavnic? Ukaz for update se takoj po uspešni izvedbi vrne in ostane blokiran, dokler ne uspe.
Storitev po zaklepanju ne deluje, ne more biti sproščena? Na ta način podatkovna baza sama sprosti ključavnico, ko storitev preneha delovati.
Vendar pa še vedno ne rešuje neposredno problema enojne točke baze podatkov, ponovnega vključevanja in poštenega zaklepanja.
Če povzamem način uporabe baze podatkov za implementacijo porazdeljenih zaklepov, ki oba temeljita na tabeli v podatkovni bazi, je ena ugotovitev, ali zaklepanje obstaja, glede na obstoj zapisov v tabeli, druga pa implementacija porazdeljenih zaklepov preko ekskluzivne zaklepavnice baze podatkov.
Prednosti porazdeljenega zaklepanja v podatkovnih bazah
Neposredno s pomočjo baze podatkov je enostavno razumeti.
Slabosti implementacije porazdeljenih zaklepov v podatkovnih bazah
Pojavilo se bo več težav, celotna rešitev pa bo postajala vse bolj zapletena v procesu reševanja.
Upravljanje baze podatkov zahteva določene stroške, zato je treba upoštevati tudi vprašanja zmogljivosti.
2. Distribuirane zaklepe na podlagi predpomnilnika
V primerjavi z rešitvijo distribuiranega zaklepanja, ki temelji na podatkovni bazi, bo implementacija, ki temelji na predpomnilniku, delovala bolje glede zmogljivosti.
Trenutno obstaja veliko zrelih produktov za predpomnjenje, vključno z Redis, memcached itd. Tukaj vzamemo Redis kot primer za analizo sheme uporabe predpomnilnika za implementacijo porazdeljenih zaklepov.
Na internetu je veliko sorodnih člankov o implementaciji porazdeljenih zaklepov na osnovi Redis, glavna metoda implementacije pa je uporaba metode Jedis.setNX.
Obstaja tudi več težav z zgornjo implementacijo:
1. Problem z eno samo točko.
2. Ta ključavnica nima časa poteka; ko operacija odklepanja spodleti, bo zapis ključavnice ves čas v redisu, druge niti pa ne morejo več pridobiti ključavnice.
3. Ta ključavnica je lahko le neblokirajoča in se bo vrnila neposredno ne glede na uspeh ali neuspeh.
4. Ta ključavnica ni reentrantna, po tem, ko nit pridobi ključavnico, je ne more ponovno pridobiti, preden jo sprosti, ker ključ, ki se uporablja, že obstaja v redisu. operacij setNX ni več mogoče izvajati.
5. Ta zaklep je nepravičen, vse čakajoče niti hkrati začnejo setNX operacije, srečne niti pa lahko dobijo zaklep.
Seveda obstajajo tudi načini, kako to rešiti.
- Danes glavne storitve predpomnjenja podpirajo uvajanje grozdov za reševanje težav z eno točko preko gručenja.
- Ni časa trajanja? Metoda setExpire za redis podpira vhodni čas poteka, podatki pa se samodejno izbrišejo po doseženem času.
- Ne blokira? medtem ko je bil večkrat usmrčen.
- Ali ni mogoče ponovno vstopiti? Ko nit pridobi zaklep, shranite trenutne informacije o gostitelju in nit ter preverite, ali ste lastnik trenutne ključavnice, preden jo naslednjič pridobite.
- Nepravično? Vse čakajoče niti postavite v čakalno vrsto, preden nit pridobi zaklep, nato pa pridobite zaklep po principu prvi noter, prvi ven.
Sinhronizacijska politika redis gruče traja nekaj časa, in možno je, da nit A dobi zaklep po uspešni nastavitvi NX, vendar ta vrednost ni bila posodobljena na strežniku, kjer nit B izvaja setNX, kar bo povzročilo težave s sočasnostjo.
Salvatore Sanfilippo, avtor redis, je predlagal algoritem Redlock, ki izvaja distribuirano upravljanje zaklepov (DLM), ki je varnejše in zanesljivejše kot eno vozlišče.
Algoritem Redlock predpostavlja, da obstaja N redis vozlišč, ki so med seboj neodvisna, običajno nastavljeno na N=5, in da teh N vozlišč teče na različnih računalnikih, da ohranijo fizično neodvisnost.
Koraki algoritma so naslednji:
1. Odjemalec pridobi trenutni čas v milisekundah.
2. Odjemalec poskuša pridobiti zaklep N vozlišč (vsako vozlišče dobi zaklep na enak način kot prej omenjeni predpomnilniški zaklep), in N vozlišč dobi zaklep z enakim ključem in vrednostjo. Odjemalec mora nastaviti časovno omejitev dostopa do vmesnika, čas časovne omejitve vmesnika pa mora biti bistveno krajši od časovne omejitve zaklepa; na primer, čas samodejnega sprostitve zaklepa je 10 sekund, nato pa je časovna omejitev vmesnika nastavljena na približno 5-50 ms. To vam omogoča, da čim prej iztečete čas pri dostopu do redis vozlišča po njegovem izpadu in zmanjša običajno uporabo zaklepa.
3. Odjemalec izračuna, koliko časa je potrebnega za pridobitev zaklepa, tako da odšteje čas, pridobljen v koraku 1, s trenutnim časom; šele ko odjemalec pridobi več kot 3 vozlišča zaklepa in je čas za pridobitev zaklepa krajši od časovne omejitve zaklepa, odjemalec pridobi porazdeljeno ključavnico.
4. Čas, ki ga odjemalec potrebuje za pridobitev ključavnice, je čas časovne omejitve nastavljene ključavnice minus čas, porabljen za pridobitev ključavnice, izračunan v koraku 3.
5. Če odjemalec ne uspe pridobiti ključavnice, bo odjemalec zaporedoma izbrisal vse ključavnice.
Z uporabo algoritma Redlock je mogoče zagotoviti, da lahko storitev distribuiranega zaklepanja še vedno deluje, če se zatakne do 2 vozlišči, kar močno izboljša razpoložljivost v primerjavi s prejšnjim zaklepom baze podatkov in zaklepanjem predpomnilnika.
Vendar pa je distribuirani strokovnjak napisal članek "Kako narediti distribuirano zaklepanje", v katerem je postavil pod vprašaj pravilnost Redlocka.
Strokovnjak je omenil, da je treba upoštevati dva vidika pri obravnavi porazdeljenih ključavnic: zmogljivost in pravilnost.
Če uporabljate visoko zmogljivo distribuirano zaklepanje in pravilnost ni potrebna, je uporaba predpomnilniške zaklepnice zadostna.
Če uporabljate zelo zanesljivo distribuirano ključavnico, morate upoštevati stroga vprašanja zanesljivosti. Redlock pa po drugi strani ne izpolnjuje pravilnosti. Zakaj pa ne? Strokovnjaki navajajo več vidikov.
Danes veliko programskih jezikov uporablja virtualne stroje z GC funkcijami, pri Full GC program preneha obdelovati GC, včasih Full GC traja dolgo, program pa ima tudi nekaj minut zamika, članek navaja primer HBase, HBase včasih GC za nekaj minut, kar povzroči potek najema. Na primer, na spodnji sliki odjemalec 1 dobi zaklep in je tik pred obdelavo skupnega vira, ko pa se pripravlja na obdelavo skupnega vira, pride do popolnega GC, dokler zaklep ne poteče. Na ta način odjemalec 2 ponovno dobi zaklep in začne delati na skupnem viru. Ko odjemalec 2 obdeluje, odjemalec 1 zaključi celoten GC in začne obdelovati skupne vire, tako da oba odjemalca obdelujeta skupne vire.
Strokovnjaki so ponudili rešitev, kot je prikazano na spodnji sliki, je videti kot MVCC, prinesi žeton do zaklepa, žeton je koncept različice, vsakič, ko je zaklep operacije zaključen, se žeton doda 1, prinesi žeton pri obdelavi deljenih virov, le določena različica žetona lahko upravlja skupni vir.
Nato je strokovnjak dodal, da algoritem temelji na lokalnem času, Redis pa na metodo getTimeOfDay za pridobivanje časa namesto na monotono uro pri obravnavi poteka ključa, kar prav tako vodi do časovnih netočnosti. Na primer, v scenariju imata dva odjemalec 1 in odjemalec 2 5 redis vozlišč (A, B, C, D in E).
1. Odjemalec 1 uspešno pridobi ključavnico od A, B in C ter pridobi časovno omejitev omrežja ključavnic od D in E.
2. Ura vozlišča C je nenatančna, kar povzroči časovno omejitev zaklepa.
3. odjemalec 2 uspešno pridobi ključavnico od C, D in E ter pridobi časovno omejitev omrežja od A in B.
4. Na ta način dobita tako odjemalec 1 kot odjemalec 2 zaklep.
Za povzetek dveh točk, ki jih strokovnjaki pravijo o Redlockovi nedosegljivosti:
1. GC in drugi scenariji se lahko pojavijo kadarkoli, kar povzroči, da odjemalec pridobi zaklep, in časovni izstop obdelave povzroči, da drug odjemalec pridobi zaklep. Strokovnjaki so prav tako ponudili rešitev za uporabo samopovečevalnih žetonov.
2. Algoritem se zanaša na lokalni čas, ura pa bo nenatančna, kar povzroči, da bosta hkrati zaklepali dva odjemalca.
Zato strokovnjaki sklepajo, da Redlock lahko normalno deluje le v omejenem omrežnem zamiku, omejeni prekinitvi programa in omejenem območju napak ure, vendar meja teh treh scenarijev ni mogoče potrditi, zato strokovnjaki ne priporočajo uporabe Redlocka. Za primere z visokimi zahtevami glede pravilnosti strokovnjaki priporočajo Zookeeper, o katerem bomo kasneje govorili z uporabo Zookeeperja kot distribuirane ključavnice.
Odgovor avtorja knjige Redis
Avtor Redisa je odgovoril z napisom bloga po pregledu strokovnega članka. Avtor se je strokovnjaku vljudno zahvalil in nato izrazil nestrinjanje z njegovim stališčem.
Razpravo avtorja REDIS o uporabi žetonov za reševanje problema časovne omejitve zaklepa lahko povzamemo v naslednjih petih točkah:
Točka 1, uporaba porazdeljenih zaklepov je običajno v tem, da nimate drugega načina za nadzor skupnih virov, strokovnjaki uporabljajo žetone za zagotavljanje obdelave deljenih virov, zato porazdeljene zaklepe niso potrebne.
Točka 2: Za generiranje žetonov, da bi zagotovili zanesljivost žetonov, ki jih pridobijo različni odjemalci, storitev, ki generira žetone, še vedno potrebuje razpršene ključavnice za zagotavljanje zanesljivosti storitve.
Točka 3, glede na to, kako strokovnjaki pravijo samopovečevanje žetonov, avtor redis meni, da je to popolnoma nepotrebno; vsak odjemalec lahko ustvari edinstven uuid kot žeton in nastavi skupni vir v stanje, ki ga lahko upravlja le odjemalec z uuid-om, tako da drugi odjemalci ne morejo obdelati skupnega vira, dokler odjemalec z zaklepom ne sprosti zaklepa.
Kot je prikazano na zgornji sliki, če odjemalec žetona 34 med zapisom pošlje GC in povzroči potek zaklepa, lahko drug odjemalec dobi zaklep žetona 35 in začne znova pisati, kar povzroči konflikt zaklepa. Zato vrstnega reda žetonov ni mogoče združiti s skupnimi viri.
Točka 5, avtor redis verjame, da se v večini scenarijev distribuirane ključavnice uporabljajo za reševanje težav s posodobitvami v netransakcijskih scenarijih. Avtor naj bi mislil, da obstajajo situacije, kjer je težko združiti žetone za obdelavo skupnih virov, zato se morate zanašati na ključavnice za zaklepanje virov in njihovo obdelavo.
Še ena težava s časom, o kateri strokovnjaki govorijo, avtorji Redisa prav tako podajo razlago. Če je čas, potreben za pridobitev ključavnice, predolg in presega privzeti časovni omejitev ključavnice, potem naročnik v tem trenutku ne more pridobiti ključavnice in strokovnjaki ne bodo predlagali nobenih primerov.
Osebna čustva
Prva težava, ki jo povzemam, je, da se lahko po tem, ko odjemalec pridobi distribuirano zaklepanje, ta sprosti po izteku časa med odjemalčevo obdelavo. Prej, ko smo govorili o časovni omejitvi, ki jo določa zaklep baze podatkov, 2 minuti, če naloga zasede zaklep naročila več kot 2 minuti, lahko drugi trgovalni center pridobi to zaklepanje, tako da lahko oba trgovalna centra obdelata isto naročilo hkrati. V običajnih okoliščinah se naloga obdela v nekaj sekundah, vendar je včasih, če je časovna omejitev, določena z vstopom v RPC zahtevo, predolga, in če je v nalogi več takšnih zahtev, je verjetno, da bo čas samodejnega odklepanja presežen. Če pišemo v javi, je lahko v sredini Full GC, tako da po odklepanju zaklepa po časovnem izteku zaklepa odjemalec tega ne zazna, kar je zelo resna stvar. Ne mislim, da je to težava v sami ključavnici, dokler ima katera koli zgoraj omenjena porazdeljena ključavnica lastnosti sprostitve časovne omejitve, se bo takšna težava pojavila. Če uporabite funkcijo časovne omejitve zaklepa, mora odjemalec nastaviti časovno omejitev in ustrezno ukrepati, namesto da bi nadaljeval obdelavo skupnega vira. Redlockov algoritem vrne čas zaklepanja, ki ga lahko odjemalec zasede po pridobitvi zaklepa, odjemalec pa mora ta čas obdelati, da nalogo ustavi po tem času.
Druga težava je, da distribuirani strokovnjaki ne razumejo Redlocka. Ključna lastnost Redlocka je, da je čas za pridobitev ključavnice skupni čas, ki ga zaklep privzeto uporabi na časovno omejitev, minus čas, potreben za pridobitev ključavnice, tako da je čas, ki ga odjemalec potrebuje za obdelavo, relativni čas, ne glede na lokalni čas.
S tega vidika je pravilnost Redlocka povsem zagotovljena. Ob skrbni analizi Redlocka je v primerjavi z redisom vozlišča glavna lastnost Redlocka višja zanesljivost, kar je v nekaterih primerih pomembna lastnost. Ampak mislim, da je Redlock porabil preveč denarja, da bi dosegel zanesljivost.
- Najprej je treba namestiti 5 vozlišč, da bo Redlock bolj zanesljiv.
- Nato morate zahtevati 5 vozlišč, da dobite zaklep, in s metodo Future lahko najprej hkrati zahtevate 5 vozlišč, nato pa dobite rezultat odgovora, kar lahko skrajša odzivni čas, vendar še vedno traja več kot enovozliščna redis zaklep.
- Ker je treba pridobiti več kot 3 od 5 vozlišč, lahko pride do konflikta zaklepov, torej vsi so pridobili 1-2 zaklepanja, in posledično nihče ne more dobiti zaklepa; ta problem, avtor Redisa si izposodi bistvo algoritma raft, s trkom ob naključnem času se lahko čas konflikta močno zmanjša, vendar se temu problemu ni mogoče dobro izogniti, še posebej, če je zaklep pridobljen prvič, zato se časovni strošek za pridobitev ključavnice poveča.
- Če sta 2 od 5 vozlišč nedosegljiva, se bo razpoložljivost zaklepa močno zmanjšala; najprej morate počakati, da rezultati teh dveh vozlišč potečejo, preden se vrnete, saj so le 3 vozlišča, odjemalec pa mora pridobiti zaklepe vseh 3 vozlišč, da ima zaklep, kar je prav tako težje.
- Če obstaja omrežna particija, se lahko zgodi, da odjemalec nikoli ne bo mogel pridobiti zaklepa.
Po analizi številnih razlogov menim, da je najkritičnejša točka problema Redlocka ta, da Redlock zahteva, da odjemalci zagotovijo doslednost zapisov, zadnjih 5 vozlišč pa je popolnoma neodvisnih in morajo vsi odjemalci upravljati teh 5 vozlišč. Če je vodja med petimi vozlišči, lahko odjemalec sinhronizira podatke vodje, dokler odjemalec pridobi zaklep od vodje, tako da ne bo težav, kot so particioniranje, časovni izpadi in konflikti. Zato menim, da lahko za zagotovitev pravilnosti porazdeljenih ključavnic uporaba porazdeljene koordinacijske storitve z močno doslednostjo bolje reši ta problem.
Spet se pojavi vprašanje, kako dolgo naj nastavim čas trajanja? Kako nastaviti čas razveljavitve, če je prekratko, zaklep se samodejno sprosti pred izvedbo metode, zato pride do težav s sočasnostjo. Če traja predolgo, bodo morali drugi navoji, ki dobijo zaklep, morda dolgo čakati.
Ta težava obstaja tudi pri uporabi podatkovnih baz za implementacijo porazdeljenih zaklepov.
Trenutni glavni pristop k temu problemu je, da se za vsako doseženo zaklepanje nastavi kratek čas časovne omejitve in se začne nit, ki osvežuje čas časovne omejitve vsakič, ko se približa časovni iztek. Zaključite to temo hkrati, ko sprostite ključavnico. Na primer, redisson, uradna komponenta distribuiranega zaklepanja v redisu, uporablja to rešitev.
Prednosti uporabe predpomnjenja za implementacijo porazdeljenih zaklepov
Dobra predstava.
Slabosti uporabe predpomnjenja za implementacijo porazdeljenih zaklepov
Izvedba je preveč odgovorna, preveč dejavnikov je treba upoštevati.
Porazdeljene ključavnice na podlagi implementacije Zookeeperja
Porazdeljene ključavnice na podlagi Zookeeperjevih začasno urejenih vozlišč.
Splošna ideja je, da ko vsak odjemalec zaklene metodo, se v imeniku določenega vozlišča, ki ustreza metodi na zookeeperju, ustvari edinstveno takojšnje urejeno vozlišče. Način, kako ugotoviti, ali dobiti ključavnico, je preprost – dovolj je, da določite tisto z najmanjšo serijsko številko v urejenem vozlišču. Ko se zaklep sprosti, preprosto izbrišite trenutni vozel. Hkrati se lahko izogne težavam zastojev, ki jih povzročajo izpadi storitev, ki jih ni mogoče sprostiti.
Poglejmo, ali lahko Zookeeper reši prej omenjene težave.
- Zaklep se ne sprosti? Uporaba Zookeeperja lahko učinkovito reši problem, da se zaklepi ne sprostijo, saj ob ustvarjanju ključavnice odjemalec ustvari začasno vozlišče v ZK, in ko odjemalec pridobi zaklep in ga nenadoma zatakne (povezava seje je prekinjena), se začasno vozlišče samodejno izbriše. Drugi naročniki lahko ključavnico dobijo znova.
- Ključavnice, ki ne blokirajo? Ko se vozlišče spremeni, Zookeeper obvesti odjemalca, odjemalec pa lahko preveri, ali je vozlišče, ki ga je ustvaril, najmanjše ordinalno število med vsemi vozlišči.
- Ne moreš ponovno vstopiti? Ko odjemalec ustvari vozlišče, neposredno zapiše informacije o gostitelju in nitki trenutnega odjemalca na vozlišče, in naslednjič, ko želite pridobiti zaklep, ga lahko primerjate s podatki v trenutno najmanjšem vozlišču. Če so informacije enake vašim, lahko neposredno pridobite zaklep, in če je drugačen, ustvarite začasno zaporedno vozlišče za sodelovanje v vrsti.
Vprašanje se ponovno pojavlja – vemo, da je treba Zookeeper namestiti v grozde, ali bodo težave s sinhronizacijo podatkov, kot so Redis grozdi?
Zookeeper je distribuirana komponenta, ki zagotavlja šibko doslednost, torej končno konsistentnost.
Zookeeper uporablja protokol za sinhronizacijo podatkov, imenovan Quorum Based Protocol. Če je v gruči Zookeeper N Zookeeper strežnikov (N je običajno liho, 3 dosegajo zanesljivost podatkov in imajo visoko zmogljivost branja in pisanja, 5 pa najboljše ravnovesje med zanesljivostjo podatkov in zmogljivostjo branja in pisanja), se najprej sinhronizira naloga pisanja uporabnika na N/2 + 1 strežnike, nato pa se vrne uporabniku, kar uporabnika pozove k uspešnemu pisanju. Protokol za sinhronizacijo podatkov, ki temelji na Quorum Based Protocol, določa doslednost moči, ki jo Zookeeper lahko podpira.
V distribuiranem okolju je shranjevanje podatkov, ki dosega močno doslednost, praktično neobstoječe in zahteva, da so vsa vozlišča sinhrono posodobljena ob posodobitvi podatkov enega vozlišča. Ta strategija sinhronizacije se pojavlja v podatkovni bazi master-slave sinhrone replikacije. Vendar pa ima ta sinhronizacijska strategija prevelik vpliv na zmogljivost pisanja in se v praksi redko pojavi. Ker Zookeeper sinhrono piše N/2+1 vozlišč, N/2 vozlišč pa se ne posodablja sinhrono, Zookeeper ni močno konsistenten.
Uporabnikova operacija posodabljanja podatkov ne zagotavlja, da bodo naslednja branja prebrala posodobljeno vrednost, vendar bo sčasoma pokazala doslednost. Žrtvovanje konsistentnosti ne pomeni popolnega ignoriranja konsistentnosti podatkov, sicer so podatki kaotični, zato ne glede na to, kako visoka je razpoložljivost sistema ali kako dobra je porazdelitev, nimajo vrednosti. Žrtvovanje doslednosti pomeni, da močna doslednost v relacijskih bazah podatkov ni več potrebna, dokler sistem lahko doseže končno doslednost.
Vprašanje za eno točko? Uporaba Zookeeperja lahko učinkovito reši problem posamezne točke, ZK je nameščen v grozdih, dokler preživi več kot polovica strojev v grozdi, je storitev mogoče zagotoviti zunanjemu svetu.
Vprašanja pravičnosti? Uporaba Zookeeperja lahko reši problem poštenih zaklepov, začasna vozlišča, ki jih ustvari odjemalec v ZK, so urejena, in vsakič, ko se zaklep sprosti, lahko ZK obvesti najmanjše vozlišče, da pridobi ključavnico, kar zagotavlja pravičnost.
Vprašanje se ponovno pojavlja – vemo, da je treba Zookeeper namestiti v grozde, ali bodo težave s sinhronizacijo podatkov, kot so Redis grozdi?
Zookeeper je distribuirana komponenta, ki zagotavlja šibko doslednost, torej končno konsistentnost.
Zookeeper uporablja protokol za sinhronizacijo podatkov, imenovan Quorum Based Protocol. Če je v gruči Zookeeper N Zookeeper strežnikov (N je običajno liho, 3 dosegajo zanesljivost podatkov in imajo visoko zmogljivost branja in pisanja, 5 pa najboljše ravnovesje med zanesljivostjo podatkov in zmogljivostjo branja in pisanja), se najprej sinhronizira naloga pisanja uporabnika na N/2 + 1 strežnike, nato pa se vrne uporabniku, kar uporabnika pozove k uspešnemu pisanju. Protokol za sinhronizacijo podatkov, ki temelji na Quorum Based Protocol, določa doslednost moči, ki jo Zookeeper lahko podpira.
V distribuiranem okolju je shranjevanje podatkov, ki dosega močno doslednost, praktično neobstoječe in zahteva, da so vsa vozlišča sinhrono posodobljena ob posodobitvi podatkov enega vozlišča. Ta strategija sinhronizacije se pojavlja v podatkovni bazi master-slave sinhrone replikacije. Vendar pa ima ta sinhronizacijska strategija prevelik vpliv na zmogljivost pisanja in se v praksi redko pojavi. Ker Zookeeper sinhrono piše N/2+1 vozlišč, N/2 vozlišč pa se ne posodablja sinhrono, Zookeeper ni močno konsistenten.
Uporabnikova operacija posodabljanja podatkov ne zagotavlja, da bodo naslednja branja prebrala posodobljeno vrednost, vendar bo sčasoma pokazala doslednost. Žrtvovanje konsistentnosti ne pomeni popolnega ignoriranja konsistentnosti podatkov, sicer so podatki kaotični, zato ne glede na to, kako visoka je razpoložljivost sistema ali kako dobra je porazdelitev, nimajo vrednosti. Žrtvovanje doslednosti pomeni, da močna doslednost v relacijskih bazah podatkov ni več potrebna, dokler sistem lahko doseže končno doslednost.
Ali Zookeeper izpolnjuje vzročno doslednost, je odvisno od tega, kako je odjemalec programiran.
Prakse, ki ne zadovoljujejo vzročne skladnosti
- Proces A zapiše kos podatkov v Zookeeperjev /z in uspešno vrne podatke
- Proces A obvesti proces B, da je A spremenil podatke /z
- B bere podatke Zookeeperjevega /z
- Ker strežnik Zookeeperja, povezan z B, morda ni bil posodobljen z A-jevimi zapisanimi podatki, B ne bo mogel prebrati A-jevih zapisanih podatkov
Prakse, ki dosegajo vzročno doslednost
- Proces B posluša spremembe podatkov v /z na Zookeeperju
- Proces A zapiše podatek na Zookeeperjev /z, in preden se uspešno vrne, mora Zookeeper poklicati poslušalca, registriranega na /z, vodja pa bo obvestil B o spremembi podatkov
- Ko je metoda odziva na dogodek pri procesu B odgovorjena, sprejme spremenjene podatke, zato bo B zagotovo lahko dobil spremenjeno vrednost
- Vzročna skladnost se tukaj nanaša na vzročno skladnost med vodjo in B, torej vodja obvesti podatke o spremembi
Drugi mehanizem poslušanja dogodkov je tudi metoda, ki jo je treba uporabiti za pravilno programiranje Zookeeperja, zato mora Zookeeper izpolnjevati vzročno konsistentnost
Zato bi morali pri implementaciji distribuiranih ključavnic na osnovi Zookeeperja uporabiti prakso zadovoljevanja vzročne konsistentnosti, torej niti, ki čakajo na ključavnico, poslušajo spremembe v zaklepu Zookeeperja, in ko je ključavnica sprostena, bo Zookeeper obvestil čakajočo nit, ki izpolnjuje pogoje poštenega zaklepa.
Lahko neposredno uporabite Zookeeper odjemalca tretje osebe za knjižnice, ki zajema storitev reentrant lock.
Porazdeljene ključavnice, implementirane z ZK, se zdijo točno tiste, kar smo pričakovali od porazdeljene ključavnice na začetku tega članka. Vendar pa ni, in porazdeljena ključavnica, ki jo je implementiral Zookeeper, ima dejansko slabost, saj zmogljivost morda ni tako visoka kot pri storitvi predpomnjenja. Ker je vsakič, ko ustvarjamo in sproščamo ključavnico, za uresničitev funkcije zaklepa potrebno dinamično ustvariti in uničiti trenutne vozlišča. Ustvarjanje in brisanje vozlišč v ZK je mogoče izvajati le prek vodilnega strežnika, nato pa se podatki delijo z vsemi spremljevalnimi stroji.
Prednosti uporabe Zookeeperja za implementacijo porazdeljenih ključavnic
Učinkovito rešujte težave z eno točko, težave brez ponovnega vstopa, težave brez blokad in neuspeh pri sprostitvi zaklepa. Implementacija je razmeroma preprosta.
Slabosti uporabe Zookeeperja za implementacijo porazdeljenih zaklepov
Zmogljivost ni tako dobra kot pri uporabi predpomnilnika za implementacijo porazdeljenih zaklepov. Potrebno je razumevanje načel ZK.
Primerjava treh možnosti
Z vidika enostavnega razumevanja (od nizke do visoke)
Baza podatkov > predpomnilnik > Zookeeper
Z vidika kompleksnosti implementacije (od nizke do visoke)
Zookeeper > predpomnilnik > baze podatkov
Z vidika uspešnosti (od visokega do nizkega)
Predpomnjenje > Zookeeper >= podatkovna baza
Z vidika zanesljivosti (od visoke do nizke)
Zookeeper > predpomnilnik > baze podatkov
|
Objavljeno na 30. 08. 2018 15:04:32
|
|
|
|
Najemodajalec|
Objavljeno na 22. 09. 2020 17:34:33
|
