ProHoster > Blogs > Administrācija > SadalÄ«ta bloÄ·Ä“Å”ana, izmantojot Redis

Sadalīta bloķēŔana, izmantojot Redis

Čau Habr!

Å odien mēs piedāvājam jÅ«su uzmanÄ«bai sarežģīta raksta tulkojumu par izplatÄ«tās bloÄ·Ä“Å”anas ievieÅ”anu, izmantojot Redis, un aicinām jÅ«s runāt par Redis izredzēm kā tēmu. AttiecÄ«gā Redloka algoritma analÄ«ze no Martina Klepmana, grāmatas autora "Lietojumprogrammas ar lielu slodzi", dota Å”eit.

SadalÄ«tā bloÄ·Ä“Å”ana ir ļoti noderÄ«gs primitÄ«vs lÄ«dzeklis, ko izmanto daudzās vidēs, kur dažādiem procesiem ir jādarbojas ar kopÄ«giem resursiem, savstarpēji izslēdzot.

Ir vairākas bibliotēkas un ziņas, kurās aprakstÄ«ts, kā ieviest DLM (Distributed Lock Manager), izmantojot Redis, taču katrai bibliotēkai ir atŔķirÄ«ga pieeja, un to sniegtās garantijas ir diezgan vājas, salÄ«dzinot ar to, kas ir sasniedzams ar nedaudz sarežģītāku dizainu.

Å ajā rakstā mēs mēģināsim aprakstÄ«t nosacÄ«to kanonisko algoritmu, kas parāda, kā Ä«stenot izplatÄ«to bloÄ·Ä“Å”anu, izmantojot Redis. Mēs runāsim par algoritmu, ko sauc Redlock, tas ievieÅ” izplatÄ«tu bloÄ·Ä“Å”anas pārvaldnieku, un, mÅ«suprāt, Å”is algoritms ir droŔāks par parasto vienas instances pieeju. Mēs ceram, ka kopiena to analizēs, sniegs atsauksmes un izmantos to kā sākumpunktu sarežģītākiem vai alternatÄ«viem projektiem.

ÄŖstenoÅ”ana

Pirms pāriet uz algoritma aprakstu, mēs sniedzam vairākas saites uz gatavām implementācijām. Tos var izmantot atsaucei.

DroŔības un pieejamības garantijas

Mēs modelēsim savu dizainu tikai ar trim Ä«paŔībām, kas, mÅ«suprāt, nodroÅ”ina minimālās garantijas, kas nepiecieÅ”amas, lai efektÄ«vi izmantotu sadalÄ«to bloÄ·Ä“Å”anu.

  1. DroŔības Ä«paÅ”ums: savstarpēja izslēgÅ”ana. Jebkurā laikā slēdzeni var turēt tikai viens klients.
  2. PieejamÄ«bas rekvizÄ«ts A: nav strupceļu. Vienmēr ir iespējams iegÅ«t bloÄ·Ä“Å”anu, pat ja klients, kurÅ” bloķēja resursu, neizdodas vai nonāk citā diska segmentā.
  3. Pieejamības rekvizīts B: kļūdu tolerance. Kamēr lielākā daļa Redis mezglu darbojas, klienti var iegūt un atbrīvot slēdzenes.

Kāpēc Å”ajā gadÄ«jumā nepietiek ar ievieÅ”anu, kuras pamatā ir kļūmes atgÅ«Å”ana
Lai saprastu, ko mēs uzlabosim, analizēsim paÅ”reizējo situāciju ar lielāko daļu izplatÄ«to bloÄ·Ä“Å”anas bibliotēku, kuras pamatā ir Redis.

VienkārŔākais veids, kā bloķēt resursu, izmantojot Redis, ir izveidot atslēgu instancē. Parasti atslēga tiek izveidota ar ierobežotu kalpoÅ”anas laiku, tas tiek panākts, izmantojot Redis piedāvāto derÄ«guma termiņa funkciju, tāpēc agrāk vai vēlāk Ŕī atslēga tiek atbrÄ«vota (mÅ«su sarakstā 2. rekvizÄ«ts). Kad klientam ir jāatbrÄ«vo resurss, tas izdzÄ“Å” atslēgu.

