Duke ardhur te një produkt që po zhvillohet për më shumë se një dekadë, nuk është aspak befasuese të gjesh teknologji të vjetruara në të. Por, çka nëse në gjashtë muaj duhet ta mbani ngarkesën 10 herë më të lartë, dhe kostoja e rënies do të rritet qindra herë? Në këtë rast, keni nevojë për një inxhinier të mirënjohur Highload. Por në mungesë të shërbëtores më besuan mua zgjidhjen e problemit. Në pjesën e parë të artikullit do t'ju tregoj se si kaluam nga Redis në Redis-cluster, dhe në pjesën e dytë do të jap këshilla se si të filloni të përdorni grupin dhe çfarë t'i kushtoni vëmendje kur e përdorni atë.

Zgjedhja e teknologjisë

A është kaq keq? veçuar Redis (redis i pavarur) në një konfigurim prej 1 master dhe N skllav? Pse e quaj teknologji të vjetëruar?

Jo, Redis nuk është aq i keq... Megjithatë, ka disa mangësi që nuk mund të anashkalohen.

• Së pari, Redis nuk mbështet mekanizmat e rikuperimit nga fatkeqësitë pas një dështimi master. Për të zgjidhur këtë problem, ne përdorëm një konfigurim me transferim automatik të VIP-ave te një master i ri, duke ndryshuar rolin e njërit prej skllevërve dhe duke ndërruar pjesën tjetër. Ky mekanizëm funksionoi, por nuk mund të quhej një zgjidhje e besueshme. Së pari, ndodhën alarme të rreme, dhe së dyti, ishte e disponueshme dhe pas funksionimit kërkoheshin veprime manuale për të ngarkuar pranverën.

• Së dyti, të kesh vetëm një mjeshtër çoi në problemin e copëtimit. Na u desh të krijonim disa grupime të pavarura "1 master dhe N skllav", më pas të shpërndajmë manualisht bazat e të dhënave midis këtyre makinave dhe të shpresojmë që nesër një nga bazat e të dhënave të mos fryhet aq shumë sa të duhet të zhvendoset në një shembull të veçantë.

Cilat janë opsionet?

• Zgjidhja më e shtrenjtë dhe më e pasur është Redis-Enterprise. Kjo është një zgjidhje në kuti me mbështetje të plotë teknike. Pavarësisht se nga pikëpamja teknike duket ideale, nuk na shkonte për arsye ideologjike.
• Redis-grup. Nga kutia ka mbështetje për failover master dhe sharding. Ndërfaqja pothuajse nuk është e ndryshme nga versioni i rregullt. Duket premtuese, do të flasim për kurthet më vonë.
• Tarantool, Memcache, Aerospike dhe të tjerë. Të gjitha këto mjete bëjnë pothuajse të njëjtën gjë. Por secila ka të metat e veta. Ne vendosëm të mos i vendosnim të gjitha vezët në një shportë. Ne përdorim Memcache dhe Tarantool për detyra të tjera, dhe, duke parë përpara, do të them se në praktikën tonë kishte më shumë probleme me to.

Specifikat e përdorimit

Le të hedhim një vështrim se cilat probleme kemi zgjidhur historikisht me Redis dhe çfarë funksionaliteti kemi përdorur:

• Cache përpara kërkesave për shërbime në distancë si 2GIS | Golang
  

  GET SET MGET MSET "SELECT DB"

• Cache para MYSQL | PHP
  

  GET SET MGET MSET SCAN "KEY BY PATTERN" "SELECT DB"

• Magazinimi kryesor për shërbimin e punës me sesionet dhe koordinatat e drejtuesve | Golang
  

  GET SET MGET MSET "SELECT DB" "ADD GEO KEY" "GET GEO KEY" SCAN

Siç mund ta shihni, nuk ka matematikë më të lartë. Cila është atëherë vështirësia? Le të shohim secilën metodë veç e veç.

