J: Viens servisa serveris, viena datu bāze, operācija: vaicājiet lietotāja pašreizējo atlikumu, atskaitiet 3% no pašreizējā atlikuma kā apstrādes maksu
sinhronizēts
slēdzene
DB bloķēšana
J: Divi servisa serveri, viena datu bāze, operācija: vaicājiet lietotāja pašreizējo bilanci, atskaitiet 3% no pašreizējā atlikuma kā apstrādes maksu
Izplatītās slēdzenes
Kāda veida sadalīta slēdzene mums ir nepieciešama?
Tas var nodrošināt, ka izplatītā lietojumprogrammu klasterī to pašu metodi var izpildīt tikai ar vienu pavedienu vienā mašīnā vienlaicīgi.
Ja šī slēdzene ir atkārtota bloķēšana (izvairieties no strupceļa)
Šī slēdzene vislabāk ir bloķēšanas slēdzene (apsveriet, vai vēlaties to atbilstoši jūsu biznesa vajadzībām)
Šī slēdzene vislabāk ir godīga slēdzene (apsveriet, vai vēlaties šo vai nē atbilstoši biznesa vajadzībām)
Ir ļoti pieejamas iegūšanas un atbrīvošanas bloķēšanas funkcijas
Iegādes un atbrīvošanas slēdzeņu veiktspēja ir labāka
1. Izplatītas slēdzenes, kuru pamatā ir datu bāzes
Izkliedētas slēdzenes, kuru pamatā ir tabulas ieviešana
Kad mēs vēlamies bloķēt metodi, izpildiet šādu SQL:
ievietot methodLock(method_name,desc) vērtības ('method_name','desc')
Tā kā mēs esam izveidojuši method_name unikalitātes ierobežojumu, ja datu bāzē vienlaikus tiek iesniegti vairāki pieprasījumi, datu bāze nodrošinās, ka tikai viena operācija var būt veiksmīga, tad mēs varam pieņemt, ka pavediens, kas veiksmīgi ieguva metodes bloķēšanu un var izpildīt metodes pamatteksta saturu.
Kad metode tiek izpildīta, ja vēlaties atbrīvot slēdzeni, jums jāizpilda šāds Sql:
dzēst no metodesBloķēt, kur method_name ='method_name'
Šai vienkāršajai ieviešanai ir šādas problēmas:
- Šī bloķēšana ir atkarīga no datu bāzes pieejamības, kas ir viens punkts un izraisīs biznesa sistēmas nepieejamību, kad datu bāze ir uzlikta.
- Šai slēdzenei nav derīguma termiņa, un, tiklīdz atbloķēšanas operācija neizdodas, bloķēšanas ieraksts paliks datu bāzē un citi pavedieni vairs nevarēs iegūt slēdzeni.
- Šī bloķēšana var būt tikai nebloķējoša, jo datu ievietošanas operācija tieši ziņos par kļūdu, tiklīdz ievietošana neizdosies. Pavedieni, kas neiegūst slēdzenes, nenonāks rindā, un viņiem būs vēlreiz jāaktivizē bloķēšanas iegūšanas operācija, lai atkal iegūtu bloķēšanu.
- Slēdzene nav atkārtota, un tas pats pavediens nevar atkal iegūt slēdzeni, kamēr tas nav atbrīvots. Jo dati datos jau pastāv.
- Šī slēdzene ir negodīga slēdzene, un visi pavedieni, kas gaida slēdzeni, sacenšas par slēdzeni pēc veiksmes.
Protams, mēs varam atrisināt iepriekš minētās problēmas arī citos veidos.
- Vai datu bāze ir viens punkts? Izveidojiet divas datu bāzes, un dati tiks sinhronizēti abos virzienos. Kad esat piekarināts, ātri pārslēdzieties uz dublējuma bibliotēku.
- Nav derīguma termiņa? Vienkārši veiciet ieplānotu uzdevumu, lai regulāri iztīrītu taimauta datus datu bāzē.
- Nebloķē? Veiciet kādu cilpu, līdz ievietošana izdodas un pēc tam atgriežas panākumi.
- Vai neesat atkārtots? Pievienojiet datu bāzes tabulai lauku, lai ierakstītu resursdatora informāciju un pavediena informāciju par mašīnu, kas pašlaik saņem slēdzeni, pēc tam nākamajā reizē, kad saņemat slēdzeni, vispirms vaicājiet datu bāzē, ja datu bāzē var atrast pašreizējās mašīnas resursdatora informāciju un pavediena informāciju, varat tieši piešķirt slēdzeni viņam.
- Negodīgi? Izveidojiet vēl vienu starpposma tabulu, lai reģistrētu visus pavedienus, kas gaida slēdzeni, un kārtojiet tos pēc izveides laika, un tikai pirmais izveidotais ir atļauts iegūt slēdzeni
Izplatītas slēdzenes, kuru pamatā ir ekskluzīvas slēdzenes
Papildus ierakstu pievienošanai un dzēšanai datu tabulā, sadalītās slēdzenes var ieviest arī ar datu slēdzenēm.
Mēs izmantojam arī tikko izveidoto datu bāzes tabulu. Izplatītās slēdzenes var ieviest, izmantojot ekskluzīvas slēdzenes datubāzēs. MySQL bāzētā InnoDB programma var izmantot šādas metodes, lai īstenotu bloķēšanas operācijas:
Ja pievienojat atjaunināšanai pēc vaicājuma priekšraksta, datu bāze vaicājuma procesa laikā datu bāzes tabulai pievienos ekskluzīvu bloķēšanu. Kad ierakstam tiek pievienota ekskluzīva bloķēšana, citi pavedieni vairs nevar pievienot ekskluzīvu bloķēšanu ierakstam šajā rindā.
Mēs varam domāt, ka pavediens, kas iegūst ekskluzīvo slēdzeni, var iegūt sadalīto slēdzeni, un, kad slēdzene ir iegūta, metodes biznesa loģiku var izpildīt un pēc tam atbloķēt, izmantojot šādas metodes:
public void unlock(){ connection.commit(); }
caur connection.commit(); darbība, lai atbrīvotu slēdzeni.
Šī metode var efektīvi atrisināt iepriekš minētās problēmas par nespēju atbrīvot slēdzeni un bloķēt slēdzeni.
Bloķē slēdzenes? Priekšraksts for update atgriežas tūlīt pēc veiksmīgas izpildes un paliek bloķēts, līdz tas ir veiksmīgs.
Pakalpojums tiek pārtraukts pēc bloķēšanas, to nevar atbrīvot? Tādā veidā datu bāze pati atbrīvo slēdzeni pēc pakalpojuma pārtraukšanas.
Tomēr tas joprojām tieši neatrisina datu bāzes viena punkta, atkārtotas ieejas un godīgas bloķēšanas problēmu.
Apkopojot veidu, kā izmantot datu bāzi, lai ieviestu sadalītās slēdzenes, kas abas balstās uz datu bāzes tabulu, viens ir noteikt, vai ir bloķēšana pēc ierakstu esamības tabulā, un otrs ir ieviest sadalītās slēdzenes, izmantojot ekskluzīvo datu bāzes bloķēšanu.
Datu bāzu izkliedētās bloķēšanas priekšrocības
Tieši ar datu bāzes palīdzību tas ir viegli saprotams.
Izkliedēto slēdzeņu ieviešanas trūkumi datubāzēs
Būs dažādas problēmas, un viss risinājums problēmas risināšanas procesā kļūs arvien sarežģītāks.
Datu bāzes darbībai ir nepieciešamas noteiktas pieskaitāmās izmaksas, un ir jāapsver veiktspējas problēmas.
2. Izplatītas slēdzenes, pamatojoties uz kešatmiņu
Salīdzinot ar datu bāzes izkliedētās bloķēšanas risinājumu, kešatmiņas ieviešana darbosies labāk veiktspējas ziņā.
Šobrīd ir daudz nobriedušu kešatmiņas produktu, tostarp Redis, memcached utt. Šeit mēs ņemam Redis kā piemēru, lai analizētu kešatmiņas izmantošanas shēmu, lai ieviestu izplatītās slēdzenes.
Internetā ir daudz saistītu rakstu par izplatīto slēdzeņu ieviešanu, pamatojoties uz Redis, un galvenā īstenošanas metode ir izmantot Jedis.setNX metodi.
Ir arī vairākas problēmas ar iepriekš minēto ieviešanu:
1. Viena punkta problēma.
2. Šai slēdzenei nav derīguma termiņa, tiklīdz atbloķēšanas darbība neizdosies, bloķēšanas ieraksts visu laiku būs sarkans, un citi pavedieni vairs nevar iegūt slēdzeni.
3. Šī slēdzene var būt tikai nebloķējoša, un tā atgriezīsies tieši neatkarīgi no panākumiem vai neveiksmēm.
4. Šī slēdzene nav atkārtota, pēc tam, kad pavediens iegūst slēdzeni, tā nevar atkal iegūt slēdzeni pirms slēdzenes atbrīvošanas, jo izmantotā atslēga jau pastāv redis. setNX operācijas vairs nevar izpildīt.
5. Šī slēdzene ir negodīga, visi gaidīšanas pavedieni sāk setNX darbības vienlaicīgi, un laimīgie pavedieni var iegūt slēdzeni.
Protams, ir arī veidi, kā to atrisināt.
- Mūsdienās mainstream kešatmiņas pakalpojumi atbalsta klasteru izvietošanu, lai atrisinātu viena punkta problēmas, izmantojot klasterizāciju.
- Nav derīguma termiņa? Redis metode setExpire atbalsta ienākošo derīguma termiņu, un dati tiek automātiski izdzēsti pēc laika sasniegšanas.
- Nebloķē? atkārtoti izpildot.
- Vai nav iespējams atkārtoti piedalīties? Pēc tam, kad pavediens iegūst slēdzeni, saglabājiet pašreizējo resursdatora informāciju un pavediena informāciju un pārbaudiet, vai esat pašreizējās slēdzenes īpašnieks, pirms nākamreiz to iegūstat.
- Negodīgi? Ievietojiet visus gaidošos pavedienus rindā, pirms pavediens iegūst slēdzeni, un pēc tam iegūstiet slēdzeni pirmais iekšā, pirmais ārā.
Redis klastera sinhronizācijas politika aizņem laiku, un ir iespējams, ka pavediens A tiek bloķēts pēc veiksmīgas NX iestatīšanas, bet šī vērtība nav atjaunināta serverī, kur pavediens B izpilda setNX, kas radīs vienlaicīgas problēmas.
Salvatore Sanfilippo, redis autors, ierosināja Redlock algoritmu, kas īsteno izkliedēto bloķēšanas pārvaldību (DLM), kas ir drošāka un uzticamāka nekā viens mezgls.
Redlock algoritms pieņem, ka ir N redis mezgli, kas ir neatkarīgi viens no otra, parasti iestatīti uz N=5, un šie N mezgli darbojas dažādās mašīnās, lai saglabātu fizisko neatkarību.
Algoritma darbības ir šādas:
1. Klients iegūst pašreizējo laiku milisekundēs.
2. Klients mēģina iegūt N mezglu bloķēšanu (katrs mezgls saņem slēdzeni tādā pašā veidā kā iepriekš minētā kešatmiņas bloķēšana), un N mezgli iegūst slēdzeni ar tādu pašu atslēgu un vērtību. Klientam ir jāiestata interfeisa piekļuves taimauts, un interfeisa taimauta laikam jābūt daudz mazākam par bloķēšanas taimautu, piemēram, bloķēšanas automātiskās atbrīvošanas laiks ir 10 sekundes, tad interfeisa taimauts ir iestatīts uz aptuveni 5-50 ms. Tas ļauj pēc iespējas ātrāk izslēgt taimautu, piekļūstot redis mezglam pēc tā nolaišanās, un samazina slēdzenes normālu izmantošanu.
3. Klients aprēķina, cik daudz laika nepieciešams slēdzenes iegūšanai, atņemot 1. solī iegūto laiku ar pašreizējo laiku, tikai tad, kad klients iegūst vairāk nekā 3 slēdzenes mezglus, un slēdzenes iegūšanas laiks ir mazāks par slēdzenes taimauta laiku, klients iegūst sadalīto slēdzeni.
4. Klienta bloķēšanas iegūšanas laiks ir iestatītais bloķēšanas taimauta laiks, no kura atskaitīts laiks, kas patērēts, lai iegūtu slēdzeni, kas aprēķināts 3. solī.
5. Ja klientam neizdodas iegūt slēdzeni, klients izdzēš visas slēdzenes pēc kārtas.
Izmantojot Redlock algoritmu, var garantēt, ka izplatītais bloķēšanas pakalpojums joprojām var darboties, piekārt līdz 2 mezgliem, kas ievērojami uzlabo pieejamību salīdzinājumā ar iepriekšējo datu bāzes bloķēšanu un kešatmiņas bloķēšanu.
Tomēr izplatītais eksperts uzrakstīja rakstu "Kā veikt sadalīto bloķēšanu", apšaubot Redlock pareizību.
Eksperts minēja, ka, apsverot sadalītās slēdzenes, jāņem vērā divi aspekti: veiktspēja un pareizība.
Ja izmantojat augstas veiktspējas izkliedētu bloķēšanu un pareizība nav nepieciešama, pietiek ar kešatmiņas bloķēšanu.
Ja izmantojat ļoti uzticamu sadalīto slēdzeni, jums jāapsver stingri uzticamības jautājumi. Redlock, no otras puses, neatbilst pareizībai. Kāpēc ne? Eksperti uzskaita vairākus aspektus.
Mūsdienās daudzas programmēšanas valodas izmanto virtuālās mašīnas ar GC funkcijām, Full GC programma pārtrauks GC apstrādi, dažreiz Full GC aizņem ilgu laiku, un pat programmai ir dažas minūtes kavēšanās, rakstā ir uzskaitīts HBase, HBase dažreiz GC piemērs dažas minūtes, kas izraisīs nomas taimautu. Piemēram, zemāk redzamajā attēlā klients 1 saņem bloķēšanu un gatavojas apstrādāt koplietojamo resursu, un, kad tas gatavojas apstrādāt koplietojamo resursu, pilns GC notiek līdz bloķēšanas termiņa beigām. Tādā veidā klients 2 atkal saņem bloķēšanu un sāk strādāt ar koplietojamo resursu. Kad 2. klients apstrādā, 1. klients pabeidz pilnu GC un sāk apstrādāt koplietojamos resursus, lai abi klienti apstrādātu koplietojamos resursus.
Eksperti sniedza risinājumu, kā parādīts zemāk redzamajā attēlā, tas izskatās kā MVCC, nogādājiet žetonu slēdzenē, marķieris ir versijas jēdziens, katru reizi, kad operācijas bloķēšana ir pabeigta, marķieris tiks pievienots 1, nogādājiet marķieri, apstrādājot koplietojamos resursus, tikai norādītā marķiera versija var apstrādāt koplietojamo resursu.
Tad eksperts arī teica, ka algoritms balstās uz vietējo laiku un ka Redis paļaujas uz getTimeOfDay metodi, lai iegūtu laiku, nevis monotonu pulksteni, apstrādājot atslēgas derīguma termiņu, kas arī noved pie laika neprecizitātēm. Piemēram, scenārijā diviem 1. klientam un 2. klientam ir 5 redis mezgli (A, B, C, D un E).
1. Klients 1 veiksmīgi iegūst slēdzeni no A, B un C un iegūst bloķēšanas tīkla taimautu no D un E.
2. Mezgla C pulkstenis ir neprecīzs, izraisot bloķēšanas taimautu.
3. 2. klients veiksmīgi iegūst slēdzeni no C, D un E un iegūst bloķēšanas tīkla taimautu no A un B.
4. Tādā veidā gan 1. klients, gan 2. klients saņem slēdzeni.
Apkopojot divus punktus, eksperti saka par Redlock nepieejamību:
1. GC un citi scenāriji var rasties jebkurā laikā, izraisot klienta bloķēšanu, un apstrādes taimauts liek citam klientam iegūt bloķēšanu. Eksperti arī sniedza risinājumu pašpalielinošu žetonu izmantošanai.
2. Algoritms balstās uz vietējo laiku, un pulkstenis būs neprecīzs, kā rezultātā divi klienti vienlaicīgi saņems slēdzenes.
Tāpēc ekspertu secinājums ir tāds, ka Redlock var normāli darboties tikai ierobežotā tīkla aizkavē, ierobežotā programmas pārtraukumā un ierobežotā pulksteņa kļūdu diapazonā, taču šo trīs scenāriju robežas nevar apstiprināt, tāpēc eksperti neiesaka izmantot Redlock. Scenārijiem ar augstām pareizības prasībām eksperti iesaka Zookeeper, kas tiks apspriests vēlāk, izmantojot Zookeeper kā izplatītu slēdzeni.
Atbilde no Redis autora
Redis autors atbildēja, rakstot emuāru pēc eksperta raksta redzēšanas. Autors pieklājīgi pateicās ekspertam un pēc tam pauda nepiekrišanu eksperta viedoklim.
REDIS autora diskusiju par marķieru izmantošanu bloķēšanas taimauta problēmas risināšanai var apkopot šādos piecos punktos:
1. punkts, sadalīto slēdzeņu izmantošana parasti ir tāda, ka jums nav cita veida, kā kontrolēt koplietojamos resursus, eksperti izmanto žetonus, lai nodrošinātu koplietojamo resursu apstrādi, tad nav nepieciešamas sadalītas slēdzenes.
2. punkts: lai nodrošinātu dažādu klientu iegūto žetonu uzticamību, pakalpojumam, kas ģenerē žetonus, joprojām ir nepieciešamas izkliedētas slēdzenes, lai nodrošinātu pakalpojuma uzticamību.
3. punkts, par to, kā eksperti saka, ka pašpalielinoši žetoni, redis autors uzskata, ka tas ir pilnīgi nevajadzīgi, katrs klients var ģenerēt unikālu uuid kā marķieru un iestatīt koplietojamo resursu tādā stāvoklī, ko var apstrādāt tikai klients ar uuid, lai citi klienti nevarētu apstrādāt koplietojamo resursu, kamēr klients, kas iegūst slēdzeni, neatlaiž slēdzeni.
Kā parādīts iepriekš redzamajā attēlā, ja 34. marķiera klients rakstīšanas procesa laikā nosūta GC un izraisa bloķēšanas taimautu, cits klients var iegūt 35. marķiera bloķēšanu un sākt rakstīt no jauna, kā rezultātā rodas bloķēšanas konflikts. Tāpēc žetonu secību nevar apvienot ar kopīgiem resursiem.
5. punkts, redis autors uzskata, ka lielākajā daļā scenāriju izkliedētās slēdzenes tiek izmantotas, lai risinātu atjaunināšanas problēmas ar darījumiem nesaistītos scenārijos. Autoram vajadzētu domāt, ka ir daži scenāriji, kad ir grūti apvienot žetonus, lai apstrādātu koplietojamos resursus, tāpēc jums ir jāpaļaujas uz slēdzenēm, lai bloķētu resursus un tos apstrādātu.
Vēl viena pulksteņa problēma, par kuru runā eksperti, Redis autori arī sniedz skaidrojumu. Ja slēdzenes iegūšanai nepieciešamais laiks ir pārāk ilgs un pārsniedz slēdzenes noklusējuma taimauta laiku, tad klients šobrīd nevar iegūt slēdzeni, un eksperti nepiedāvās piemērus.
Personīgās jūtas
Pirmā problēma, ko es apkopoju, ir tāda, ka pēc tam, kad klients iegūst sadalītu slēdzeni, bloķēšana var tikt atbrīvota pēc taimauta klienta apstrādes laikā. Agrāk, runājot par 2 minūšu datu bāzes bloķēšanas iestatīto taimautu, ja uzdevums aizņem pasūtījuma bloķēšanu ilgāk par 2 minūtēm, tad otrs tirdzniecības centrs var iegūt šo pasūtījuma bloķēšanu, lai abi tirdzniecības centri vienlaikus varētu apstrādāt vienu un to pašu pasūtījumu. Normālos apstākļos uzdevums tiek apstrādāts dažu sekunžu laikā, bet dažreiz taimauts, kas iestatīts, pievienojoties RPC pieprasījumam, ir pārāk ilgs, un uzdevumā ir vairāki šādi taimauta pieprasījumi, tad ir iespējams, ka automātiskās atbloķēšanas laiks tiks pārsniegts. Ja mēs rakstām java, vidū var būt pilns GC, tāpēc pēc bloķēšanas taimauta klients to nevar uztvert, kas ir ļoti nopietna lieta. Es nedomāju, ka tā ir problēma ar pašu slēdzeni, ja vien jebkurai iepriekš minētajai sadalītajai bloķēšanai ir taimauta atbrīvošanas īpašības, šāda problēma radīsies. Ja izmantojat bloķēšanas taimauta funkciju, klientam ir jāiestata bloķēšanas taimauts un attiecīgi jārīkojas, nevis jāturpina apstrādāt koplietojamo resursu. Redlock algoritms atgriež bloķēšanas laiku, ko klients var aizņemt pēc tam, kad klients iegūst slēdzeni, un klientam šis laiks ir jāapstrādā, lai apturētu uzdevumu pēc šī laika.
Otra problēma ir tā, ka izplatītie eksperti nesaprot Redlock. Redlock galvenā iezīme ir tā, ka slēdzenes iegūšanas laiks ir kopējais laiks, kad slēdzene pēc noklusējuma ir taimauts, atskaitot laiku, kas nepieciešams slēdzenes iegūšanai, lai klients apstrādātu relatīvu laiku neatkarīgi no vietējā laika.
No šī viedokļa Redlock pareizību var labi garantēt. Rūpīga Redlock analīze, salīdzinot ar mezgla redis, galvenā Redlock nodrošinātā iezīme ir augstāka uzticamība, kas ir svarīga iezīme dažos scenārijos. Bet es domāju, ka Redlock ir iztērējis pārāk daudz naudas, lai sasniegtu uzticamību.
- Pirmkārt, ir jāizvieto 5 mezgli, lai padarītu Redlock uzticamāku.
- Tad jums ir jāpieprasa 5 mezgli, lai iegūtu slēdzeni, un, izmantojot nākotnes metodi, vispirms varat pieprasīt 5 mezglus vienlaicīgi un pēc tam iegūt atbildes rezultātu kopā, kas var saīsināt reakcijas laiku, taču tas joprojām aizņem vairāk laika nekā viena mezgla redis bloķēšana.
- Tad, tā kā ir jāiegūst vairāk nekā 3 no 5 mezgliem, var rasties bloķēšanas konflikts, tas ir, visi ir ieguvuši 1-2 slēdzenes, un rezultātā neviens nevar iegūt slēdzeni, šī problēma, Redis autors aizņemas plosta algoritma būtību, izmantojot sadursmi nejaušā laikā, konflikta laiku var ievērojami samazināt, taču no šīs problēmas nevar izvairīties ļoti labi, it īpaši, ja slēdzene tiek iegādāta pirmo reizi, tāpēc slēdzenes iegādes laika izmaksas palielinās.
- Ja 2 no 5 mezgliem ir uz leju, slēdzenes pieejamība ievērojami samazināsies, pirmkārt, pirms atgriešanās jums jāgaida šo divu nolaisto mezglu rezultāti, un ir tikai 3 mezgli, un klientam ir jāiegūst visu 3 mezglu slēdzenes, lai būtu slēdzene, kas arī ir grūtāk.
- Ja ir tīkla nodalījums, tad var rasties situācija, kad klients nekad nevarēs iegūt slēdzeni.
Analizējot tik daudzus iemeslus, es domāju, ka Redlock problēmas kritiskākais punkts ir tas, ka Redlock pieprasa klientiem nodrošināt rakstīšanas konsekvenci, un aizmugures 5 mezgli ir pilnīgi neatkarīgi, un visiem klientiem ir jādarbojas šie 5 mezgli. Ja starp 5 mezgliem ir līderis, klients var sinhronizēt līdera datus tik ilgi, kamēr klients iegūst slēdzeni no līdera, lai nerastos tādas problēmas kā sadalīšana, taimauts un konflikti. Tāpēc, lai nodrošinātu sadalīto slēdzeņu pareizību, es domāju, ka izkliedēta koordinācijas pakalpojuma izmantošana ar spēcīgu konsekvenci var labāk atrisināt problēmu.
Atkal rodas jautājums, cik ilgi man vajadzētu iestatīt derīguma termiņu? Kā iestatīt anulēšanas laiku ir pārāk īss, un bloķēšana tiek automātiski atbrīvota pirms metodes izpildes, tad radīsies vienlaicīgas problēmas. Ja tas aizņem pārāk ilgu laiku, citiem pavedieniem, kas iegūst slēdzeni, var nākties gaidīt ilgu laiku.
Šī problēma pastāv arī ar datu bāzu izmantošanu, lai ieviestu izplatītas slēdzenes.
Pašreizējā galvenā pieeja šai problēmai ir iestatīt īsu taimauta laiku katrai iegūtajai bloķēšanai un sākt pavedienu, lai atsvaidzinātu bloķēšanas taimauta laiku katru reizi, kad tas tuvojas taimautam. Beidziet šo pavedienu vienlaicīgi ar slēdzenes atbrīvošanu. Piemēram, redisson, oficiālais izplatītais redis bloķēšanas komponents, izmanto šo risinājumu.
Kešatmiņas izmantošanas priekšrocības, lai ieviestu sadalītās slēdzenes
Labs sniegums.
Kešatmiņas izmantošanas trūkumi, lai ieviestu sadalītās slēdzenes
Īstenošana ir pārāk atbildīga, ir pārāk daudz faktoru, kas jāņem vērā.
Izplatītas slēdzenes, kuru pamatā ir Zookeeper ieviešana
Izplatītas slēdzenes, kuru pamatā ir Zookeeper pagaidu pasūtītie mezgli.
Vispārējā ideja ir tāda, ka, kad katrs klients bloķē metodi, norādītā mezgla direktorijā tiek ģenerēts unikāls tūlītējs pasūtīts mezgls, kas atbilst zookeeper metodei. Veids, kā noteikt, vai iegūt slēdzeni, ir vienkāršs, jums ir jānosaka tikai tas, kam ir mazākais sērijas numurs pasūtītajā mezglā. Kad slēdzene ir atbrīvota, vienkārši izdzēsiet momentāno mezglu. Tajā pašā laikā tas var izvairīties no strupceļa problēmas, ko izraisa pakalpojumu dīkstāve, kuru nevar atbrīvot.
Redzēsim, vai Zookeeper var atrisināt iepriekš minētās problēmas.
- Slēdzene netiek atbrīvota? Izmantojot Zookeeper, var efektīvi atrisināt slēdzeņu neatbrīvošanas problēmu, jo, veidojot slēdzeni, klients izveidos pagaidu mezglu ZK, un, tiklīdz klients iegūst slēdzeni un pēkšņi to pakārt (sesijas savienojums ir pārtraukts), tad pagaidu mezgls tiks automātiski izdzēsts. Citi klienti var atkal iegūt slēdzeni.
- Nebloķējošas slēdzenes? Kad mezgls mainās, Zookeeper paziņos klientam, un klients var pārbaudīt, vai tā izveidotais mezgls ir mazākais kārtas skaitlis starp visiem mezgliem.
- Vai nevarat atkārtoti piedalīties? Kad klients izveido mezglu, tas tieši raksta pašreizējā klienta resursdatora informāciju un pavediena informāciju mezglā, un nākamajā reizē, kad vēlaties iegūt slēdzeni, varat to salīdzināt ar datiem pašreizējā mazākajā mezglā. Ja informācija ir tāda pati kā jūsu, tad jūs varat tieši iegūt slēdzeni, un, ja tā ir atšķirīga, izveidojiet pagaidu secīgu mezglu, lai piedalītos rindā.
Atkal rodas jautājums, mēs zinām, ka Zookeeper ir jāizvieto klasteros, vai būs datu sinhronizācijas problēmas, piemēram, Redis klasteri?
Zookeeper ir izplatīts komponents, kas garantē vāju konsekvenci, t.i., iespējamo konsekvenci.
Zookeeper izmanto datu sinhronizācijas protokolu, ko sauc par kvoruma protokolu. Ja Zookeeper klasterī ir N Zookeeper serveri (N parasti ir nepāra, 3 var atbilst datu uzticamībai un ir augsta lasīšanas un rakstīšanas veiktspēja, un 5 ir vislabākais līdzsvars starp datu uzticamību un lasīšanas un rakstīšanas veiktspēju), tad lietotāja rakstīšanas operācija vispirms tiek sinhronizēta ar N/2 + 1 serveriem un pēc tam atgriezta lietotājam, mudinot lietotāju veiksmīgi rakstīt. Datu sinhronizācijas protokols, kas balstīts uz kvoruma protokolu, nosaka spēka konsekvenci, ko Zookeeper var atbalstīt.
Izkliedētā vidē datu glabāšana, kas atbilst spēcīgai konsekvencei, būtībā neeksistē, un, atjauninot viena mezgla datus, visi mezgli ir jāatjaunina sinhroni. Šī sinhronizācijas stratēģija tiek parādīta sinhronās replicēšanas datu bāzē master-slave. Tomēr šai sinhronizācijas stratēģijai ir pārāk liela ietekme uz rakstīšanas veiktspēju, un tā ir reti redzama praksē. Tā kā Zookeeper raksta N/2+1 mezglus sinhroni, un N/2 mezgli netiek atjaunināti sinhroni, Zookeeper nav spēcīgi konsekvents.
Lietotāja datu atjaunināšanas operācija negarantē, ka turpmākie lasījumi nolasīs atjaunināto vērtību, bet galu galā parādīs konsekvenci. Konsekvences upurēšana nenozīmē pilnīgu datu konsekvences ignorēšanu, pretējā gadījumā dati ir haotiski, tāpēc neatkarīgi no tā, cik augsta ir sistēmas pieejamība, neatkarīgi no tā, cik labs ir sadalījums, tam nav nekādas vērtības. Konsekvences upurēšana ir tikai tāda, ka relāciju datu bāzēs vairs nav nepieciešama spēcīga konsekvence, bet tik ilgi, kamēr sistēma var sasniegt iespējamo konsekvenci.
Viena punkta jautājums? Izmantojot Zookeeper, var efektīvi atrisināt viena punkta problēmu, ZK tiek izvietots klasteros, kamēr vairāk nekā puse no klastera mašīnām izdzīvo, pakalpojumu var sniegt ārpasaulei.
Taisnīguma jautājumi? Izmantojot Zookeeper, var atrisināt godīgu slēdzeņu problēmu, klienta izveidotie pagaidu mezgli ZK ir sakārtoti, un katru reizi, kad slēdzene tiek atbrīvota, ZK var paziņot mazākajam mezglam, lai iegūtu slēdzeni, nodrošinot taisnīgumu.
Atkal rodas jautājums, mēs zinām, ka Zookeeper ir jāizvieto klasteros, vai būs datu sinhronizācijas problēmas, piemēram, Redis klasteri?
Zookeeper ir izplatīts komponents, kas garantē vāju konsekvenci, t.i., iespējamo konsekvenci.
Zookeeper izmanto datu sinhronizācijas protokolu, ko sauc par kvoruma protokolu. Ja Zookeeper klasterī ir N Zookeeper serveri (N parasti ir nepāra, 3 var atbilst datu uzticamībai un ir augsta lasīšanas un rakstīšanas veiktspēja, un 5 ir vislabākais līdzsvars starp datu uzticamību un lasīšanas un rakstīšanas veiktspēju), tad lietotāja rakstīšanas operācija vispirms tiek sinhronizēta ar N/2 + 1 serveriem un pēc tam atgriezta lietotājam, mudinot lietotāju veiksmīgi rakstīt. Datu sinhronizācijas protokols, kas balstīts uz kvoruma protokolu, nosaka spēka konsekvenci, ko Zookeeper var atbalstīt.
Izkliedētā vidē datu glabāšana, kas atbilst spēcīgai konsekvencei, būtībā neeksistē, un, atjauninot viena mezgla datus, visi mezgli ir jāatjaunina sinhroni. Šī sinhronizācijas stratēģija tiek parādīta sinhronās replicēšanas datu bāzē master-slave. Tomēr šai sinhronizācijas stratēģijai ir pārāk liela ietekme uz rakstīšanas veiktspēju, un tā ir reti redzama praksē. Tā kā Zookeeper raksta N/2+1 mezglus sinhroni, un N/2 mezgli netiek atjaunināti sinhroni, Zookeeper nav spēcīgi konsekvents.
Lietotāja datu atjaunināšanas operācija negarantē, ka turpmākie lasījumi nolasīs atjaunināto vērtību, bet galu galā parādīs konsekvenci. Konsekvences upurēšana nenozīmē pilnīgu datu konsekvences ignorēšanu, pretējā gadījumā dati ir haotiski, tāpēc neatkarīgi no tā, cik augsta ir sistēmas pieejamība, neatkarīgi no tā, cik labs ir sadalījums, tam nav nekādas vērtības. Konsekvences upurēšana ir tikai tāda, ka relāciju datu bāzēs vairs nav nepieciešama spēcīga konsekvence, bet tik ilgi, kamēr sistēma var sasniegt iespējamo konsekvenci.
Tas, vai Zookeeper atbilst cēloņsakarībai, ir atkarīgs no tā, kā klients ir ieprogrammēts.
Prakse, kas neatbilst cēloņsakarībai
- Process A ieraksta datus uz Zookeeper /z un veiksmīgi atgriežas
- Process A informē procesu B, ka A ir modificējis /z datus
- B nolasa zoodārza uzturētāja /z datus
- Tā kā Zookeeper serveris, kas savienots ar B, iespējams, nav atjaunināts ar A rakstītajiem datiem, tad B nevarēs nolasīt A rakstītos datus
Prakses, kas atbilst cēloņsakarībai
- B process klausās datu izmaiņas /z vietnē Zookeeper
- Process A ieraksta datus uz Zookeeper /z, un pirms tas veiksmīgi atgriežas, Zookeeper ir jāpiezvana klausītājam, kas reģistrēts /z, un vadītājs paziņos B par datu izmaiņām
- Pēc tam, kad tiek atbildēta uz B procesa notikuma reakcijas metodi, tā ņem mainītos datus, tāpēc B noteikti varēs iegūt mainīto vērtību
- Cēloņsakarība šeit attiecas uz cēloņsakarību starp Leader un B, tas ir, līderis paziņo datus par izmaiņām
Otrais notikumu klausīšanās mehānisms ir arī metode, kas jāizmanto, lai pareizi programmētu Zookeeper, tāpēc Zookeeper jāatbilst cēloņsakarībai
Tāpēc, ieviešot sadalītās slēdzenes, kuru pamatā ir Zookeeper, mums jāizmanto cēloņsakarības konsekvences apmierināšanas prakse, tas ir, pavedieni, kas gaida slēdzeni, klausās izmaiņas Zookeeper slēdzenē, un, kad slēdzene tiek atbrīvota, Zookeeper paziņos gaidīšanas pavedienam, kas atbilst godīgiem bloķēšanas nosacījumiem.
Jūs varat tieši izmantot Zookeeper trešās puses bibliotēkas klientu, kas ietver atkārtotu bloķēšanas pakalpojumu.
Šķiet, ka izkliedētās slēdzenes, kas ieviestas ar ZK, atbilst tieši tam, ko mēs gaidījām no izplatītās slēdzenes šī raksta sākumā. Tomēr tā nav, un Zookeeper ieviestajai izkliedētajai bloķēšanai faktiski ir trūkums, tas ir, veiktspēja var nebūt tik augsta kā kešatmiņas pakalpojumam. Tā kā katru reizi, veidojot un atbrīvojot slēdzeni, momentānie mezgli ir dinamiski jāizveido un jāiznīcina, lai realizētu bloķēšanas funkciju. Mezglu izveidi un dzēšanu ZK var veikt tikai caur līdera serveri, un pēc tam dati tiek kopīgoti ar visām sekotāju mašīnām.
Zookeeper izmantošanas priekšrocības, lai ieviestu izkliedētas slēdzenes
Efektīvi atrisināt viena punkta problēmas, neatgriešanās problēmas, nebloķēšanas problēmas un bloķēšanas neveiksmi. Tas ir salīdzinoši vienkārši īstenojams.
Zookeeper izmantošanas trūkumi, lai ieviestu izkliedētas slēdzenes
Veiktspēja nav tik laba kā kešatmiņas izmantošana, lai ieviestu sadalītās slēdzenes. Nepieciešama izpratne par ZK principiem.
Trīs iespēju salīdzinājums
No vieglas izpratnes viedokļa (no zemas līdz augstai)
Datu bāze > kešatmiņa > Zookeeper
No īstenošanas sarežģītības viedokļa (no zemas līdz augstai)
Zookeeper > kešatmiņa > datubāzēs
No veiktspējas viedokļa (no augsta uz zemu)
Kešatmiņa > Zookeeper >= datu bāze
No uzticamības viedokļa (no augsta līdz zemam)
Zookeeper > kešatmiņa > datubāzēs
|
Publicēts 30.08.2018 15:04:32
|
|
|
|
Saimnieks|
Publicēts 22.09.2020 17:34:33
|