No pirmā acu uzmetiena Å”is risinājums darbojas diezgan labi, taču pastāv problēma: mÅ«su arhitektÅ«ra rada vienu neveiksmes punktu. Kas notiek, ja resursdatora Redis instance neizdodas? Pieliksim tad vergu! Un mēs to izmantosim, ja vadÄ«tājs nebÅ«s pieejams. Diemžēl Ŕī iespēja nav piemērota. To darot, mēs nevarēsim pareizi ieviest savstarpējās izslēgÅ”anas Ä«paÅ”umu, kas mums nepiecieÅ”ams, lai nodroÅ”inātu droŔību, jo replikācija programmā Redis ir asinhrona.

ŠžŃ‡ŠµŠ²ŠøŠ“Š½Š¾, чтŠ¾ Š² тŠ°ŠŗŠ¾Š¹ Š¼Š¾Š“ŠµŠ»Šø Š²Š¾Š·Š½ŠøŠŗŠ°ŠµŃ‚ сŠ¾ŃŃ‚Š¾ŃŠ½ŠøŠµ Š³Š¾Š½ŠŗŠø:

  1. Klients A iegūst kapteiņa slēdzeni.
  2. Galvenā ierīce neizdodas, pirms atslēgas ievade tiek pārsūtīta uz slavenu ierīci.
  3. Sekotājs tiek paaugstināts par vadītāju.
  4. Klients B iegÅ«st bloÄ·Ä“Å”anu tam paÅ”am resursam, kuru A jau ir bloķējis. DROÅ ÄŖBAS PĀRKĀPJUMS!

Dažreiz ir pilnÄ«gi normāli, ka Ä«paÅ”os apstākļos, piemēram, kļūmes gadÄ«jumā, daudzi klienti var vienlaikus turēt slēdzeni. Šādos gadÄ«jumos var izmantot uz replikāciju balstÄ«tu risinājumu. Pretējā gadÄ«jumā mēs iesakām Å”ajā rakstā aprakstÄ«to risinājumu.

Pareiza ievieŔana ar vienu gadījumu

Pirms mēģināt pārvarēt iepriekÅ” aprakstÄ«tās vienas instances konfigurācijas trÅ«kumus, sapratÄ«sim, kā pareizi rÄ«koties ar Å”o vienkārÅ”o gadÄ«jumu, jo Å”is risinājums faktiski ir derÄ«gs lietojumprogrammās, kurās laiku pa laikam ir pieņemams sacensÄ«bu nosacÄ«jums, kā arÄ« tāpēc, ka tiek bloķēta viens gadÄ«jums kalpo par pamatu, kas tiek izmantots Å”eit aprakstÄ«tajā izplatÄ«tajā algoritmā.

Lai iegÅ«tu slēdzeni, rÄ«kojieties Ŕādi:

SET resource_name my_random_value NX PX 30000

Å Ä« komanda instalē atslēgu tikai tad, ja tā vēl nepastāv (opcija NX) ar derÄ«guma periodu 30000 XNUMX milisekundes (PX opcija). TaustiņŔ ir iestatÄ«ts uz ā€œmyrandomvalue" Å ai vērtÄ«bai ir jābÅ«t unikālai visiem klientiem un visiem bloÄ·Ä“Å”anas pieprasÄ«jumiem.
Pamatā, lai droÅ”i atbrÄ«votu slēdzeni, tiek izmantota nejauÅ”a vērtÄ«ba, un skripts norāda Redis: noņemiet atslēgu tikai tad, ja tā pastāv un tajā saglabātā vērtÄ«ba ir tieÅ”i tāda, kāda tika gaidÄ«ta. Tas tiek panākts, izmantojot Ŕādu Lua skriptu:

if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

Tas ir svarÄ«gi, lai novērstu cita klienta turētas slēdzenes noņemÅ”anu. Piemēram, klients var iegÅ«t slēdzeni, pēc tam tikt bloķēts kādā darbÄ«bā, kas ilgst ilgāk nekā pirmā slēdzene (lai atslēgai bÅ«tu laiks beigties), un vēlāk noņemt slēdzeni, ko bija ievietojis kāds cits klients.
VienkārÅ”as DEL izmantoÅ”ana nav droÅ”a, jo klients var noņemt cita klienta bloÄ·Ä“Å”anu. Turpretim, izmantojot iepriekÅ” minēto skriptu, katra slēdzene tiek ā€œparakstÄ«taā€ ar nejauÅ”u virkni, tāpēc to var noņemt tikai klients, kurÅ” to iepriekÅ” ievietoja.