Метод
Përshkrim
Karakteristikat e Redis-cluster
vendim

VENDOSET
Çelësi i shkrimit/leximit

MGET MSET
Shkruani/lexoni çelësa të shumtë
Çelësat do të jenë në nyje të ndryshme. Bibliotekat e gatshme mund të kryejnë shumë operacione vetëm brenda një nyje
Zëvendësoni MGET me një tubacion të operacioneve N GET

ZGJIDH DB
Zgjidhni bazën me të cilën do të punojmë
Nuk mbështet baza të të dhënave të shumta
Vendosni gjithçka në një bazë të dhënash. Shtoni prefikset tek çelësat

SCAN
Kaloni nëpër të gjithë çelësat në bazën e të dhënave
Meqenëse kemi një bazë të dhënash, kalimi nëpër të gjithë çelësat në grup është shumë i shtrenjtë
Mbani një invariant brenda një çelësi dhe bëni një HSCAN në këtë çelës. Ose refuzoni plotësisht

GEO
Operacionet me një gjeoçelë
Gjeoçelësi nuk është i copëtuar

ÇELËSI SIPAS MOBILIT
Duke kërkuar për një çelës sipas modelit
Meqenëse kemi një bazë të dhënash, ne do të kërkojmë në të gjithë çelësat në grup. Shumë e shtrenjtë
Refuzoni ose mbani invariantin, si në rastin e SCAN-it

Redis vs Redis-grup

Çfarë humbim dhe çfarë fitojmë kur kalojmë në një grup?

• Disavantazhet: humbasim funksionalitetin e disa bazave të të dhënave.
  • Nëse duam të ruajmë të dhëna logjikisht të palidhura në një grup, do të duhet të bëjmë paterica në formën e parashtesave.
  • Ne humbasim të gjitha operacionet "bazë", të tilla si SCAN, DBSIZE, CLEAR DB, etj.
  • Multi-operacionet janë bërë shumë më të vështira për t'u zbatuar sepse mund të kërkojnë qasje në disa nyje.
• Avantazhet:
  • Toleranca e gabimeve në formën e dështimit master.
  • Sharding në anën e Redis.
  • Transferoni të dhënat midis nyjeve në mënyrë atomike dhe pa ndërprerje.
  • Shtoni dhe rishpërndani kapacitetin dhe ngarkesat pa ndërprerje.

Do të konkludoja se nëse nuk keni nevojë të siguroni një nivel të lartë të tolerancës ndaj gabimeve, atëherë lëvizja në një grup nuk ia vlen, sepse mund të jetë një detyrë jo e parëndësishme. Por nëse fillimisht zgjidhni midis një versioni të veçantë dhe një versioni grupor, atëherë duhet të zgjidhni një grup, pasi nuk është më keq dhe, përveç kësaj, do t'ju lehtësojë disa nga dhimbjet e kokës.

Përgatitja për të lëvizur

Le të fillojmë me kërkesat për lëvizje:

• Duhet të jetë pa probleme. Një ndalesë e plotë e shërbimit për 5 minuta nuk na përshtatet.
• Duhet të jetë sa më i sigurt dhe gradual. Dua të kem pak kontroll mbi situatën. Ne nuk duam të hedhim gjithçka menjëherë dhe të lutemi mbi butonin e rikthimit.
• Humbje minimale të të dhënave gjatë lëvizjes. Ne e kuptojmë se do të jetë shumë e vështirë për të lëvizur në mënyrë atomike, kështu që ne lejojmë një desinkronizim midis të dhënave në Redis të rregullt dhe të grupuar.

Mirëmbajtja e grupimeve

Pak para lëvizjes, duhet të mendojmë nëse mund ta mbështesim grupin:

• Grafikët. Ne përdorim Prometheus dhe Grafana për të grafikuar ngarkesën e CPU-së, përdorimin e memories, numrin e klientëve, numrin e operacioneve GET, SET, AUTH, etj.
• Ekspertizë. Imagjinoni që nesër do të keni një grup të madh nën përgjegjësinë tuaj. Nëse prishet, askush përveç jush nuk mund ta rregullojë atë. Nëse ai fillon të ngadalësojë, të gjithë do të vrapojnë drejt jush. Nëse keni nevojë të shtoni burime ose të rishpërndani ngarkesën, kthehuni tek ju. Për të mos u thinjur në 25 vjeç, këshillohet që të parashikohen këto raste dhe të kontrollohet paraprakisht se si do të sillet teknologjia në veprime të caktuara. Le të flasim për këtë në më shumë detaje në seksionin "Ekspertiza".
• Monitorimi dhe alarmet. Kur një grup prishet, ju dëshironi të jeni të parët që dini për të. Këtu u kufizuam në një njoftim që të gjitha nyjet kthejnë të njëjtin informacion për gjendjen e grupit (po, ndodh ndryshe). Dhe probleme të tjera mund të vërehen më shpejt nga sinjalizimet nga shërbimet e klientëve Redis.

kalim

Si do të lëvizim:

• Para së gjithash, duhet të përgatisni një bibliotekë për të punuar me grupin. Ne morëm go-redis si bazë për versionin Go dhe e ndryshuam pak për t'iu përshtatur vetes. Ne zbatuam Multi-metods përmes tubacioneve, dhe gjithashtu korrigjuam pak rregullat për përsëritjen e kërkesave. Versioni PHP kishte më shumë probleme, por ne përfundimisht u vendosëm në php-redis. Kohët e fundit ata prezantuan mbështetjen e grupeve dhe sipas mendimit tonë duket mirë.
• Më pas ju duhet të vendosni vetë grupin. Kjo bëhet fjalë për fjalë në dy komanda bazuar në skedarin e konfigurimit. Ne do të diskutojmë vendosjen në më shumë detaje më poshtë.
• Për lëvizje graduale ne përdorim modalitetin e thatë. Meqenëse kemi dy versione të bibliotekës me të njëjtën ndërfaqe (njëri për versionin e rregullt, tjetri për grupin), nuk kushton asgjë për të krijuar një mbështjellës që do të funksionojë me një version të veçantë dhe paralelisht do t'i dublikojë të gjitha kërkesat në grup, Krahasoni përgjigjet dhe shkruani mospërputhjet në regjistrat (në rastin tonë në NewRelic). Kështu, edhe nëse versioni i grupit prishet gjatë prezantimit, prodhimi ynë nuk do të ndikohet.
• Pasi të kemi nxjerrë grupin në modalitetin e thatë, ne mund të shikojmë me qetësi grafikun e mospërputhjeve të përgjigjes. Nëse shkalla e gabimit ngadalë por me siguri lëviz drejt një konstante të vogël, atëherë gjithçka është në rregull. Pse ka ende mospërputhje? Sepse regjistrimi në një version të veçantë ndodh pak më herët se në grup, dhe për shkak të mikrolagut, të dhënat mund të ndryshojnë. Gjithçka që mbetet është të shikojmë regjistrat e mospërputhjeve dhe nëse të gjitha ato shpjegohen nga joatomiteti i regjistrimit, atëherë mund të vazhdojmë.
• Tani mund të ndërroni modalitetin e tharjes në drejtim të kundërt. Ne do të shkruajmë dhe lexojmë nga grupi dhe do ta dublojmë atë në një version të veçantë. Per cfare? Gjatë javës së ardhshme do të doja të vëzhgoja punën e grupit. Nëse befas rezulton se ka probleme në ngarkesën maksimale, ose nuk kemi marrë parasysh diçka, ne kemi gjithmonë një rikthim urgjent në kodin e vjetër dhe të dhënat aktuale falë modalitetit të thatë.
• E tëra që mbetet është të çaktivizoni modalitetin e thatë dhe të çmontoni versionin e veçantë.

