K: Vienas paslaugų serveris, viena duomenų bazė, operacija: užklauskite vartotojo dabartinį likutį, išskaičiuokite 3% nuo dabartinio likučio kaip tvarkymo mokestį
sinchronizuota
užraktas
DB užraktas
K: Du paslaugų serveriai, viena duomenų bazė, operacija: užklauskite vartotojo dabartinį likutį, išskaičiuokite 3% nuo dabartinio likučio kaip tvarkymo mokestį
Paskirstytos spynos
Kokio paskirstyto užrakto mums reikia?
Tai gali užtikrinti, kad paskirstytame programų klasteryje tą patį metodą vienu metu gali vykdyti tik viena gija viename kompiuteryje.
Jei šis užraktas yra pakartotinis užraktas (venkite aklavietės)
Ši spyna geriausiai yra blokuojanti spyna (apsvarstykite, ar norite šios pagal savo verslo poreikius)
Ši spyna geriausiai turi būti sąžininga spyna (apsvarstykite, ar norite šios, ar ne, atsižvelgiant į verslo poreikius)
Yra labai prieinamos fiksavimo ir atleidimo užrakto funkcijos
Geresnis įsigijimo ir atleidimo spynų veikimas
1. Paskirstytos spynos, pagrįstos duomenų bazėmis
Paskirstyti užraktai, pagrįsti lentelėmis pagrįstais diegimais
Kai norime užrakinti metodą, vykdykite šį SQL:
įterpti į methodLock(method_name,desc) reikšmes ('method_name','desc')
Kadangi mes padarėme method_name unikalumo apribojimą, jei į duomenų bazę vienu metu pateikiamos kelios užklausos, duomenų bazė užtikrins, kad tik viena operacija gali būti sėkminga, tada galime manyti, kad gija, kuri sėkmingai gavo metodą, užrakina ir gali vykdyti metodo turinį.
Kai metodas vykdomas, jei norite atleisti užraktą, turite atlikti šį Sql:
ištrinti iš methodLock kur method_name ='method_name'
Šis paprastas įgyvendinimas aukščiau turi šias problemas:
- Šis užraktas priklauso nuo duomenų bazės prieinamumo, kuris yra vienas taškas, todėl verslo sistema bus nepasiekiama, kai duomenų bazė bus pakabinta.
- Šis užraktas neturi galiojimo laiko, o kai atrakinimo operacija nepavyks, užrakto įrašas liks duomenų bazėje, o kitos gijos nebegalės gauti užrakto.
- Šis užraktas gali būti tik neblokuojantis, nes duomenų įterpimo operacija tiesiogiai praneš apie klaidą, kai nepavyks įterpti. Gijos, kurios neįgyja užraktų, nepateks į eilę ir turės dar kartą suaktyvinti užrakto įsigijimo operaciją, kad vėl gautų užraktą.
- Užraktas nėra pakartotinis, ir tas pats siūlas negali vėl gauti užrakto, kol jis nebus atleistas. Nes duomenys duomenyse jau yra.
- Ši spyna yra nesąžininga spyna, ir visi siūlai, laukiantys spynos, konkuruoja dėl spynos sėkmės.
Žinoma, aukščiau išvardytas problemas galime išspręsti ir kitais būdais.
- Ar duomenų bazė yra vienas taškas? Sukurkite dvi duomenų bazes ir duomenys bus sinchronizuojami abiem kryptimis. Padėję ragelį, greitai perjunkite į atsarginę biblioteką.
- Nėra galiojimo laiko? Tiesiog atlikite suplanuotą užduotį, kad reguliariai išvalytumėte skirtojo laiko duomenis duomenų bazėje.
- Neblokuojantis? Atlikite tam tikrą ciklą, kol įterpimas pavyks ir grąžins sėkmę.
- Ne pakartotinis? Pridėkite lauką į duomenų bazės lentelę, kad įrašytumėte pagrindinio kompiuterio informaciją ir gijų informaciją apie mašiną, kuri šiuo metu gauna užraktą, tada kitą kartą gavę užraktą, pirmiausia užklauskite duomenų bazę, jei pagrindinio kompiuterio informaciją ir gijų informaciją galima rasti duomenų bazėje, galite tiesiogiai priskirti užraktą jam.
- Nesąžininga? Sukurkite kitą tarpinę lentelę, kad įrašytumėte visas gijas, laukiančias užrakto, ir rūšiuokite jas pagal sukūrimo laiką, ir tik pirmajai sukurtai leidžiama įsigyti užraktą
Paskirstytos spynos, pagrįstos išskirtinėmis spynomis
Be įrašų pridėjimo ir ištrynimo duomenų lentelėje, paskirstytus užraktus taip pat galima įdiegti naudojant užraktus, kurie pateikiami kartu su duomenimis.
Taip pat naudojame ką tik sukurtą duomenų bazės lentelę. Paskirstytus užraktus galima įdiegti naudojant išskirtinius duomenų bazių užraktus. "MySql" pagrįstas "InnoDB" variklis gali naudoti šiuos metodus užrakinimo operacijoms įgyvendinti:
Jei įtrauksite naujinti po užklausos sakinio, užklausos proceso metu duomenų bazė pridės išskirtinį duomenų bazės lentelės užraktą. Kai į įrašą įtraukiamas išskirtinis užraktas, kitos gijos nebegali įtraukti išskirtinio užrakto į įrašą toje eilutėje.
Galime manyti, kad gija, gaunanti išskirtinį užraktą, gali gauti paskirstytą užraktą, o gavus užraktą, galima vykdyti metodo verslo logiką, o tada atrakinti šiais būdais:
public void unlock(){ connection.commit(); }
per connection.commit(); užrakto atlaisvinimo operacija.
Šis metodas gali veiksmingai išspręsti aukščiau paminėtas problemas dėl nesugebėjimo atlaisvinti užrakto ir užblokuoti užrakto.
Blokuoti spynas? Sakinys for update grįžta iškart po sėkmingo vykdymo ir lieka užblokuotas, kol pavyksta.
Aptarnavimas neveikia po užrakto, jo negalima atleisti? Tokiu būdu duomenų bazė pati atleidžia užraktą, kai paslauga neveikia.
Tačiau tai vis dar tiesiogiai neišsprendžia duomenų bazės vieno taško, pakartotinio įėjimo ir sąžiningo užrakinimo problemos.
Apibendrinant duomenų bazės naudojimo būdą paskirstytiems užraktams įgyvendinti, kurie abu priklauso nuo duomenų bazės lentelės, vienas yra nustatyti, ar yra užraktas pagal įrašų egzistavimą lentelėje, o kitas - įdiegti paskirstytus užraktus per išskirtinį duomenų bazės užraktą.
Paskirstyto duomenų bazių užrakinimo privalumai
Tiesiogiai naudojant duomenų bazę, tai lengva suprasti.
Paskirstytų užraktų diegimo duomenų bazėse trūkumai
Bus įvairių problemų, o visas sprendimas problemos sprendimo procese taps vis sudėtingesnis.
Duomenų bazės valdymas reikalauja tam tikrų pridėtinių išlaidų, todėl reikia atsižvelgti į našumo problemas.
2. Paskirstytos spynos pagal talpyklą
Palyginti su duomenų baze pagrįstu paskirstyto užrakinimo sprendimu, talpykla pagrįstas diegimas veiks geriau.
Šiuo metu yra daug brandžių talpyklos produktų, įskaitant "Redis", "memcached" ir kt. Čia mes imame "Redis" kaip pavyzdį, kad išanalizuotume talpyklos naudojimo paskirstytiems užraktams įgyvendinti schemą.
Internete yra daug susijusių straipsnių apie paskirstytų spynų, pagrįstų Redis, įgyvendinimą, o pagrindinis įgyvendinimo būdas yra naudoti Jedis.setNX metodą.
Taip pat yra keletas problemų, susijusių su aukščiau pateiktu įgyvendinimu:
1. Vieno taško problema.
2. Šis užraktas neturi galiojimo laiko, kai atrakinimo operacija nepavyks, užrakto įrašas visą laiką bus raudonas, o kiti siūlai nebegalės gauti užrakto.
3. Šis užraktas gali būti tik neblokuojantis ir grįš tiesiogiai, nepriklausomai nuo sėkmės ar nesėkmės.
4. Ši spyna nėra pakartotinė, po to, kai siūlas gauna spyną, ji negali vėl gauti užrakto prieš atleisdama spyną, nes naudojamas raktas jau egzistuoja redis. setNX operacijų vykdyti nebegalima.
5. Šis užraktas yra nesąžiningas, visos laukiančios gijos pradeda setNX operacijas tuo pačiu metu, o laimingos gijos gali gauti užraktą.
Žinoma, yra ir būdų, kaip tai išspręsti.
- Šiais laikais pagrindinės talpyklos paslaugos palaiko klasterio diegimą, kad būtų galima išspręsti vieno taško problemas klasterizuojant.
- Nėra galiojimo laiko? Redis metodas setExpire palaiko gaunamą galiojimo laiką, o duomenys automatiškai ištrinami pasibaigus laikui.
- Neblokuojantis? kai pakartotinai vykdoma.
- Ar neįmanoma vėl įeiti? Kai gija įgyja užraktą, išsaugokite dabartinę pagrindinio kompiuterio informaciją ir gijos informaciją ir patikrinkite, ar esate dabartinio užrakto savininkas prieš gaudami kitą kartą.
- Nesąžininga? Įdėkite visus laukiančius siūlus į eilę, kol siūlas įgyja užraktą, ir tada įsigykite užraktą pirmas į, pirmas išeina.
Redis klasterio sinchronizavimo strategija užtrunka, ir gali būti, kad gija A užrakinama sėkmingai nustačius NX, tačiau ši reikšmė nebuvo atnaujinta serveryje, kuriame gija B vykdo setNX, o tai sukels sutapimo problemų.
Salvatore Sanfilippo, redis autorius, pasiūlė "Redlock" algoritmą, kuris įgyvendina paskirstytą užrakto valdymą (DLM), kuris yra saugesnis ir patikimesnis nei vienas mazgas.
Redlock algoritmas daro prielaidą, kad yra N redis mazgų, kurie yra nepriklausomi vienas nuo kito, paprastai nustatyti į N=5, ir šie N mazgai veikia skirtingose mašinose, kad išlaikytų fizinę nepriklausomybę.
Algoritmo veiksmai yra šie:
1. Klientas gauna dabartinį laiką milisekundėmis.
2. Klientas bando gauti N mazgų užraktą (kiekvienas mazgas gauna užraktą taip pat, kaip ir anksčiau minėtas talpyklos užraktas), o N mazgai gauna užraktą su tuo pačiu raktu ir reikšme. Klientas turi nustatyti sąsajos prieigos skirtąjį laiką, o sąsajos skirtasis laikas turi būti daug trumpesnis nei užrakto skirtasis laikas, pavyzdžiui, užrakto automatinio atleidimo laikas yra 10 s, tada sąsajos skirtasis laikas nustatomas maždaug 5-50 ms. Tai leidžia kuo greičiau pasiekti "redis" mazgą, kai jis sugenda, ir sumažina įprastą užrakto naudojimą.
3. Klientas apskaičiuoja, kiek laiko užtrunka užraktui gauti, atimdamas 1 žingsnyje gautą laiką iš dabartinio laiko, tik tada, kai klientas gauna daugiau nei 3 spynos mazgus, o užrakto įsigijimo laikas yra trumpesnis nei užrakto laikas, klientas gauna paskirstytą užraktą.
4. Kliento užrakto įsigijimo laikas yra nustatytas užrakto laikas atėmus laiką, praleistą spynai gauti, apskaičiuotą 3 veiksme.
5. Jei klientui nepavyksta gauti užrakto, klientas ištrins visas spynas iš eilės.
Naudojant "Redlock" algoritmą, galima garantuoti, kad paskirstyta užrakto paslauga vis tiek gali veikti pakabinus iki 2 mazgų, o tai labai pagerina prieinamumą, palyginti su ankstesniu duomenų bazės užraktu ir talpyklos užraktu.
Tačiau paskirstytas ekspertas parašė straipsnį "Kaip atlikti paskirstytą užrakinimą", kuriame abejoja "Redlock" teisingumu.
Ekspertas paminėjo, kad svarstant paskirstytas spynas reikia atsižvelgti į du aspektus: našumą ir teisingumą.
Jei naudojate didelio našumo paskirstytą užraktą ir teisingumas nereikalingas, pakanka naudoti talpyklos užraktą.
Jei naudojate labai patikimą paskirstytą užraktą, turite atsižvelgti į griežtus patikimumo klausimus. Kita vertus, "Redlock" neatitinka teisingumo. Kodėlgi ne? Ekspertai išvardija keletą aspektų.
Šiais laikais daugelis programavimo kalbų naudoja virtualias mašinas su GC funkcijomis, "Full GC" programa nustos apdoroti GC, kartais "Full GC" užtrunka ilgai ir net programa turi kelias minutes vėlavimo, straipsnyje pateikiamas HBase, HBase kartais GC pavyzdys kelioms minutėms, dėl kurių nuomos laikas baigsis. Pavyzdžiui, toliau pateiktame paveikslėlyje 1 klientas gauna užraktą ir ruošiasi apdoroti bendrinamą išteklių, o kai jis ruošiasi apdoroti bendrinamą išteklių, visas GC įvyksta tol, kol baigiasi užrakto galiojimo laikas. Tokiu būdu 2 klientas vėl gauna užraktą ir pradeda dirbti su bendrinamu ištekliumi. Kai 2 klientas apdoroja, 1 klientas užbaigia visą GC ir pradeda apdoroti bendrai naudojamus išteklius, kad abu klientai apdorotų bendrinamus išteklius.
Ekspertai pateikė sprendimą, kaip parodyta paveikslėlyje žemiau, atrodo kaip MVCC, atneškite žetoną į spyną, žetonas yra versijos sąvoka, kiekvieną kartą, kai operacijos užraktas bus baigtas, žetonas bus pridėtas 1, atneškite žetoną apdorojant bendrus išteklius, tik nurodyta žetono versija gali tvarkyti bendrinamus išteklius.
Tada ekspertas taip pat pasakė, kad algoritmas remiasi vietiniu laiku, o Redis remiasi getTimeOfDay metodu, kad gautų laiką, o ne monotonišką laikrodį, kai tvarkomas rakto galiojimo laikas, o tai taip pat lemia laiko netikslumus. Pavyzdžiui, scenarijuje du 1 ir 2 klientai turi 5 redis mazgus (A, B, C, D ir E).
1. 1 klientas sėkmingai įsigyja užraktą iš A, B ir C ir gauna užrakto tinklo skirtąjį laiką iš D ir E.
2. C mazgo laikrodis yra netikslus, todėl baigiasi užrakto laikas.
3. 2 klientas sėkmingai įsigyja užraktą iš C, D ir E ir gauna užrakto tinklo skirtąjį laiką iš A ir B.
4. Tokiu būdu tiek 1, tiek 2 klientas gauna užraktą.
Apibendrinant du dalykus, ekspertai sako apie Redlock neprieinamumą:
1. GC ir kiti scenarijai gali įvykti bet kuriuo metu, todėl klientas gauna užraktą, o apdorojimo skirtasis laikas priverčia kitą klientą gauti užraktą. Ekspertai taip pat pateikė sprendimą, kaip naudoti savaime didėjančius žetonus.
2. Algoritmas remiasi vietiniu laiku, o laikrodis bus netikslus, todėl du klientai vienu metu gaus užraktus.
Todėl ekspertų išvada yra ta, kad "Redlock" gali normaliai veikti tik esant ribotam tinklo vėlavimui, ribotam programos pertraukimui ir ribotam laikrodžio paklaidos diapazonui, tačiau šių trijų scenarijų ribų patvirtinti negalima, todėl ekspertai nerekomenduoja naudoti "Redlock". Scenarijams, kuriems keliami aukšti teisingumo reikalavimai, ekspertai rekomenduoja "Zookeeper", kuris bus aptartas vėliau naudojant "Zookeeper" kaip paskirstytą užraktą.
Atsakymas iš autoriaus Redis
"Redis" autorius atsakė parašęs tinklaraštį, pamatęs eksperto straipsnį. Autorius mandagiai padėkojo ekspertui, o tada išreiškė nesutikimą su eksperto nuomone.
REDIS autoriaus diskusiją apie žetonų naudojimą užrakto skirtojo laiko problemai išspręsti galima apibendrinti šiais penkiais punktais:
1 punktas, paskirstytų spynų naudojimas paprastai yra tas, kad jūs neturite kito būdo valdyti bendrus išteklius, ekspertai naudoja žetonus, kad užtikrintų bendrų išteklių apdorojimą, tada nereikia paskirstytų spynų.
2 punktas: siekiant užtikrinti skirtingų klientų gautų žetonų patikimumą, žetonus generuojančiai paslaugai vis tiek reikia paskirstytų užraktų, kad būtų užtikrintas paslaugos patikimumas.
3 punktas, kaip ekspertai sako, kad savaime didėjantys žetonai, redis autorius mano, kad tai visiškai nereikalinga, kiekvienas klientas gali sugeneruoti unikalų uuid kaip žetoną ir nustatyti bendrą išteklių būseną, kurią gali apdoroti tik klientas su uuid, kad kiti klientai negalėtų apdoroti bendro ištekliaus, kol klientas, kuris gauna užraktą, atleidžia užraktą.
Kaip parodyta aukščiau esančiame paveikslėlyje, jei 34 atpažinimo ženklo klientas siunčia GC rašymo proceso metu ir sukelia užrakto laiką, kitas klientas gali gauti 35 atpažinimo ženklo užraktą ir vėl pradėti rašyti, todėl gali kilti užrakto konfliktas. Todėl žetonų tvarka negali būti derinama su bendrais ištekliais.
5 punktas, redis autorius mano, kad daugeliu scenarijų paskirstyti užraktai naudojami atnaujinimo problemoms spręsti ne sandorių scenarijuose. Autorius turėtų pasakyti, kad yra keletas scenarijų, kai sunku sujungti žetonus, kad būtų galima valdyti bendrus išteklius, todėl turite pasikliauti spynomis, kad užrakintumėte išteklius ir juos apdorotumėte.
Kita laikrodžio problema, apie kurią kalba ekspertai, "Redis" autoriai taip pat pateikia paaiškinimą. Jei užrakto įsigijimo laikas yra per ilgas ir viršija numatytąjį užrakto skirtąjį laiką, klientas šiuo metu negali gauti užrakto, o ekspertų pasiūlytų pavyzdžių nebus.
Asmeniniai jausmai
Pirmoji problema, kurią apibendrinu, yra ta, kad klientui gavus paskirstytą užraktą, užraktas gali būti atleistas po skirtojo laiko kliento apdorojimo metu. Anksčiau, kalbant apie 2 minučių duomenų bazės užrakto nustatytą skirtąjį laiką, jei užduotis užima užsakymo užraktą ilgiau nei 2 minutes, kitas prekybos centras gali gauti šį užsakymo užraktą, kad abu prekybos centrai galėtų apdoroti tą patį užsakymą tuo pačiu metu. Įprastomis aplinkybėmis užduotis apdorojama per kelias sekundes, tačiau kartais prisijungus prie RPC užklausos nustatytas skirtasis laikas yra per ilgas, o užduotyje yra kelios tokios skirtojo laiko užklausos, tikėtina, kad automatinio atrakinimo laikas bus viršytas. Jei rašome java, viduryje gali būti Full GC, todėl atrakinus užraktą pasibaigus užrakto skirtajam laikui, klientas negali to suvokti, o tai yra labai rimtas dalykas. Nemanau, kad tai yra problema su užraktu pati, kol bet paskirstytas užraktas minėtas aukščiau turi ypatybes skirtojo laiko atleidimo, tokia problema atsiras. Jei naudojate užrakinimo skirtojo laiko funkciją, klientas turi nustatyti užrakto skirtąjį laiką ir imtis atitinkamų veiksmų, užuot tęsęs bendrinamo ištekliaus apdorojimą. "Redlock" algoritmas grąžina užrakinimo laiką, kurį klientas gali užimti po to, kai klientas įsigyja užraktą, ir klientas turi apdoroti šį laiką, kad sustabdytų užduotį po to laiko.
Antroji problema yra ta, kad paskirstyti ekspertai nesupranta Redlock. Pagrindinis "Redlock" bruožas yra tas, kad užrakto įsigijimo laikas yra bendras laikas, kai užraktas pagal numatytuosius nustatymus baigiasi atėmus laiką, kurio reikia spynai įsigyti, todėl laikas, per kurį klientas apdoroja, yra santykinis laikas, nepriklausomai nuo vietos laiko.
Šiuo požiūriu "Redlock" teisingumas gali būti gerai garantuotas. Kruopščiai analizuojant Redlock, palyginti su mazgo redis, pagrindinė Redlock funkcija yra didesnis patikimumas, kuris yra svarbi savybė kai kuriuose scenarijuose. Bet manau, kad Redlock išleido per daug pinigų, kad pasiektų patikimumą.
- Pirma, reikia įdiegti 5 mazgus, kad "Redlock" būtų patikimesnis.
- Tada turite paprašyti 5 mazgų, kad gautumėte užraktą, o naudodami ateities metodą pirmiausia galite paprašyti 5 mazgų vienu metu, o tada gauti atsakymo rezultatą, o tai gali sutrumpinti atsakymo laiką, tačiau vis tiek užtrunka daugiau laiko nei vieno mazgo redis užraktas.
- Tada, kadangi reikia gauti daugiau nei 3 iš 5 mazgų, gali kilti užrakto konfliktas, tai yra, visi gavo 1-2 spynas, ir dėl to niekas negali gauti spynos, ši problema, Redis autorius pasiskolina plausto algoritmo esmę, per susidūrimą atsitiktiniu laiku konflikto laikas gali būti labai sutrumpintas, tačiau šios problemos negalima išvengti labai gerai, ypač kai spyna įsigyjama pirmą kartą, todėl padidėja spynos įsigijimo laiko sąnaudos.
- Jei 2 iš 5 mazgų neveikia, užrakto prieinamumas labai sumažės, visų pirma, prieš grįždami turite palaukti, kol baigsis šių dviejų nuleistų mazgų rezultatai, o yra tik 3 mazgai, o klientas turi gauti visų 3 mazgų spynas, kad būtų užraktas, o tai taip pat yra sunkiau.
- Jei yra tinklo skaidinys, gali būti situacija, kai klientas niekada negalės gauti užrakto.
Išanalizavęs tiek daug priežasčių, manau, kad svarbiausias Redlock problemos taškas yra tas, kad Redlock reikalauja, kad klientai užtikrintų rašymo nuoseklumą, o backend 5 mazgai yra visiškai nepriklausomi, ir visi klientai turi valdyti šiuos 5 mazgus. Jei tarp 5 mazgų yra lyderis, klientas gali sinchronizuoti lyderio duomenis tol, kol klientas gauna užraktą iš lyderio, kad nekiltų problemų, tokių kaip skaidymas, skirtasis laikas ir konfliktai. Todėl, siekiant užtikrinti paskirstytų spynų teisingumą, manau, kad naudojant paskirstytą koordinavimo paslaugą su dideliu nuoseklumu galima geriau išspręsti problemą.
Vėl kyla klausimas, kiek laiko turėčiau nustatyti galiojimo laiką? Kaip nustatyti negaliojimo laiką yra per trumpas, o užraktas automatiškai atleidžiamas prieš vykdant metodą, tada kils sutapimo problemų. Jei tai užtrunka per ilgai, kitų siūlų, kurie gauna užraktą, gali tekti ilgai laukti.
Ši problema taip pat kyla naudojant duomenų bazes paskirstytiems užraktams įgyvendinti.
Dabartinis pagrindinis požiūris į šią problemą yra nustatyti trumpą kiekvieno gauto užrakto skirtąjį laiką ir pradėti giją, kad atnaujintumėte užrakto skirtąjį laiką kiekvieną kartą, kai jis netrukus pasieks skirtąjį laiką. Užbaikite šią giją, tuo pačiu metu atleisdami užraktą. Pavyzdžiui, redisson, oficialus paskirstytas redis užrakto komponentas, naudoja šį sprendimą.
Talpyklos naudojimo paskirstytiems užraktams įgyvendinti privalumai
Geras pasirodymas.
Talpyklos naudojimo paskirstytoms spynoms įgyvendinti trūkumai
Įgyvendinimas yra pernelyg atsakingas, yra per daug veiksnių, į kuriuos reikia atsižvelgti.
Paskirstytos spynos, pagrįstos "Zookeeper" įdiegimu
Paskirstytos spynos, pagrįstos laikinai užsakytais "Zookeeper" mazgais.
Bendra idėja yra ta, kad kiekvienam klientui užrakinus metodą, nurodyto mazgo kataloge sugeneruojamas unikalus momentinis užsakytas mazgas, atitinkantis zookeeper metodą. Būdas nustatyti, ar gauti užraktą, yra paprastas, jums reikia nustatyti tik tą, kurio užsakytame mazge yra mažiausias serijos numeris. Kai užraktas bus atleistas, tiesiog ištrinkite momentinį mazgą. Tuo pačiu metu tai gali išvengti aklavietės, kurią sukelia paslaugų prastovos, kurios negalima atleisti.
Pažiūrėkime, ar "Zookeeper" gali išspręsti anksčiau minėtas problemas.
- Užraktas nebus atleistas? "Zookeeper" naudojimas gali efektyviai išspręsti spynų neatleidimo problemą, nes kurdamas užraktą klientas sukurs laikiną mazgą ZK, o kai klientas gaus užraktą ir staiga jį pakabins (sesijos ryšys nutrūks), laikinasis mazgas bus automatiškai ištrintas. Kiti klientai gali vėl gauti užraktą.
- Neblokuojančios spynos? Pasikeitus mazgui, "Zookeeper" praneš klientui, o klientas galės patikrinti, ar jo sukurtas mazgas yra mažiausias eilės numeris tarp visų mazgų.
- Negalite vėl įeiti? Kai klientas sukuria mazgą, jis tiesiogiai įrašo dabartinio kliento pagrindinio kompiuterio informaciją ir gijų informaciją į mazgą, o kitą kartą, kai norėsite gauti užraktą, galėsite palyginti jį su dabartinio mažiausio mazgo duomenimis. Jei informacija yra tokia pati kaip jūsų, galite tiesiogiai gauti užraktą, o jei jis skiriasi, sukurkite laikiną nuoseklų mazgą, kad galėtumėte dalyvauti eilėje.
Vėl kyla klausimas, žinome, kad "Zookeeper" turi būti diegiamas klasteriuose, ar kils duomenų sinchronizavimo problemų, tokių kaip "Redis" klasteriai?
Zookeeper yra paskirstytas komponentas, garantuojantis silpną nuoseklumą, t. y. galiausiai nuoseklumą.
"Zookeeper" naudoja duomenų sinchronizavimo protokolą, vadinamą "Quorum Based Protocol". Jei "Zookeeper" klasteryje yra N "Zookeeper" serverių (N paprastai yra nelyginis, 3 gali atitikti duomenų patikimumą ir pasižymėti dideliu skaitymo ir rašymo našumu, o 5 turi geriausią pusiausvyrą tarp duomenų patikimumo ir skaitymo bei rašymo našumo), tada vartotojo rašymo operacija pirmiausia sinchronizuojama su N/2 + 1 serveriais, o tada grąžinama vartotojui, raginant vartotoją sėkmingai rašyti. Duomenų sinchronizavimo protokolas, pagrįstas kvorumu pagrįstu protokolu, nustato stiprumo nuoseklumą, kurį gali palaikyti Zookeeper.
Paskirstytoje aplinkoje duomenų saugykla, atitinkanti stiprų nuoseklumą, iš esmės neegzistuoja, todėl atnaujinant vieno mazgo duomenis reikia sinchroniškai atnaujinti visus mazgus. Ši sinchronizavimo strategija rodoma sinchroninio replikavimo duomenų bazėje Master-Slave. Tačiau ši sinchronizavimo strategija turi per didelę įtaką rašymo našumui ir retai pastebima praktikoje. Kadangi Zookeeper rašo N/2+1 mazgus sinchroniškai, o N/2 mazgai nėra atnaujinami sinchroniškai, Zookeeper nėra labai nuoseklus.
Vartotojo duomenų atnaujinimo operacija negarantuoja, kad vėlesni skaitymai nuskaitys atnaujintą reikšmę, bet galiausiai parodys nuoseklumą. Paaukoti nuoseklumą nereiškia visiškai ignoruoti duomenų nuoseklumą, kitaip duomenys yra chaotiški, todėl nesvarbu, koks didelis sistemos prieinamumas, kad ir koks geras būtų paskirstymas, jis neturi jokios vertės. Nuoseklumo aukojimas yra tik tai, kad stiprus nuoseklumas reliacinėse duomenų bazėse nebereikalingas, bet tol, kol sistema gali pasiekti galutinį nuoseklumą.
Vieno taško klausimas? Naudojant "Zookeeper" galima efektyviai išspręsti vieno taško problemą, ZK diegiama klasteriuose, kol išgyvena daugiau nei pusė klasterio mašinų, paslauga gali būti teikiama išoriniam pasauliui.
Sąžiningumo klausimai? Naudojant "Zookeeper" galima išspręsti sąžiningų užraktų problemą, laikini mazgai, kuriuos klientas sukūrė ZK, yra tvarkingi, o kiekvieną kartą, kai užraktas atleidžiamas, ZK gali pranešti mažiausiam mazgui, kad gautų užraktą, užtikrindamas teisingumą.
Vėl kyla klausimas, žinome, kad "Zookeeper" turi būti diegiamas klasteriuose, ar kils duomenų sinchronizavimo problemų, tokių kaip "Redis" klasteriai?
Zookeeper yra paskirstytas komponentas, garantuojantis silpną nuoseklumą, t. y. galiausiai nuoseklumą.
"Zookeeper" naudoja duomenų sinchronizavimo protokolą, vadinamą "Quorum Based Protocol". Jei "Zookeeper" klasteryje yra N "Zookeeper" serverių (N paprastai yra nelyginis, 3 gali atitikti duomenų patikimumą ir pasižymėti dideliu skaitymo ir rašymo našumu, o 5 turi geriausią pusiausvyrą tarp duomenų patikimumo ir skaitymo bei rašymo našumo), tada vartotojo rašymo operacija pirmiausia sinchronizuojama su N/2 + 1 serveriais, o tada grąžinama vartotojui, raginant vartotoją sėkmingai rašyti. Duomenų sinchronizavimo protokolas, pagrįstas kvorumu pagrįstu protokolu, nustato stiprumo nuoseklumą, kurį gali palaikyti Zookeeper.
Paskirstytoje aplinkoje duomenų saugykla, atitinkanti stiprų nuoseklumą, iš esmės neegzistuoja, todėl atnaujinant vieno mazgo duomenis reikia sinchroniškai atnaujinti visus mazgus. Ši sinchronizavimo strategija rodoma sinchroninio replikavimo duomenų bazėje Master-Slave. Tačiau ši sinchronizavimo strategija turi per didelę įtaką rašymo našumui ir retai pastebima praktikoje. Kadangi Zookeeper rašo N/2+1 mazgus sinchroniškai, o N/2 mazgai nėra atnaujinami sinchroniškai, Zookeeper nėra labai nuoseklus.
Vartotojo duomenų atnaujinimo operacija negarantuoja, kad vėlesni skaitymai nuskaitys atnaujintą reikšmę, bet galiausiai parodys nuoseklumą. Paaukoti nuoseklumą nereiškia visiškai ignoruoti duomenų nuoseklumą, kitaip duomenys yra chaotiški, todėl nesvarbu, koks didelis sistemos prieinamumas, kad ir koks geras būtų paskirstymas, jis neturi jokios vertės. Nuoseklumo aukojimas yra tik tai, kad stiprus nuoseklumas reliacinėse duomenų bazėse nebereikalingas, bet tol, kol sistema gali pasiekti galutinį nuoseklumą.
Ar zoologijos sodo prižiūrėtojas atitinka priežastinį nuoseklumą, priklauso nuo to, kaip klientas yra užprogramuotas.
Priežastinio nuoseklumo neatitinkanti praktika
- A procesas įrašo duomenis į Zookeeper /z ir sėkmingai grįžta
- A procesas informuoja B procesą, kad A pakeitė /z duomenis
- B nuskaito zoologijos sodo prižiūrėtojo /z duomenis
- Kadangi prie B prijungto zoologijos sodo prižiūrėtojo serveris galėjo būti neatnaujintas A rašytiniais duomenimis, B negalės nuskaityti A rašytinių duomenų
Priežastinį nuoseklumą atitinkanti praktika
- B procesas klausosi duomenų pokyčių /z Zookeeper
- A procesas įrašo duomenis į zoologijos sodo prižiūrėtojo /z, o prieš sėkmingai grįžtant, zoologijos sodo prižiūrėtojas turi paskambinti klausytojui, užsiregistravusiam /z, o vadovas praneš B apie duomenų pasikeitimą
- Atsakius į B proceso įvykio reagavimo metodą, jis paima pakeistus duomenis, todėl B tikrai galės gauti pakeistą vertę
- Priežastinis nuoseklumas čia reiškia priežastinį nuoseklumą tarp "Leader" ir "B", t. y. vadovas praneša duomenims apie pokyčius
Antrasis įvykių klausymosi mechanizmas taip pat yra metodas, kuris turėtų būti naudojamas tinkamai programuoti Zookeeper, todėl Zookeeper turėtų atitikti priežastinį nuoseklumą
Todėl, kai diegiame paskirstytus užraktus, pagrįstus "Zookeeper", turėtume naudoti priežastinio nuoseklumo patenkinimo praktiką, tai yra, spynos laukiančios gijos klausosi "Zookeeper" užrakto pokyčių, o atleidus užraktą, "Zookeeper" praneš laukiančiajai gijai, atitinkančiai sąžiningo užrakto sąlygas.
Galite tiesiogiai naudoti "Zookeeper" trečiosios šalies bibliotekos klientą, kuris apima pakartotinio užrakto paslaugą.
Atrodo, kad paskirstytos spynos, įdiegtos naudojant ZK, tiksliai atitinka tai, ko tikėjomės iš paskirstyto užrakto šio straipsnio pradžioje. Tačiau taip nėra, o "Zookeeper" įdiegtas paskirstytas užraktas iš tikrųjų turi trūkumų, tai yra, našumas gali būti ne toks didelis kaip talpyklos paslaugos. Nes kiekvieną kartą kuriant ir atleidžiant užraktą, momentiniai mazgai turi būti dinamiškai sukurti ir sunaikinti, kad būtų galima realizuoti užrakto funkciją. ZK mazgų kūrimas ir ištrynimas gali būti atliekamas tik per lyderio serverį, o tada duomenys bendrinami su visais sekėjų įrenginiais.
"Zookeeper" naudojimo privalumai paskirstytoms spynoms įdiegti
Efektyviai spręskite vieno taško problemas, negrįžimo problemas, neblokavimo problemas ir užrakto nepavykimą atleisti. Tai gana paprasta įgyvendinti.
"Zookeeper" naudojimo paskirstytoms spynoms įgyvendinti trūkumai
Našumas nėra toks geras, kaip talpyklos naudojimas paskirstytiems užraktams įgyvendinti. Būtina suprasti ZK principus.
Trijų variantų palyginimas
Iš lengvo supratimo perspektyvos (nuo žemo iki aukšto)
Duomenų bazė > talpykla > Zookeeper
Įgyvendinimo sudėtingumo požiūriu (nuo mažo iki didelio)
"Zookeeper" > talpyklą > duomenų bazėse
Našumo požiūriu (nuo aukšto iki žemo)
Talpykla > Zookeeper >= duomenų bazė
Patikimumo požiūriu (nuo aukšto iki žemo)
"Zookeeper" > talpyklą > duomenų bazėse
|
Paskelbta 2018-08-30 15:04:32
|
|
|
|
Savininkas|
Paskelbta 2020-09-22 17:34:33
|