Kādai vajadzētu bÅ«t Å”ai nejauÅ”ajai virknei? Es domāju, ka tai vajadzētu bÅ«t 20 baiti no /dev/urandom, taču jÅ«s varat atrast lētākus veidus, kā padarÄ«t virkni pietiekami unikālu saviem mērÄ·iem. Piemēram, bÅ«tu pareizi sēt RC4 ar /dev/urandom un pēc tam no tā Ä£enerēt pseidogadÄ«juma straumi. VienkārŔāks risinājums ietver unix laika kombināciju mikrosekundes izŔķirtspējā un klienta ID; tas nav tik droÅ”s, bet tas, iespējams, atbilst uzdevumam lielākajā daļā kontekstu.

Laiks, ko izmantojam kā atslēgas kalpoÅ”anas laika mērauklu, tiek saukts par "slēdzenes kalpoÅ”anas laiku". Å Ä« vērtÄ«ba ir gan laiks, kas paiet pirms bloÄ·Ä“Å”anas tiek automātiski atbrÄ«vots, gan laiks, kas klientam jāpabeidz, pirms cits klients var bloķēt Å”o resursu, faktiski nepārkāpjot savstarpējās izslēgÅ”anas garantijas. Å Ä« garantija ir ierobežota tikai uz noteiktu laika periodu, kas sākas no slēdzenes iegādes brīža.

Tāpēc mēs esam apsprieduÅ”i labu veidu, kā iegÅ«t un atbrÄ«vot slēdzeni. Sistēma (ja mēs runājam par neizplatÄ«tu sistēmu, kas sastāv no viena un vienmēr pieejama gadÄ«juma) ir droÅ”a. Attiecināsim Å”o jēdzienu uz izkliedētu sistēmu, kur mums nav Ŕādu garantiju.

Redlock algoritms

Algoritma izplatÄ«tajā versijā tiek pieņemts, ka mums ir N Redis meistari. Å ie mezgli ir pilnÄ«gi neatkarÄ«gi viens no otra, tāpēc mēs neizmantojam replikāciju vai kādu citu netieÅ”u koordinācijas sistēmu. Mēs jau esam aprakstÄ«juÅ”i, kā droÅ”i iegÅ«t un atbrÄ«vot slēdzeni vienā gadÄ«jumā. Mēs uzskatām par paÅ”saprotamu, ka algoritms, strādājot ar vienu gadÄ«jumu, izmantos tieÅ”i Å”o metodi. MÅ«su piemēros mēs iestatām N uz 5, kas ir saprātÄ«ga vērtÄ«ba. Tādējādi mums bÅ«s jāizmanto 5 Redis meistari dažādos datoros vai virtuālajās maŔīnās, lai nodroÅ”inātu, ka tie darbojas lielā mērā neatkarÄ«gi viens no otra.