provim

Së pari, shkurtimisht rreth dizajnit të grupit.

Para së gjithash, Redis është një dyqan me vlerë kyçe. Vargjet arbitrare përdoren si çelësa. Numrat, vargjet dhe strukturat e tëra mund të përdoren si vlera. Ka shumë nga këto të fundit, por për të kuptuar strukturën e përgjithshme kjo nuk është e rëndësishme për ne.
Niveli tjetër i abstraksionit pas çelësave është lojëra elektronike (SLOTS). Çdo çelës i përket një prej 16 sloteve. Mund të ketë çdo numër çelësash brenda çdo slot. Kështu, të gjithë çelësat ndahen në 383 grupe të shkëputura.

Më pas, duhet të ketë N nyje master në grup. Çdo nyje mund të konsiderohet si një shembull i veçantë Redis që di gjithçka për nyjet e tjera brenda grupit. Çdo nyje kryesore përmban një numër slotash. Çdo slot i përket vetëm një nyje master. Të gjitha lojërat elektronike duhet të shpërndahen midis nyjeve. Nëse disa lojëra elektronike nuk janë ndarë, atëherë çelësat e ruajtur në to do të jenë të paarritshëm. Ka kuptim të ekzekutohet çdo nyje master në një makinë të veçantë logjike ose fizike. Vlen gjithashtu të kujtohet se çdo nyje funksionon vetëm në një bërthamë, dhe nëse doni të ekzekutoni shumë instanca Redis në të njëjtën makinë logjike, sigurohuni që ato të funksionojnë në bërthama të ndryshme (ne nuk e kemi provuar këtë, por në teori duhet të funksionojë) . Në thelb, nyjet kryesore sigurojnë ndarje të rregullt, dhe më shumë nyje master lejojnë kërkesat e shkrimit dhe leximit të shkallëzohen.

Pasi të gjithë çelësat të shpërndahen midis slotave dhe slotet të shpërndahen midis nyjeve kryesore, një numër arbitrar i nyjeve skllav mund të shtohet në secilën nyje kryesore. Brenda çdo lidhjeje të tillë master-skllav, përsëritja normale do të funksionojë. Nevojiten skllevërit për të shkallëzuar kërkesat e leximit dhe për dështimin në rast të dështimit të masterit.

Tani le të flasim për operacionet që do të ishte më mirë të mund të bënim.

Ne do të hyjmë në sistem nëpërmjet Redis-CLI. Meqenëse Redis nuk ka një pikë të vetme hyrjeje, mund të kryeni veprimet e mëposhtme në cilindo nga nyjet. Në çdo pikë tërheq vëmendjen veçmas për mundësinë e kryerjes së operacionit nën ngarkesë.

