Kur hyni në një produkt që zhvillohet për më shumë se një dekadë, nuk është aspak befasuese të gjeni teknologji të vjetra. Por çfarë nëse pas gjashtë muajsh duhet të mbani një ngarkesë dhjetë herë më të madhe, dhe çmimi i rënieve rritet qindra herë? Në këtë rast, ju nevojitet një Inxhinier Highload i shkëlqyer. Por, për shkak të mungesës së një të tillë, problemin më besuan mua. Në pjesën e parë të artikullit, do të tregoj se si u kaluam nga Redis në Redis-cluster, dhe në pjesën e dytë do të jap këshilla si të filloni të përdorni klasterin dhe në çfarë duhet të vini re gjatë kushteve të përdorimit.
Zgjedhja e teknologjisë
A është kaq e keqe Redis i veçantë (redis i izoluar) në konfigurimin 1 master dhe N skllave? Pse e quaj atë teknologji të vjetër?
Jo, Redis nuk është kaq i keq... Sidoqoftë, ka disa mangësi që nuk mund të injorohen.
Së pari, Redis nuk mbështet mekanizmat e rikuperimit nga rënia e masterit. Për të zgjidhur këtë problem, ne përdorëm një konfigurim me përshkrirjen automatike të VIP-ve në masterin e ri, duke ndryshuar rolin e njërit prej skllavëve dhe duke kaluar të tjerët. Ky mekanizëm funksionoi, por nuk mund ta quajmë një zgjidhje të besueshme. Së pari, ndodhnin goditje të rreme, dhe së dyti, ai ishte një herësh, dhe pas aktivizimit kërkoheshin veprime manuale për të rifilluar sistemin.
Së dyti, pranimi i vetëm një masteri shkaktonte një problem sharding. Duhej të krijonim disa klasterë të pavarur "1 master dhe N skllavë", pastaj të shpërndanim manualisht bazat në këto makina dhe të shpresonim që nesër ndonjëra nga bazat nuk do të rritej aq shumë sa të duhej të transferohej në një instancë të veçantë.
ĂfarĂ« opionesh ka?
- Zgjidhja më e shtrenjtë dhe më e pasur është Redis-Enterprise. Kjo është një zgjidhje e kutisë me mbështetje të plotë teknike. Pavarësisht se si duket e përsosur nga aspekti teknik, nuk na përputhej për arsye ideologjike.
- Redis-kluster. Ka rasti kaq shumë mbështetje për kalimin e fatkeqësive dhe shardimin. Ndërfaqja është pothuajse e njëjtë me versionin e zakonshëm. Duket premtuese, do të flasim më vonë për pengesat.
- Tarantool, Memcache, Aerospike dhe të tjerë. Të gjitha këto mjete bëjnë më shumë ose më pak të njëjtën gjë. Por secili ka disavantazhet e tij. Ne vendosëm të mos i vendosim të gjitha vezët në një shportë. Memcache dhe Tarantool i përdorim për detyra të tjera, dhe, para se të kalojmë më tej, do të thuash se në praktikën tonë kemi pasur më shumë probleme me to.
Specifikat e përdorimit
Le të shohim cilat detyra kemi zgjidhur historikisht me Redis dhe cilën funksionalitet e kemi përdorur:
- Kesh para kërkesave ndaj shërbimeve të largëta si 2GIS | Golang
GET SET MGET MSET "ZRAPORTO DB"
- Kesh para MYSQL | PHP
GET SET MGET MSET SCAN "ĂELSI ME MODELL" "ZRAPORTO DB"
- Depoja kryesore për shërbimin e menaxhimit të sesioneve dhe koordinatave të shoferëve | Golang
GET SET MGET MSET "ZRAPORTO DB" "SHTO ĂELSIN GJEO" "MERR ĂELSIN GJEO" SCAN
Siç e shihni, nuk ka matematikĂ« tĂ« lartĂ«. ĂfarĂ« Ă«shtĂ« atĂ«herĂ« e vĂ«shtira? Le tĂ« shqyrtojmĂ« secilĂ«n metodĂ« veçmas.
Metoda
PĂ«rshkrimi
Karakteristikat e Redis-kluster
Zgjidhja
GET SET
Shkruaj/merr çelësin
MGET MSET
Shkruaj/merr disa çelësa
ĂelĂ«t do tĂ« jenĂ« nĂ« node tĂ« ndryshme. Bibliotekat e gatshme dinĂ« tĂ« bĂ«jnĂ« Multi-operacione vetĂ«m brenda njĂ« node.
Zëvendëso MGET me pipeline nga N operacione GET.
PĂ«rzgjidh DB
Zgjidhni bazën me të cilën do të punojmë.
Nuk mbështet disa baza të dhënash.
Të gjitha të dhënat në një bazë. Shtoni prefikse te çelësat.
SCAN
Kaloni përmes të gjitha çelësave në bazë.
Pasi që kemi një bazë, kalimi përmes të gjithë çelësave në kluster është shumë i shtrenjtë.
Mbani invariantin brenda një çelësi dhe bëni HSCAN mbi këtë çelës. Ose hiqeni krejtësisht.
GEO
Operacionet e punës me çelësin gjeografik.
ĂelĂ«si gjeografik nuk shardohet.
KEY BY PATTERN
Kërko çelësin sipas modelit.
Pasi kemi një bazë, do të kërkojmë për të gjithë çelësat në kluster. Shumë e shtrenjtë.
Hiqni dorë ose mbani invariantin, siç është rasti me SCAN-in.
Redis vs Redis-cluster
ĂfarĂ« humbasim dhe çfarĂ« fitojmĂ« kur kalojmĂ« nĂ« kluster?
- Disavantazhet: humbasim funksionalitetin e disa bazave.
- Nëse duam të ruajmë në një kluster të dhëna që nuk lidhen logjikisht, do të duhet të bëjmë disa zgjidhje si prefiksat.
- Humbasim tĂ« gjitha operacionet ânĂ« bazĂ«â, si SCAN, DBSIZE, CLEAR DB etj.
- Multi-operatorët janë bërë ndjeshëm më të komplikuar për t'u realizuar, sepse mund të kërkohet qasja në disa node.
- Përparësitë:
- Qëndrueshmëria në mënyrë të sigurt si kalim emergjence i masterit.
- Segmentimi në anën e Redis.
- Transferimi i të dhënave midis node-ve në mënyrë atomike dhe pa ndalesa.
- Shtimi dhe ripërndarja e kapaciteteve dhe ngarkesave pa ndalesa.
Do ta bëja përfundimin se nëse nuk keni nevojë për një nivel të lartë qëndrushmërie, atëherë kalimi në klaster nuk ia vlen, pasi kjo mund të jetë një detyrë jo triviale. Por nëse fillimisht zgjidhni midis një versioni të veçantë dhe një klasteri, atëherë duhet të zgjidhni klasterin, pasi nuk është më i keq dhe për më tepër do t'ju heqë disa nga dhimbjet e kokës.
Përgatitja për kalim
Le të fillojmë me kërkesat për kalim:
- Ai duhet të jetë pa ndalesa. Një ndalim i plotë i shërbimit për 5 minuta nuk na përshtatet.
- Ai duhet të jetë sa më i sigurt dhe gradual. Dëshirojmë të kemi njëfarë kontrolli mbi situatën. Të hedhim gjithçka menjëherë dhe të lutemi për butonin e rikthimit nuk dëshirojmë.
- Minimizimi i humbjeve të të dhënave gjatë migrimit. Ne e kuptojmë se do të jetë shumë e vështirë të migrosh në mënyrë atomike, prandaj lejojmë njëfarë çregullimi midis të dhënave në Redis-in normal dhe atë në klaster.
Shërbimi i klasterit
Para se të filloni migrimin, duhet të mendoni nëse mund të mbani klasterin:
- Grafikët. Ne përdorim Prometheus dhe Grafana për grafikët e ngarkesës së procesorëve, memorie e zënë, numrin e klientëve, numrin e operacioneve GET, SET, AUTH, etj.
- Ekspertiza. PĂ«rshtypni se nesĂ«r do tĂ« keni nĂ«n pĂ«rgjegjĂ«si njĂ« klaster tĂ« madh. NĂ«se ai dĂ«shton, askush pĂ«rveç jush nuk do tĂ« jetĂ« nĂ« gjendje ta riparojĂ«. NĂ«se fillon tĂ« ngadalĂ«sohet â tĂ« gjithĂ« do tĂ« vrapojnĂ« te ju. NĂ«se Ă«shtĂ« e nevojshme tĂ« shtoni burime ose tĂ« shpĂ«rndani ngarkesĂ«n â pĂ«rsĂ«ri te ju. PĂ«r tĂ« mos u thinjur nĂ« 25, Ă«shtĂ« e preferueshme tĂ« parashikoni kĂ«to raste dhe tĂ« kontrolloni paraprakisht se si do tĂ« sillet teknologjia gjatĂ« veprimeve tĂ« ndryshme. Do tĂ« flasim mĂ« shumĂ« pĂ«r kĂ«tĂ« nĂ« seksionin "Ekspertiza".
- Monitorimi dhe njoftimet. Kur klasteri dështojnë, dëshirojmë të jemi të parët që e dinë. Këtu ne u kufizuam në njoftimin se të gjitha nodat kthejnë të njëjtin informacion për gjendjen e klasterit (po, ndodhin raste të tjera gjithashtu). Problemet e tjera mund të vihen re më shpejt përmes njoftimeve nga shërbimet e klientëve të Redis.
Shkëputja
Si do të bëjmë shkëputjen:
- NĂ« radhĂ« tĂ« parĂ«, duhet tĂ« pĂ«rgatisim bibliotekĂ«n pĂ«r punĂ«n me klasterin. Si bazĂ« pĂ«r versionin nĂ« GĐŸ, ne morĂ«m go-redis dhe e modifikuam pak sipas nevojave tona. Realizuam metodat Multi pĂ«rmes pipeline-Ă«ve, si dhe bĂ«ra disa rregullime nĂ« rregullat e pĂ«rsĂ«ritjes sĂ« kĂ«rkesave. Me versionin pĂ«r PHP patĂ«m mĂ« shumĂ« probleme, por nĂ« fund u ndalĂ«m nĂ« php-redis. SĂ« fundmi, ata zyrtarisht zbatuan mbĂ«shtetje pĂ«r klasterin, dhe sipas mendimit tonĂ«, duket mirĂ«.
- Më pas, duhet të vendosim vetë klasterin. Kjo bëhet literalisht në dy komanda mbi bazën e dosjes së konfigurimit. Më shumë detaje për konfigurimin do të diskutojmë më poshtë.
- Për migrimin gradual përdorim dry-mode. Duke pasur dy versione të bibliotekës me të njëjtin ndërfaqe (një për versionin normal dhe një tjetër për klasterin), nuk është ndonjë e vështirë të krijosh një mbështjellës që të punojë me versionin e veçantë dhe paralelisht të dublosh të gjitha kërkesat në klaster, të krahasosh përgjigjet dhe të regjistrosh diferencat në log (në rastin tonë në NewRelic). Duke bërë kështu, edhe nëse gjatë nxjerrjes versioni i klasterit dështojë, produksioni ynë nuk do të preket.
- Duke nxjerrë klasterin në dry-mode, mund të shikojmë qetësisht grafikën e diferencave të përgjigjeve. Nëse përqindja e gabimeve ngadalë, por sigurt është duke shkuar drejt një konstante të vogël, atëherë gjithçka është në rregull. Pse ekzistojnë ende diferenca? Sepse regjistrimi në versionin e veçantë ndodh disa kohë më parë se në klaster, dhe për shkak të mikro-ndërprerjeve të dhënat mund të dallohen. Thjesht duhen shqyrtuar logët e diferencave, dhe nëse të gjitha ato janë të shpjegueshme nga mos-atomiciteti i regjistrimit, atëherë mund të vazhdojmë përpara.
- Tani tani mund të kaloni dry-mode në anën tjetër. Do të shkruajmë dhe lexojmë nga klasteri, dhe do të ashtu që të dyfishojmë në një version të veçantë. Pse? Gjatë javës së ardhshme dëshirojmë të vëzhgojmë funksionimin e klasterit. Nëse ndodhi që të zbulojmë ndonjë problem gjatë ngarkesës maksimale, ose nëse ndonjë gjë na ka ikur nga vëmendja, gjithmonë do të kemi një rikthim emergjent në kodin e vjetër dhe të dhënat në aktualitet falë dry-mode.
- Kalon vetëm për të çaktivizuar dry-mode dhe për të demontuar versionin e veçantë.
Ekspertiza
Së pari, një përmbledhje e shkurtër mbi ndërtimin e klasterit.
SĂ« pari, Redis Ă«shtĂ« njĂ« depo e tĂ« dhĂ«nave me çelĂ«sa dhe vlera. ĂelĂ«si pĂ«rdor vargje tĂ« rastĂ«sishme. Vlerat mund tĂ« jenĂ« numra, vargje dhe struktura tĂ« plota. Ka shumĂ« prej kĂ«tyre, por pĂ«r tĂ« kuptuar ndĂ«rtimin e pĂ«rgjithshĂ«m, kjo nuk Ă«shtĂ« e rĂ«ndĂ«sishme.
Niveli tjetĂ«r i abstraksionit pas çelĂ«save janĂ« slotet (SLOTS). Ădo çelĂ«s i pĂ«rket njĂ« prej 16,383 slotĂ«ve. Brenda çdo sloti mund tĂ« ketĂ« sa tĂ« doni çelĂ«sa. NĂ« kĂ«tĂ« mĂ«nyrĂ«, tĂ« gjithĂ« çelĂ«sat shpĂ«rndahen nĂ« 16,383 grupe tĂ« papĂ«rputhshme.
MĂ« pas, nĂ« klasĂ«n duhet tĂ« ketĂ« N master-node. Ădo node mund tĂ« pĂ«rfaqĂ«sohet si njĂ« instancĂ« e veçantĂ« Redis, e cila di gjithçka pĂ«r nodet e tjera brenda klasĂ«s. Ădo master-node pĂ«rmban njĂ« sasi tĂ« caktuar slotesh. Ădo slot i pĂ«rket vetĂ«m njĂ« master-node. TĂ« gjithĂ« slotet duhet tĂ« shpĂ«rndahen midis nodave. NĂ«se ndonjĂ« slot nuk Ă«shtĂ« shpĂ«rndarĂ«, atĂ«herĂ« çelĂ«sat qĂ« ruhen nĂ« to nuk do tĂ« jenĂ« tĂ« disponueshĂ«m. Ka kuptim tĂ« nisni çdo master-node nĂ« njĂ« makinĂ« logjike ose fizike tĂ« veçantĂ«. Gjithashtu, Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« mbani mend se çdo node funksionon vetĂ«m nĂ« njĂ« bĂ«rthamĂ«, dhe nĂ«se dĂ«shironi tĂ« nisni disa instancĂ« Redis nĂ« njĂ« makinĂ« logjike, sigurohuni qĂ« ato do tĂ« funksionojnĂ« nĂ« bĂ«rthama tĂ« ndryshme (ne nuk e kemi provuar kĂ«tĂ«, por nĂ« teori, gjithçka duhet tĂ« funksionojĂ«). NĂ« thelb, master-node ofrojnĂ« njĂ« sharding tĂ« zakonshĂ«m, dhe mĂ« shumĂ« master-node lejojnĂ« tĂ« skaloni kĂ«rkesat pĂ«r shkruar dhe lexuar.
Pasi i të gjitha çelësat ndahen në slotet dhe slotet shpërndahen në master-node, çdo master-node mund të ketë një numër të pakufizuar slave-node. Brenda çdo lidhjeje të tillë "master-slave" do të funksionojë replikimi normal. Slave-t janë të nevojshme për të shkallëzuar kërkesat për lexim dhe për kalimin në rast se master-i dështon.
Tani le të flasim për operacione që do të shërbenin mirë të silleshim.
Për të komunikuar me sistemin, ne do të përdorim Redis-CLI. Duke qenë se Redis-i nuk ka një pikë të vetme hyrëse, operacionet e mëposhtme mund të kryhen në ndonjë nga nodet. Në secilën pikë, unë veçoj mundësinë e kryerjes së operacionit nën ngarkesë.
- E para dhe më e rëndësishmja që na nevojitet: operacioni cluster nodes. Ai kthen gjendjen e klasterit, tregon listën e nodave, rolet e tyre, shpërndarjen e slotave etj. Informacione të tjera mund të merren përmes cluster info dhe cluster slots.
- Do tĂ« ishte mirĂ« tĂ« ishim nĂ« gjendje tĂ« shtonim dhe hiqnim nodet. PĂ«r kĂ«tĂ«, ka operacionet cluster meet dhe cluster forget. Mbani parasysh se cluster forget duhet tĂ« aplikohet pĂ«r ĂDO nod, si pĂ«r mjeshtĂ«rat, ashtu edhe pĂ«r replikat. NdĂ«rsa pĂ«r cluster meet Ă«shtĂ« mjaft tĂ« thirret vetĂ«m nĂ« njĂ« nodĂ«. Ky ndryshim mund tĂ« jetĂ« shqetĂ«sues, prandaj Ă«shtĂ« mĂ« mirĂ« tĂ« informoheni pĂ«r tĂ« para se tĂ« nisni klasterin nĂ« prodhim. Shtimi i njĂ« nodi realizohet nĂ« mĂ«nyrĂ« tĂ« sigurt nĂ« proces dhe nuk ndikon nĂ« funksionimin e klasterit (çfarĂ« Ă«shtĂ« e logjikshme). NĂ«se do tĂ« hiqni njĂ« nodĂ« nga klasteri, duhet tĂ« siguroheni qĂ« nuk ka mbetur slot (ndryshe rrezikoni tĂ« humbni qasjen nĂ« tĂ« gjitha çelĂ«sat nĂ« kĂ«tĂ« nod). Po ashtu, mos hiqni mjeshtrin qĂ« ka skllavĂ«, pĂ«rndryshe do tĂ« nisni njĂ« votim tĂ« panevojshĂ«m pĂ«r njĂ« mjeshtĂ«r tĂ« ri. NĂ«se nuk ka mĂ« slot nĂ« nodet, kjo Ă«shtĂ« njĂ« problem i vogĂ«l, por pse tĂ« kemi zgjedhje tĂ« tepĂ«rta, kur mund tĂ« hiqni fillimisht skllavĂ«t.
- Nëse duhet të ndërrosh përforcimin dhe skllevërin me forcë, komanda cluster failover është e përshtatshme. Duke e thirrur atë në luftë, duhet të kuptosh se gjatë realizimit të operacionit, përforcimi do të jetë i paarritshëm. Zakonsisht, kalimi ndodhi për më pak se një sekondë, por jo në mënyrë atomike. Mund të llogarisni që një pjesë e kërkesave drejt përforcimit në këtë kohë do të përfundojë me gabim.
- Para para se heqĂ«n nodet nga klasteri, asnjĂ« slot nuk duhet tĂ« mbetet atje. ĂshtĂ« mĂ« mirĂ« t'i rishpĂ«rndahen ato pĂ«rmes komandĂ«s cluster reshard. Slots do tĂ« transferohen nga njĂ« master nĂ« njĂ« tjetĂ«r. E gjithĂ« operacioni mund tĂ« marrĂ« disa minuta, varĂ«sisht nga volumi i tĂ« dhĂ«nave qĂ« po transferohen, megjithatĂ« procesi i transferimit Ă«shtĂ« i sigurt dhe nuk ka ndonjĂ« ndikim nĂ« funksionimin e klasterit. KĂ«shtu, tĂ« gjitha tĂ« dhĂ«nat mund tĂ« transferohen nga njĂ« nod nĂ« njĂ« tjetĂ«r nĂ«n ngarkesĂ« dhe tĂ« mos shqetĂ«soheni pĂ«r disponueshmĂ«rinĂ« e tyre. MegjithatĂ«, ka edhe nuanca. SĂ« pari, transferimi i tĂ« dhĂ«nave lidhet me njĂ« ngarkesĂ« tĂ« caktuar nĂ« nodin marrĂ«s dhe atĂ« dĂ«rgues. NĂ«se nodi marrĂ«s Ă«shtĂ« tashmĂ« shumĂ« i ngarkuar pĂ«r sa i pĂ«rket CPU-sĂ«, nuk duhet ta ngarkoni atĂ« edhe me pranimin e tĂ« dhĂ«nave tĂ« reja. SĂ« dyti, sa herĂ« qĂ« asnjĂ« slot nuk do tĂ« mbetet nĂ« masterin e dĂ«rguesit, tĂ« gjitha slave-t e tij do tĂ« kalojnĂ« menjĂ«herĂ« te masteri nĂ« tĂ« cilin kĂ«to slots janĂ« transferuar. Problemi Ă«shtĂ« se tĂ« gjitha kĂ«to slave do tĂ« duan tĂ« sinkronizohen me tĂ« dhĂ«nat njĂ«herĂ«sh. Dhe do t'ju faturohet nĂ«se kjo do tĂ« jetĂ« sinkronizim pjesor, e jo i plotĂ«. Merini parasysh kĂ«to, dhe kombinoni operacionet e transferimit tĂ« slots dhe shkĂ«putjes/transfertĂ«s sĂ« slave-ve. Ose shpresoni qĂ« keni njĂ« rezervĂ« tĂ« mjaftueshme.
- ĂfarĂ« tĂ« bĂ«ni nĂ«se gjatĂ« transferimit zbuloni se keni humbur disa slot-e? Shpresoj qĂ« kjo problematikĂ« tĂ« mos ju prekĂ«, por nĂ«se ndodh, ka operacionin cluster fix. Ai do tĂ« shpĂ«rndajĂ« slotet nĂ« nodet nĂ« rend tĂ« rastĂ«sishĂ«m. Ju rekomandoj tĂ« kontrolloni funksionimin e saj, duke fshirĂ« paraprakisht nga klasteri nodin me slotet e shpĂ«rndara. Duke qenĂ« se tĂ« dhĂ«nat nĂ« slotet e pa shpĂ«rndara tani janĂ« tĂ« paqasshme, nuk ka kohĂ« pĂ«r t'u shqetĂ«suar pĂ«r problemet me aksesin e kĂ«tyre slot-eve. Nga ana tjetĂ«r, operacioni nuk do tĂ« ndikojĂ« nĂ« slotet e shpĂ«rndara.
- Një operacion tjetër i dobishëm është monitor. Ai lejon në kohë reale të shihni të gjithë listën e kërkesave që shkojnë në nod. Për më tepër, mund të bëni grep mbi të për të mësuar nëse ka trafikun e nevojshëm.
Duhet përmendur gjithashtu procedura e kalimit emergjent të masterit. Nëse flasim shkurt, ajo ekziston dhe, sipas mendimit tim, funksionon shkëlqyer. Megjithatë, nuk duhet të mendoni se nëse hiqni kabllon nga prizë në makinën me nodin master, Redis do të kalojë menjëherë dhe klientët nuk do ta vërejnë humbjen. Nga përvoja ime, kalimi ndodh pas disa sekondash. Gjatë këtij kohe, një pjesë e të dhënave do të jetë e pa aksesueshme: zbulohet pavlefshmëria e masterit, nodet votojnë për një të ri, skllavët kalojnë, të dhënat sinkronizohen. Mënyra më e mirë për të konfirmuar vetë se skema funksionon është të zhvilloni stërvitje lokale. Ngrihuni një klaster në laptopin tuaj, jepni një ngarkesë minimale, imitoni rënien (për shembull, duke bllokuar portet), vlerësoni shpejtësinë e kalimit. Në mendimin tim, vetëm pas disa ditësh lojë në këtë mënyrë, mund të jeni të sigurt për funksionimin e teknologjisë. Ose, ndoshta, të shpresoni se softueri që përdoret nga gjysma e internetit me siguri funksionon.
Konfigurimi
Shpesh, konfigurimi është gjëja e parë që nevojitet për të filluar punën me mjetin. Dhe kur gjithçka fillon të funksionojë, është e pambështetur të prekësh konfigurimin. Duhen përpjekje të caktuara për të detyruar veten të kthehesh në cilësime dhe t'i shqyrtosh ato me kujdes. Nga ajo që kam parasysh, kemi pasur të paktën dy dështime të rënda për shkak të moskujdesit ndaj konfigurimit. Kushtoni vëmendje të veçantë pikave të mëposhtme:
- timeout 0
Koha, pas sĂ« cilĂ«s mbyllen lidhjet e paaktivizuara (nĂ« sekonda). 0 â nuk mbyllen
Jo çdo bibliotekë jonë ishte në gjendje të mbyllte lidhjet siç duhet. Duke çaktivizuar këtë cilësim, bëjmë rrezik të arrijmë limitin e numrit të klientëve. Në anën tjetër, nëse kemi një problem të tillë, ndarja automatike e lidhjeve të humbura do ta maskojë atë, dhe ne mund të mos e vëmë re. Gjithashtu, mos e aktivizoni këtë cilësim kur përdorni lidhje persistente. - Save x y & appendonly yes
Ruajtja e snapshot-it RDB.
Problemet RDB/AOF do t'i diskutojmë në detaje më poshtë. - stop-writes-on-bgsave-error no & slave-serve-stale-data yes
Nëse është e aktivizuar, kur RDB-snapshot-i prishet, master-i do të ndalojë të pranojë kërkesa për ndryshime. Nëse lidhja me master-in humbet, skllavi mund të vazhdojë të përgjigjet ndaj kërkesave (po). Ose do të ndalojë të përgjigjet (jo)
Nuk jemi të kënaqur me situatën ku Redis shndërrohet në një kallpem. - repl-ping-slave-period 5
Pas kësaj periudhe kohe, do të fillojmë të shqetësohemi se master-i ka dështuar dhe është koha për të kryer procedurën e kalimit.
Do të duhet të gjejmë manualisht ekuilibrin midis sinjaleve të rreme dhe fillimit të kalimit. Në praktikën tonë, kjo është 5 sekonda. - repl-backlog-size 1024mb & epl-backlog-ttl 0
Saktësisht aq të dhëna mund të ruajmë në buffer për një skllav që ka humbur lidhjen. Nëse buffer-i përfundon, do të duhet të sinkronizohemi plotësisht.
Praktika tregon se është më mirë të vendosni një vlerë më të madhe. Shkaku për të cilat skllavi mund të fillojë të vonohet është mjaftueshëm. Nëse ai vonohet, ka shumë të ngjarë që master-i juaj të ketë probleme dhe sinkronizimi i plotë do të jetë pikë e fundit. - maxclients 10000
Numri maksimal i klientëve në një kohë të caktuar.
Nga eksperienca jonë, është më mirë të vendosni një vlerë më të lartë. Redis e menaxhon shumë mirë me 10,000 lidhje. Thjesht sigurohuni që sistemi të ketë mjaft soketë. - maxmemory-policy volatile-ttl
Rregulli sipas të cilit fshihen çelësat kur arrihet kufiri i memories së disponueshme.
Këtu është e rëndësishme jo vetë rregulli, por kuptimi i mënyrës se si do të ndodhë. Redis meriton lavdërime për aftësinë e tij për të funksionuar normalisht kur arrihet kufiri i memories.
Problemet RDB dhe AOF
Ndërkohë që vetë Redis ruan të gjitha informacionet në memorien operative, ekziston gjithashtu një mekanizëm për ruajtjen e të dhënave në disk. Më saktësisht, tre mekanizma:
- RDB-snapshot â njĂ« kopje e plotĂ« e tĂ« gjithĂ« tĂ« dhĂ«nave. Caktohet me definimin SAVE X Y dhe lexohet si 'Ruaj njĂ« kopje tĂ« plotĂ« tĂ« tĂ« dhĂ«nave çdo X sekonda, nĂ«se janĂ« ndryshuar tĂ« paktĂ«n Y çelĂ«sa'.
- Skedari i vetĂ«m tĂ« shtohet â njĂ« listĂ« operacionesh nĂ« rendin e ekzekutimit tĂ« tyre. Shton operacionet e reja nĂ« skedar çdo X sekonda ose çdo Y operacione.
- RDB dhe AOF â kombinimi i dy metodave tĂ« mĂ«sipĂ«rme.
Të gjitha metodat kanë përparësitë dhe disavantazhet e tyre, nuk do t'i përmend të gjitha; thjesht do t'i kushtoj vëmendje momenteve që në mendimin tim nuk janë të dukshme.
Së pari, për të ruajtur një snapshot RDB, kërkohet të thirret FORK. Nëse ka shumë të dhëna, kjo mund të ndalojë tërë Redis për një periudhë prej disa milisekondash deri në një sekondë. Për më tepër, sistemi ka nevojë të rezervojë memorie për një snapshot të tillë, çka çon në nevojën për të mbajtur dyfishin e rezervës së memorie në një server logjik: nëse për Redis janë rezervuar 8 GB, atëherë në makinë virtuale me të duhet të jetë e disponueshme 16.
Së dyti, ka probleme me sinkronizimin e pjesshëm. Në modalitetin AOF, gjatë ripërkthimit të skllavit në vend të sinkronizimit të pjesshëm mund të kryhet një sinkronizim i plotë. Pse ndodh kështu, nuk kam arritur ta kuptoj. Por është mirë ta mbash mend këtë.
Këto dy pika na bëjnë të mendojmë nëse na duhen këto të dhëna në disk, nëse gjithçka përsëritet nga slave-t. Mund të humbasim të dhënat vetëm në rast se të gjitha slave-t dalin jashtë funksionit, dhe kjo është një problem në nivelin e "zjarrit në Qendrën e Të Dhënave". Si një kompromis, mund të propozojmë që të ruajmë të dhënat vetëm në slave, por në këtë rast, duhet të sigurohemi që këto slave kurrë të mos bëhen master gjatë rikuperimit të emergjencës (për këtë ekziston një cilësim prioritari për slave në konfigurimin e tyre). Ne në çdo rast konkret mendojmë nëse duhet të ruajmë të dhënat në disk dhe shpesh herë përgjigjemi "jo".
PĂ«rfundimi
Në përfundim, shpresoj se kam arritur të jap një pasqyrë të përgjithshme të funksionimit të redis-cluster për ata që nuk kanë dëgjuar fare për të, si dhe të theksoj disa çështje që nuk janë të qarta për ata që e përdorin prej kohësh.
Faleminderit për kohën e dhënë dhe, si zakonisht, komentet në lidhje me temën janë të mirëseardhura.
Burimi: habr.com