Lai iegÅ«tu slēdzeni, klients veic Ŕādas darbÄ«bas:

  1. IegÅ«st paÅ”reizējo laiku milisekundēs.
  2. SecÄ«gi mēģina iegÅ«t bloÄ·Ä“Å”anu visos N gadÄ«jumos, visos gadÄ«jumos izmantojot vienu un to paÅ”u atslēgas nosaukumu un nejauŔās vērtÄ«bas. 2. posmā, kad klients iestata bloÄ·Ä“Å”anu katram gadÄ«jumam, klients izmanto aizkavi, lai to iegÅ«tu, kas ir pietiekami Ä«ss salÄ«dzinājumā ar laiku, pēc kura bloÄ·Ä“Å”ana tiek automātiski atbrÄ«vota. Piemēram, ja bloÄ·Ä“Å”anas ilgums ir 10 sekundes, tad aizkave varētu bÅ«t ~5-50 milisekundes robežās. Tas novērÅ” situāciju, kad klients var palikt bloķēts ilgu laiku, mēģinot sasniegt neveiksmÄ«gu Redis mezglu: ja gadÄ«jums nav pieejams, mēs cenÅ”amies pēc iespējas ātrāk izveidot savienojumu ar citu gadÄ«jumu.
  3. Lai paņemtu slēdzeni, klients aprēķina, cik daudz laika ir pagājis; Lai to izdarÄ«tu, no faktiskās laika vērtÄ«bas tiek atņemts laikspiedols, kas tika iegÅ«ts 1. darbÄ«bā. Ja un tikai tad, ja klients varēja iegÅ«t bloÄ·Ä“Å”anu lielākajā daļā gadÄ«jumu (vismaz 3), un kopējo laiku, kas bija nepiecieÅ”ams, lai to paveiktu. iegÅ«t slēdzeni, mazāks par slēdzenes ilgumu, tiek uzskatÄ«ts, ka slēdzene ir iegÅ«ta.
  4. Ja bloÄ·Ä“Å”ana ir iegÅ«ta, bloÄ·Ä“Å”anas ilgums tiek uzskatÄ«ts par sākotnējo bloÄ·Ä“Å”anas ilgumu, no kura atņem 3. darbÄ«bā aprēķināto pagājuÅ”o laiku.
  5. Ja klientam kāda iemesla dēļ neizdodas iegÅ«t bloÄ·Ä“Å”anu (vai nu tas nevarēja bloķēt N/2+1 gadÄ«jumus, vai bloÄ·Ä“Å”anas ilgums bija negatÄ«vs), tas mēģinās atbloķēt visus gadÄ«jumus (pat tos, kurus, pēc viņa domām, nevar bloķēt ).

Vai algoritms ir asinhrons?

Å is algoritms ir balstÄ«ts uz pieņēmumu, ka, lai gan nav sinhronizēta pulksteņa, kurā darbotos visi procesi, vietējais laiks katrā procesā joprojām plÅ«st aptuveni tādā paŔā tempā, un kļūda ir maza, salÄ«dzinot ar kopējo laiku, pēc kura tiek bloķēta. automātiski atbrÄ«vots. Å is pieņēmums ir ļoti lÄ«dzÄ«gs parastajiem datoriem raksturÄ«gajai situācijai: katram datoram ir lokālais pulkstenis, un parasti varam rēķināties ar to, ka laika starpÄ«ba starp dažādiem datoriem ir neliela.

Å ajā brÄ«dÄ« mums ir rÅ«pÄ«gāk jāformulē savstarpējās izslēgÅ”anas noteikums: savstarpēja izslēgÅ”ana tiek garantēta tikai tad, ja klients, kuram ir slēdzene, iziet slēdzenes darbÄ«bas laikā (Ŕī vērtÄ«ba iegÅ«ta 3. darbÄ«bā), atskaitot vēl kādu laiku (kopā daži milisekundes, lai kompensētu laika starpÄ«bu starp procesiem).

Å is interesants raksts stāsta vairāk par tādām sistēmām, kurām nepiecieÅ”ama laika intervālu saskaņoÅ”ana: Noma: efektÄ«vs kļūdu izturÄ«gs mehānisms izplatÄ«tās failu keÅ”atmiņas konsekvencei.

Neveiksmes gadījumā mēģiniet vēlreiz

Ja klientam neizdodas iegÅ«t bloÄ·Ä“Å”anu, tam pēc nejauÅ”as aizkaves jāmēģina vēlreiz; tas tiek darÄ«ts, lai desinhronizētu vairākus klientus, kuri mēģina vienlaikus iegÅ«t bloÄ·Ä“Å”anu vienam un tam paÅ”am resursam (kas var novest pie "smadzeņu sadalÄ«Å”anas" situācijas, kurā nav uzvarētāju). Turklāt, jo ātrāk klients mēģina iegÅ«t bloÄ·Ä“Å”anu lielākajai daļai Redis gadÄ«jumu, jo Å”aurāks ir logs, kurā var rasties smadzeņu sadalÄ«Å”anās situācija (un mazāka vajadzÄ«ba pēc atkārtota mēģinājuma). Tāpēc ideālā gadÄ«jumā klientam vajadzētu mēģināt nosÅ«tÄ«t SET komandas N gadÄ«jumiem vienlaikus, izmantojot multipleksÄ“Å”anu.