• Gjëja e parë dhe më e rëndësishme që na nevojitet është funksionimi i nyjeve të grupimit. Ai kthen gjendjen e grupit, tregon një listë të nyjeve, rolet e tyre, shpërndarjen e sloteve, etj. Më shumë informacion mund të merret duke përdorur informacionin e grupit dhe lojërat e grupeve.
• Do të ishte mirë të ishim në gjendje të shtoni dhe hiqni nyjet. Për këtë qëllim ekzistojnë operacione takimi dhe harrimi i grupimeve. Ju lutemi vini re se harresa e grupimit duhet të zbatohet në ÇDO nyje, si master ashtu edhe kopje. Dhe Cluster Meet duhet të thirret vetëm në një nyje. Ky ndryshim mund të jetë shqetësues, kështu që është më mirë të mësoni rreth tij përpara se të shkoni drejtpërdrejt me grupin tuaj. Shtimi i një nyje bëhet në mënyrë të sigurt në betejë dhe nuk ndikon në funksionimin e grupit në asnjë mënyrë (gjë që është logjike). Nëse do të hiqni një nyje nga grupi, duhet të siguroheni që nuk ka mbetur vend i caktuar në të (përndryshe rrezikoni të humbni aksesin në të gjithë çelësat në këtë nyje). Gjithashtu, mos e fshini një master që ka skllevër, përndryshe do të bëhet një votim i panevojshëm për një zotëri të ri. Nëse nyjet nuk kanë më lojëra elektronike, atëherë ky është një problem i vogël, por pse na duhen zgjedhje shtesë nëse mund t'i fshijmë së pari skllevërit.
• Nëse ju duhet të ndërroni me forcë pozicionet master dhe skllav, atëherë komanda e dështimit të grupit do të funksionojë. Kur e quani atë në betejë, duhet të kuptoni se mjeshtri nuk do të jetë i disponueshëm gjatë operacionit. Në mënyrë tipike, ndërrimi ndodh në më pak se një sekondë, por nuk është atomike. Mund të prisni që disa kërkesa drejtuar masterit të dështojnë gjatë kësaj kohe.
• Përpara se të hiqni një nyje nga grupi, nuk duhet të ketë mbetur në të. Është më mirë t'i rishpërndani ato duke përdorur komandën reshard të grupit. Slots do të transferohen nga një master në tjetrin. I gjithë operacioni mund të zgjasë disa minuta, varet nga vëllimi i të dhënave që transferohen, por procesi i transferimit është i sigurt dhe nuk ndikon në asnjë mënyrë funksionimin e grupit. Kështu, të gjitha të dhënat mund të transferohen nga një nyje në tjetrën drejtpërdrejt nën ngarkesë, dhe pa u shqetësuar për disponueshmërinë e saj. Megjithatë, ka edhe hollësi. Së pari, transferimi i të dhënave shoqërohet me një ngarkesë të caktuar në nyjet e marrësit dhe dërguesit. Nëse nyja e marrësit është tashmë e ngarkuar shumë në procesor, atëherë nuk duhet ta ngarkoni atë me marrjen e të dhënave të reja. Së dyti, sapo të mos mbetet asnjë vend i vetëm në zotëruesin dërgues, të gjithë skllevërit e tij do të shkojnë menjëherë te zotëria tek i cili janë transferuar këto lojëra elektronike. Dhe problemi është se të gjithë këta skllevër do të duan të sinkronizojnë të dhënat menjëherë. Dhe do të jeni me fat nëse është sinkronizim i pjesshëm dhe jo i plotë. Merreni parasysh këtë dhe kombinoni operacionet e transferimit të lojërave elektronike dhe çaktivizimit/transferimit të skllevërve. Ose shpresoni se keni një diferencë të mjaftueshme sigurie.
• Çfarë duhet të bëni nëse gjatë transferimit zbuloni se i keni humbur diku lojërat elektronike? Shpresoj që ky problem të mos ju prekë, por nëse po, ka një operacion të rregullimit të grupit. Së paku, ajo do të shpërndajë lojëra elektronike nëpër nyje në një mënyrë të rastësishme. Unë rekomandoj të kontrolloni funksionimin e tij duke hequr fillimisht nyjen me lojëra elektronike të shpërndara nga grupi. Meqenëse të dhënat në lojëra elektronike të pashpërndara nuk janë tashmë të disponueshme, është tepër vonë për t'u shqetësuar për problemet me disponueshmërinë e këtyre lojërave elektronike. Nga ana tjetër, operacioni nuk do të ndikojë në lojëra elektronike të shpërndara.
• Një tjetër operacion i dobishëm është monitorimi. Kjo ju lejon të shihni në kohë reale të gjithë listën e kërkesave që shkojnë në nyje. Për më tepër, ju mund ta kapni atë dhe të zbuloni nëse ka trafikun e nevojshëm.