Å eit ir vērts uzsvērt, cik svarÄ«gi ir klientiem, kuriem neizdodas iegÅ«t lielāko daļu slēdzeņu, atbrÄ«vot (daļēji) iegādātās slēdzenes, lai viņiem nebÅ«tu jāgaida atslēgas derÄ«guma termiņŔ, pirms resursa slēdzeni var iegÅ«t atkārtoti. (lai gan, ja notiek tÄ«kla sadrumstalotÄ«ba un klients zaudē kontaktu ar Redis gadÄ«jumiem, jums ir jāmaksā pieejamÄ«bas sods, gaidot atslēgas derÄ«guma termiņu).

Slēdzenes atbrÄ«voÅ”ana

BloÄ·Ä“Å”anas atbrÄ«voÅ”ana ir vienkārÅ”a darbÄ«ba, kas vienkārÅ”i prasa visu gadÄ«jumu atbloÄ·Ä“Å”anu neatkarÄ«gi no tā, vai klients, Ŕķiet, ir veiksmÄ«gi bloķējis konkrētu gadÄ«jumu.

DroŔības apsvērumi

Vai algoritms ir droÅ”s? Mēģināsim iztēloties, kas notiek dažādos scenārijos.

Sākumā pieņemsim, ka klients lielākajā daļā gadÄ«jumu varēja iegÅ«t bloÄ·Ä“Å”anu. Katrā instancē bÅ«s atslēga ar vienādu kalpoÅ”anas laiku visiem. Tomēr katra no Ŕīm atslēgām tika instalēta atŔķirÄ«gā laikā, tāpēc to derÄ«guma termiņŔ beigsies dažādos laikos. Bet, ja pirmā atslēga tika instalēta laikā, kas nav sliktāks par T1 (laiks, kuru mēs izvēlamies pirms sazināŔanās ar pirmo serveri), un pēdējā atslēga tika instalēta laikā, kas nav sliktāks par T2 (laiks, kurā tika saņemta atbilde no pēdējā servera), tad mēs esam pārliecināti, ka pirmā atslēga komplektā, kurai beidzas derÄ«guma termiņŔ, izdzÄ«vos vismaz MIN_VALIDITY=TTL-(T2-T1)-CLOCK_DRIFT. Visām pārējām atslēgām derÄ«guma termiņŔ beigsies vēlāk, tāpēc varam bÅ«t droÅ”i, ka visas atslēgas bÅ«s vienlaikus derÄ«gas vismaz Å”o laiku.

Laikā, kad lielākā daļa atslēgu paliek spēkā, cits klients nevarēs iegÅ«t slēdzeni, jo N/2+1 SET NX operācijas nevar bÅ«t veiksmÄ«gas, ja N/2+1 atslēgas jau pastāv. LÄ«dz ar to, ja slēdzene ir iegādāta, to tajā paŔā brÄ«dÄ« atkārtoti iegÅ«t nav iespējams (tas pārkāptu savstarpējās izslēgÅ”anas Ä«paŔību).
Tomēr mēs vēlamies pārliecināties, ka vairāki klienti, kas mēģina iegūt slēdzeni vienlaikus, nevar gūt panākumus vienlaikus.

Ja klients lielāko daļu gadÄ«jumu ir bloķējis apmēram vai ilgāk par maksimālo bloÄ·Ä“Å”anas ilgumu, tas uzskatÄ«s bloÄ·Ä“Å”anu par nederÄ«gu un atbloķēs gadÄ«jumus. Tāpēc jāņem vērā tikai tas gadÄ«jums, kad klientam lielāko daļu gadÄ«jumu izdevās bloķēt Ä«sākā laikā par derÄ«guma termiņu. Å ajā gadÄ«jumā, ņemot vērā iepriekÅ” minēto argumentu, laikā MIN_VALIDITY nevienam klientam nevajadzētu bÅ«t iespējai atkārtoti iegÅ«t slēdzeni. Tāpēc daudzi klienti varēs bloķēt N/2+1 gadÄ«jumus vienā un tajā paŔā laikā (kas beidzas 2. posma beigās) tikai tad, kad vairākuma bloÄ·Ä“Å”anas laiks bija ilgāks par TTL laiku, kas padara bloÄ·Ä“Å”anu nederÄ«gu.