Vlen gjithashtu të përmendet procedura master failover. Me pak fjalë, ekziston dhe, për mendimin tim, funksionon shkëlqyeshëm. Megjithatë, mos mendoni se nëse shkëputni kordonin e rrymës në një makinë me një nyje kryesore, Redis do të kalojë menjëherë dhe klientët nuk do ta vërejnë humbjen. Në praktikën time, ndërrimi ndodh në disa sekonda. Gjatë kësaj kohe, disa nga të dhënat do të jenë të padisponueshme: zbulohet padisponueshmëria e masterit, nyjet votojnë për një të re, skllevërit ndërrohen, të dhënat sinkronizohen. Mënyra më e mirë për t'u siguruar që skema po funksionon është të kryeni ushtrime lokale. Ngrini grupin në laptop, jepini një ngarkesë minimale, simuloni një përplasje (për shembull, duke bllokuar portat) dhe vlerësoni shpejtësinë e ndërrimit. Sipas mendimit tim, vetëm pasi të keni luajtur në këtë mënyrë për një ose dy ditë, mund të jeni të sigurt në funksionimin e teknologjisë. Epo, ose shpresoj që softueri që përdor gjysma e internetit ndoshta funksionon.

konfiguracion

Shpesh, konfigurimi është gjëja e parë që duhet të filloni të punoni me mjetin. Dhe kur gjithçka funksionon, as nuk dëshironi të prekni konfigurimin. Duhet disa përpjekje për të detyruar veten të ktheheni te cilësimet dhe t'i kaloni ato me kujdes. Në kujtesën time, kemi pasur të paktën dy dështime serioze për shkak të moskujdesit ndaj konfigurimit. Kushtojini vëmendje të veçantë pikave të mëposhtme:

• koha 0
  Koha pas së cilës mbyllen lidhjet joaktive (në sekonda). 0 - mos mbyllni
  Jo çdo bibliotekë e jona ishte në gjendje të mbyllte lidhjet siç duhet. Duke çaktivizuar këtë cilësim, rrezikojmë të arrijmë kufirin e numrit të klientëve. Nga ana tjetër, nëse ka një problem të tillë, atëherë ndërprerja automatike e lidhjeve të humbura do ta maskojë atë, dhe ne mund të mos e vërejmë. Përveç kësaj, nuk duhet ta aktivizoni këtë cilësim kur përdorni lidhje të vazhdueshme.
• Ruaj xy & shtojcë po
  Ruajtja e një fotografie RDB.
  Ne do të diskutojmë çështjet e RDB/AOF në detaje më poshtë.
• stop-writes-on-bgsave-error no & slave-serve-stale-data po
  Nëse aktivizohet, nëse fotografia e RDB prishet, masteri do të ndalojë pranimin e kërkesave për ndryshim. Nëse lidhja me masterin humbet, skllavi mund të vazhdojë t'u përgjigjet kërkesave (po). Ose do të ndalojë së përgjigjuri (jo)
  Nuk jemi të kënaqur me situatën në të cilën Redis kthehet në kungull.
• repl-ping-slave-perioda 5
  Pas kësaj periudhe kohore, ne do të fillojmë të shqetësohemi se masteri është prishur dhe është koha për të kryer procedurën e dështimit.
  Ju do të duhet të gjeni manualisht një ekuilibër midis pozitivëve të rremë dhe nxitjes së një dështimi. Në praktikën tonë kjo është 5 sekonda.
• repl-backlog-size 1024mb & epl-backlog-ttl 0
  Ne mund të ruajmë pikërisht kaq shumë të dhëna në një tampon për një kopje të dështuar. Nëse buferi mbaron, do t'ju duhet të sinkronizoni plotësisht.
  Praktika sugjeron që është më mirë të vendosni një vlerë më të lartë. Ka shumë arsye pse një kopje mund të fillojë të vonojë. Nëse mbetet, atëherë ka shumë të ngjarë që mjeshtri juaj tashmë po lufton për të përballuar, dhe sinkronizimi i plotë do të jetë pika e fundit.