Vai varat sniegt oficiālu droŔības pierādÄ«jumu, norādÄ«t esoÅ”os lÄ«dzÄ«gus algoritmus vai atrast kļūdu iepriekÅ” minētajā?

Pieejamības apsvērumi

Sistēmas pieejamÄ«ba ir atkarÄ«ga no trim galvenajām Ä«paŔībām:

  1. Automātiski atlaist slēdzenes (kad beidzas atslēgu derÄ«guma termiņŔ): atslēgas galu galā atkal bÅ«s pieejamas, lai tās izmantotu slēdzenēm.
  2. Tas, ka klienti parasti palÄ«dz viens otram, noņemot slēdzenes, kad vēlamā slēdzene nav iegÅ«ta, vai ir iegÅ«ta un darbs ir pabeigts; tāpēc, visticamāk, mums nebÅ«s jāgaida, lÄ«dz beigsies atslēgu derÄ«guma termiņŔ, lai atgÅ«tu slēdzeni.
  3. Fakts, ka klientam atkārtoti jāmēģina iegÅ«t slēdzeni, tas gaida salÄ«dzinoÅ”i ilgāku laiku, nekā nepiecieÅ”ams, lai iegÅ«tu lielāko daļu slēdzeņu. Tas samazina iespējamÄ«bu, ka, sacenÅ”oties par resursiem, var rasties situācija ar ŔķelÅ”anos.

Tomēr pastāv pieejamÄ«bas sods, kas vienāds ar tÄ«kla segmentu TTL, tādēļ, ja ir blakus segmenti, sods var bÅ«t nenoteikts. Tas notiek ikreiz, kad klients iegÅ«st bloÄ·Ä“Å”anu un pēc tam nopludina uz citu segmentu, pirms tas var to atbrÄ«vot.

Principā, ņemot vērā bezgalÄ«gus blakus esoÅ”os tÄ«kla segmentus, sistēma var palikt nepieejama bezgalÄ«gi ilgu laiku.

Veiktspēja, kļūmjpārlēce un fsync

Daudzi cilvēki izmanto Redis, jo viņiem ir nepiecieÅ”ama augsta bloÄ·Ä“Å”anas servera veiktspēja attiecÄ«bā uz latentumu, kas nepiecieÅ”ams, lai iegÅ«tu un atbrÄ«votu slēdzenes, un iegÅ«Å”anu/izlaidumu skaitu, ko var pabeigt sekundē. Lai izpildÄ«tu Å”o prasÄ«bu, pastāv stratēģija saziņai ar N Redis serveriem, lai samazinātu latentumu. Å Ä« ir multipleksÄ“Å”anas stratēģija (jeb "nabaga multipleksÄ“Å”ana", kur ligzda tiek ievietota nebloÄ·Ä“Å”anas režīmā, nosÅ«ta visas komandas un nolasa komandas vēlāk, pieņemot, ka marÅ”ruta laiks starp klientu un katru gadÄ«jumu ir lÄ«dzÄ«gs) .

Tomēr mums ir jāņem vērā arÄ« apsvērumi, kas saistÄ«ti ar ilgtermiņa datu glabāŔanu, ja mēs cenÅ”amies izveidot modeli ar uzticamu atkopÅ”anos pēc kļūmēm.

BÅ«tÄ«bā, lai noskaidrotu problēmu, pieņemsim, ka mēs konfigurējam Redis bez ilgtermiņa datu glabāŔanas. Klientam izdodas bloķēt 3 no 5 gadÄ«jumiem. Viens no gadÄ«jumiem, ko klientam izdevās bloķēt, tiek restartēts, un Å”obrÄ«d tam paÅ”am resursam atkal ir 3 gadÄ«jumi, kurus mēs varam bloķēt, savukārt cits klients var bloķēt restartēto gadÄ«jumu, pārkāpjot droŔības rekvizÄ«tu. uzņemas slēdzeņu ekskluzivitāti.

Ja iespējosit datus uz priekÅ”u (AOF), situācija nedaudz uzlabosies. Piemēram, varat reklamēt serveri, nosÅ«tot komandu SHUTDOWN un restartējot to. Tā kā Redis derÄ«guma termiņa darbÄ«bas ir semantiski ieviestas tā, lai laiks turpinātu plÅ«st pat tad, kad serveris ir izslēgts, visas mÅ«su prasÄ«bas ir piemērotas. Tas ir normāli, kamēr tiek nodroÅ”ināta normāla izslēgÅ”ana. Ko darÄ«t elektrÄ«bas padeves pārtraukumu gadÄ«jumā? Ja Redis pēc noklusējuma ir konfigurēts ar fsync sinhronizāciju diskā katru sekundi, iespējams, ka pēc restartÄ“Å”anas mums nebÅ«s mÅ«su atslēgas. Teorētiski, ja mēs vēlamies garantēt bloÄ·Ä“Å”anas droŔību jebkuras instances restartÄ“Å”anas laikā, mums tas ir jāiespējo fsync=always iestatÄ«jumos ilgstoÅ”ai datu glabāŔanai. Tas pilnÄ«bā nogalinās veiktspēju, lÄ«dz pat CP sistēmu lÄ«menim, ko tradicionāli izmanto, lai droÅ”i ieviestu sadalÄ«tas slēdzenes.

Taču situācija ir labāka, nekā Ŕķiet no pirmā acu uzmetiena. Principā algoritma droŔība tiek saglabāta, jo, instanci restartējot pēc kļūmes, tā vairs nepiedalās nevienā bloÄ·Ä“Å”anā, kas paÅ”laik ir aktÄ«va.

Lai to nodroÅ”inātu, mums vienkārÅ”i jānodroÅ”ina, lai pēc kļūmes gadÄ«jums paliktu nepieejams laika periodu, kas nedaudz pārsniedz mÅ«su izmantoto maksimālo TTL. Tādā veidā mēs gaidÄ«sim lÄ«dz derÄ«guma termiņa beigām un visu atslēgu, kas bija aktÄ«vas kļūmes brÄ«dÄ«, automātiskai atbrÄ«voÅ”anai.

Izmantojot aizkavētas restartÄ“Å”anas, principā ir iespējams panākt droŔību pat tad, ja Redis nav ilgstoÅ”as ā€‹ā€‹ā€‹ā€‹noturÄ«bas. Tomēr ņemiet vērā, ka tas var izraisÄ«t naudas sodu par pieejamÄ«bas pārkāpÅ”anu. Piemēram, ja vairums gadÄ«jumu neizdodas, sistēma kļūs globāli nepieejama TTL (un Å”ajā laikā nevar bloķēt nevienu resursu).

Mēs palielinām algoritma pieejamÄ«bu: mēs pagarinām bloÄ·Ä“Å”anu

Ja klientu veiktais darbs sastāv no maziem soļiem, iespējams samazināt noklusējuma slēdzenes ilgumu un ieviest slēdzeņu pagarināŔanas mehānismu. Principā, ja klients ir aizņemts ar skaitļoÅ”anu un bloÄ·Ä“Å”anas derÄ«guma termiņŔ ir bÄ«stami zems, varat nosÅ«tÄ«t Lua skriptu visiem gadÄ«jumiem, kas paplaÅ”ina atslēgas TTL, ja atslēga joprojām pastāv un tās vērtÄ«ba joprojām ir nejauÅ”a vērtÄ«ba, kas iegÅ«ta, kad slēdzene tika iegādāta.

Klientam vajadzētu uzskatÄ«t, ka bloÄ·Ä“Å”ana ir atkārtoti jāiegÅ«st tikai tad, ja tā derÄ«guma termiņā ir spējusi bloķēt lielāko daļu gadÄ«jumu.

Tiesa, tehniski algoritms nemainās, tāpēc ir jāierobežo maksimālais atkārtotu slēdzenes iegÅ«Å”anas mēģinājumu skaits, pretējā gadÄ«jumā tiks pārkāptas pieejamÄ«bas Ä«paŔības.

Avots: www.habr.com

Pievieno komentāru