• maksimumin e klientëve 10000
  Numri maksimal i klientëve një herë.
  Në përvojën tonë, është më mirë të vendosni një vlerë më të lartë. Redis trajton mirë 10 mijë lidhje. Vetëm sigurohuni që ka mjaft priza në sistem.
• maxmemory-policy volatile-ttl
  Rregulli me të cilin çelësat fshihen kur arrihet kufiri i disponueshëm i memories.
  Ajo që është e rëndësishme këtu nuk është vetë rregulli, por të kuptuarit se si do të ndodhë kjo. Redis mund të lavdërohet për aftësinë e tij për të punuar normalisht kur arrihet kufiri i kujtesës.

Problemet RDB dhe AOF

Edhe pse vetë Redis ruan të gjitha informacionet në RAM, ekziston gjithashtu një mekanizëm për ruajtjen e të dhënave në disk. Më saktësisht, tre mekanizma:

• RDB-snapshot - një fotografi e plotë e të gjitha të dhënave. Vendoseni duke përdorur konfigurimin SAVE XY dhe lexoni "Ruaj një pamje të plotë të të gjitha të dhënave çdo X sekonda nëse të paktën çelësat Y kanë ndryshuar".
• Skedar vetëm me shtojcë - një listë e operacioneve sipas radhës që kryhen. Shton operacione të reja hyrëse në skedar çdo X sekonda ose çdo operacion Y.
• RDB dhe AOF janë një kombinim i dy të mëparshmeve.

Të gjitha metodat kanë avantazhet dhe disavantazhet e tyre, nuk do t'i rendis të gjitha, thjesht do të tërheq vëmendjen në pikat që, për mendimin tim, nuk janë të dukshme.

Së pari, ruajtja e një fotografie RDB kërkon thirrjen e FORK. Nëse ka shumë të dhëna, kjo mund të varë të gjithë Redis për një periudhë prej disa milisekonda në një sekondë. Përveç kësaj, sistemi duhet të ndajë memorie për një fotografi të tillë, gjë që çon në nevojën për të mbajtur një furnizim të dyfishtë RAM në makinën logjike: nëse ndahen 8 GB për Redis, atëherë 16 GB duhet të jenë të disponueshme në makinën virtuale me atë.

Së dyti, ka probleme me sinkronizimin e pjesshëm. Në modalitetin AOF, kur skllav është rilidhur, në vend të sinkronizimit të pjesshëm, mund të kryhet sinkronizimi i plotë. Pse ndodh kjo, nuk mund ta kuptoja. Por ia vlen ta mbani mend këtë.

Këto dy pika tashmë na bëjnë të mendojmë nëse vërtet na duhen këto të dhëna në disk nëse gjithçka tashmë është dublikuar nga skllevërit. Të dhënat mund të humbasin vetëm nëse të gjithë skllevërit dështojnë, dhe ky është një problem i nivelit "zjarr në DC". Si një kompromis, ju mund të propozoni të ruani të dhënat vetëm në skllevër, por në këtë rast duhet të siguroheni që këta skllevër nuk do të bëhen kurrë mjeshtër gjatë rikuperimit nga fatkeqësia (për këtë ekziston një përcaktim i përparësisë së skllevërve në konfigurimin e tyre). Për veten tonë, në secilin rast specifik ne mendojmë nëse është e nevojshme të ruani të dhënat në disk, dhe më shpesh përgjigjja është "jo".

Përfundim

Si përfundim, shpresoj se kam qenë në gjendje të jap një ide të përgjithshme se si funksionon redis-cluster për ata që nuk kanë dëgjuar fare për të, dhe gjithashtu tërhoqi vëmendjen për disa pika jo të dukshme për ata që e kanë përdorur atë. për një kohë të gjatë.
Faleminderit për kohën tuaj dhe, si gjithmonë, komentet mbi këtë temë janë të mirëseardhura.

Burimi: www.habr.com