Hamarkada bat baino gehiago garatzen ari den produktu batera helduta, ez da batere harritzekoa bertan teknologia zaharkituak aurkitzea. Baina zer gertatzen da sei hilabetean karga 10 aldiz handiagoa mantendu behar baduzu eta erorketen kostua ehunka aldiz handituko bada? Kasu honetan, Highload Engineer cool bat behar duzu. Baina neskamerik ezean, arazoa konpontzeko ardura eman zidaten. Artikuluaren lehen zatian Redis-tik Redis-clusterera nola pasatu ginen kontatuko dizuet, eta bigarren zatian cluster-a erabiltzen hasteko aholkuak emango ditut eta hura erabiltzeko orduan zertan jarri arreta.

Teknologiaren hautaketa

Hain txarra al da? bereizi Redis (redis independentea) 1 maisu eta N esklaboen konfigurazioan? Zergatik esaten diot teknologia zaharkitua?

Ez, Redis ez dago horren txarra... Hala ere, badira alde batera utzi ezin diren hutsune batzuk.

• Lehenik eta behin, Redis-ek ez ditu onartzen hondamendiak berreskuratzeko mekanismoak hutsegite nagusi baten ondoren. Arazo hau konpontzeko, VIP-ak maisu berri batera transferitzeko automatikoki duen konfigurazio bat erabili dugu, esklaboetako baten rola aldatuz eta gainerakoak aldatuz. Mekanismo honek funtzionatu zuen, baina ezin zaio irtenbide fidagarritzat jo. Lehenik eta behin, alarma faltsuak gertatu ziren, eta bigarrenik, botatzekoa zen, eta funtzionamenduaren ondoren eskuzko ekintzak behar ziren malgukia kargatzeko.

• Bigarrenik, maisu bakarra izateak zatiketaren arazoa ekarri zuen. "1 maisu eta N esklabo" hainbat kluster independente sortu behar izan genituen, ondoren datu-baseak eskuz banatu makina horien artean eta espero bihar datu-baseetako bat ez zela hainbeste puztuko, ezen aparteko instantzia batera eraman behar izatea.

Zeintzuk dira aukerak?

• Irtenbide garestiena eta aberatsena Redis-Enterprise da. Laguntza tekniko osoa duen kaxa bidezko irtenbidea da. Ikuspegi teknikotik aproposa dirudien arren, arrazoi ideologikoengatik ez zitzaigun egokitu.
• Redis-kluster. Kutxatik kanpo master failover eta sharding-erako laguntza dago. Interfazea ez da ohiko bertsioaren ia desberdina. Itxura itxaropentsua dirudi, geroxeago hitz egingo dugu zuloez.
• Tarantool, Memcache, Aerospike eta beste. Tresna hauek guztiek gauza bera egiten dute. Baina bakoitzak bere gabeziak ditu. Gure arrautza guztiak saski batean ez jartzea erabaki genuen. Memcache eta Tarantool erabiltzen ditugu beste zeregin batzuetarako, eta, aurrera begira, esango dut gure praktikan arazo gehiago egon zirela haiekin.

Erabileraren berezitasunak

Ikus dezagun historikoki Redis-ekin zer arazo konpondu ditugun eta zer funtzionalitate erabili ditugun:

• Cache 2GIS | bezalako urruneko zerbitzuei egindako eskaerak baino lehen Golang
  

  GET SET MGET MSET "HAUTETU DB"

• MYSQL aurretik | PHP
  

  LORTU EZARTU MGET MSET ESKANATEA "KEY EREDUAREN ARABERA" "HAUTATU DB"

• Saioekin eta gidariaren koordenatuekin lan egiteko zerbitzurako biltegiratze nagusia | Golang
  

  LORTU EZARTU MGET MSET "HAUSTU DB" "GEHITU GEO GAKOA" "LORTU GEO GAKOA" ESKANEA

Ikusten duzunez, goi mailako matematikarik ez. Zein da orduan zailtasuna? Ikus ditzagun metodo bakoitza bereizita.

Метод
Description
Redis-cluster-en ezaugarriak
Erabaki

EZARRI
Idatzi/irakurtzeko tekla

MGET MSET
Idatzi/irakur ezazu hainbat gako
Teklak nodo ezberdinetan egongo dira. Prestatutako liburutegiek eragiketa anitzak egin ditzakete nodo bakarrean
Ordeztu MGET N GET eragiketen kanalizazio batekin

AUKERATU DB
Hautatu lan egingo dugun oinarria
Ez du hainbat datu-base onartzen
Jarri dena datu-base batean. Gehitu aurrizkiak teklei

SCAN
Joan datu-baseko gako guztiak
Datu-base bat dugunez, klusterreko gako guztiak pasatzea garestia da
Mantendu aldaezin bat gako baten barruan eta egin HSCAN gako honetan. Edo erabat ukatu

GEO
Eragiketak geotekla batekin
Geotekla ez dago zatituta

EREDUZ GILTZA
Ereduka gako bat bilatzen
Datu-base bat dugunez, klusterreko gako guztietan bilatuko dugu. Garestiegia
Ukatu edo mantendu aldaezinari, SCAN-en kasuan bezala

Redis vs Redis-kluster

Zer galtzen dugu eta zer irabazten dugu kluster batera aldatzean?

• Desabantailak: hainbat datu-baseren funtzionaltasuna galtzen dugu.
  • Logikoki zerikusirik ez duten datuak kluster batean gorde nahi baditugu, aurrizki moduan makuluak egin beharko ditugu.
  • "Oinarrizko" eragiketa guztiak galtzen ditugu, hala nola SCAN, DBSIZE, CLEAR DB, etab.
  • Eragiketa anitzak ezartzea askoz zailagoa bihurtu da, hainbat nodotarako sarbidea behar duelako.
• abantailak:
  • Akatsen tolerantzia hutsegite maisuaren moduan.
  • Sharding Redis aldean.
  • Transferitu datuak nodoen artean atomikoki eta geldialdirik gabe.
  • Gehitu eta birbanatu ahalmena eta kargak geldialdirik gabe.

Ondorioztatuko nuke akatsen tolerantzia maila altua eman behar ez baduzu, kluster batera mugitzeak ez duela merezi, zeregin ez-huts bat izan daitekeelako. Baina hasiera batean bertsio bereizia eta cluster bertsioa aukeratzen baduzu, orduan cluster bat aukeratu beharko zenuke, ez baita okerragoa eta, gainera, buruhauste batzuk arinduko zaitu.

Mugitzeko prestatzen

Has gaitezen mugitzeko eskakizunekin:

• Ezinbestekoa izan behar du. 5 minutuko zerbitzua erabat gelditzea ez zaigu komeni.
• Ahalik eta seguruena eta pixkanaka izan behar du. Egoeraren gaineko kontrol pixka bat izan nahi dut. Ez dugu dena aldi berean bota nahi eta atzera botatzeko botoia otoitz egin nahi.
• Datu-galera minimoa mugitzean. Ulertzen dugu atomikoki mugitzea oso zaila izango dela, beraz, datuen artean nolabaiteko desinkronizazioa ahalbidetzen dugu Redis erregularretan eta multzokatuan.

Klusterraren mantentze-lanak

Mugimenduaren aurretik, pentsatu beharko genuke klusterra onartzen dugun ala ez:

• Grafikoak. Prometheus eta Grafana erabiltzen ditugu CPUaren karga, memoriaren erabilera, bezero kopurua, GET, SET, AUTH eragiketa etab.
• Espezializazioa. Imajinatu bihar kluster erraldoi bat izango duzula zure ardurapean. Hausten bada, inork ezingo du konpondu. Moteltzen hasten bada, denek korrika egingo dute zuregana. Baliabideak gehitu edo karga birbanatu behar baduzu, itzuli zuregana. 25 urterekin grisa ez bihurtzeko, komeni da kasu horiek aurreikustea eta aldez aurretik egiaztatzea nola jokatuko duen teknologiak ekintza jakin batzuetan. Hitz egin dezagun zehatzago honi buruz “Esperientzia” atalean.
• Jarraipena eta alertak. Kluster bat apurtzen denean, horren berri ematen lehena izan nahi duzu. Hemen nodo guztiek klusterraren egoerari buruzko informazio bera itzultzen duten jakinarazpen batera mugatu gara (bai, ezberdin gertatzen da). Eta beste arazo batzuk azkarrago antzeman daitezke Redis bezero-zerbitzuen abisuek.

zeharkaldia

Nola mugituko garen:

• Lehenik eta behin, liburutegi bat prestatu behar duzu cluster-arekin lan egiteko. Go-redis hartu genuen oinarri Go bertsioaren eta pixka bat aldatu genuen geure egokitzeko. Multi-metodoak kanalizazioen bidez inplementatu ditugu, eta eskaerak errepikatzeko arauak ere apur bat zuzendu ditugu. PHP bertsioak arazo gehiago izan zituen, baina azkenean php-redis-en finkatu ginen. Duela gutxi klusterraren laguntza aurkeztu dute eta gure ustez ondo ikusten da.
• Ondoren, klusterra bera zabaldu behar duzu. Hau literalki konfigurazio fitxategian oinarritutako bi komandotan egiten da. Ezarpena xehetasun gehiagorekin eztabaidatuko dugu jarraian.
• Pixkanaka mugitzeko modu lehorra erabiltzen dugu. Interfaze bera duten liburutegiaren bi bertsio ditugunez (bat bertsio arrunterako, bestea klustererako), ez da ezer kostatzen bertsio bereizi batekin funtzionatuko duen bilgarri bat sortzea eta paraleloki klusterrerako eskaera guztiak bikoiztea. alderatu erantzunak eta idatzi desadostasunak erregistroetan (gure kasuan NewRelic-en). Horrela, nahiz eta kluster bertsioa apurtu egiten den bitartean, gure ekoizpena ez da kaltetuko.
• Klusterra modu lehorrean zabaldu ondoren, erantzunen desadostasunen grafikoa lasai ikus dezakegu. Errore-tasa poliki-poliki baina ziurrenik konstante txiki batera joaten bada, dena ondo dago. Zergatik daude oraindik desadostasunak? Bertsio bereizi batean grabatzea klusterrean baino apur bat lehenago gertatzen delako, eta mikro-lag-aren ondorioz, datuak aldendu daitezke. Desadostasunen erregistroak begiratzea besterik ez da geratzen, eta denak diskoaren ez-atomikotasunagatik azaltzen badira, aurrera egin dezakegu.
• Orain lehor modua alda dezakezu kontrako norabidean. Klusteretik idatzi eta irakurriko dugu, eta bertsio bereizi batean bikoiztuko dugu. Zertarako? Datorren astean klusterraren lana behatu nahiko nuke. Bat-batean karga gailurrean arazoak daudela edo zerbait kontuan hartu ez badugu, beti izaten dugu larrialdiko kode zaharrera eta uneko datuetara itzulera lehorrari esker.
• Lehorra modua desgaitu eta bertsio bereizia desegitea da geratzen dena.

azterketa

Lehenik eta behin, labur-labur klusterraren diseinuari buruz.

Lehenik eta behin, Redis gako-balioen denda bat da. Kate arbitrarioak gako gisa erabiltzen dira. Zenbakiak, kateak eta egitura osoak balio gisa erabil daitezke. Azken horietako asko daude, baina egitura orokorra ulertzeko hori ez da garrantzitsua guretzat.
Gakoen ondorengo abstrakzio-maila zirrikituak (SLOTS) dira. Gako bakoitza 16 zirrikituetako bati dagokio. Zirrikitu bakoitzaren barruan edozein giltza egon daiteke. Horrela, gako guztiak 383 multzo disjuntetan banatzen dira.

Ondoren, klusterrean N nodo nagusi egon behar dira. Nodo bakoitza kluster barruko beste nodoei buruz dena dakien Redis instantzia bereizi gisa har daiteke. Nodo nagusi bakoitzak slot kopuru bat dauka. Zirrikitu bakoitza nodo nagusi bakarrari dagokio. Zirrikitu guztiak nodoen artean banatu behar dira. Zirrikitu batzuk esleitzen ez badira, horietan gordetako gakoak eskuraezinak izango dira. Zentzuzkoa da nodo nagusi bakoitza makina logiko edo fisiko ezberdin batean exekutatzeko. Gogoratu beharra dago, gainera, nodo bakoitza nukleo batean bakarrik exekutatzen dela, eta Redis instantzia anitz exekutatu nahi badituzu makina logiko berean, ziurtatu nukleo ezberdinetan exekutatzen direla (ez dugu hau probatu, baina teorian funtzionatu beharko luke) . Funtsean, nodo nagusiek zatiketa erregularra eskaintzen dute, eta nodo nagusi gehiagok idazteko eta irakurtzeko eskaerak eskalatzeko aukera ematen dute.

Gako guztiak zirrikituen artean banatu ondoren, eta zirrikituak nodo nagusien artean sakabanatuta egon ondoren, nodo esklabo kopuru arbitrario bat gehi daiteke nodo nagusi bakoitzean. Horrelako maisu-esklabu esteka bakoitzaren barruan, erreplikazio normalak funtzionatuko du. Esklaboak behar dira irakurketa-eskaerak eskalatzeko eta hutsegite nagusiak hutsegite kasuan.

Orain hitz egin dezagun hobe izango litzatekeen eragiketez.

Redis-CLI bidez sartuko gara sistemara. Redis-ek sarrera puntu bakar bat ez duenez, eragiketa hauek egin ditzakezu edozein nodotan. Puntu bakoitzean, eragiketa kargapean egiteko aukera ematen dut arreta.

• Behar dugun lehenengo gauza eta garrantzitsuena cluster nodoen eragiketa da. Klusterraren egoera itzultzen du, nodoen zerrenda, haien rolak, zirrikituen banaketa, etab. Informazio gehiago lor daiteke kluster informazioa eta kluster zirrikituak erabiliz.
• Polita litzateke nodoak gehitu eta kendu ahal izatea. Horretarako cluster topaketa eta cluster forget eragiketak daude. Kontuan izan cluster forget nodo BAKOITZAri aplikatu behar zaiola, bai maisuei bai errepliketan. Eta cluster topaketa nodo batean bakarrik deitu behar da. Desberdintasun hau kezkagarria izan daiteke, beraz, hobe da horri buruz ikastea zure klusterra zuzenean hasi aurretik. Nodo bat gehitzea modu seguruan egiten da borrokan eta ez dio inola ere eragiten klusterraren funtzionamenduari (logikoa da). Klusterretik nodo bat kenduko baduzu, ziurtatu behar duzu ez dagoela zirrikiturik geratzen (bestela, nodo honetako gako guztietarako sarbidea galtzeko arriskua duzu). Gainera, ez ezabatu esklaboak dituen maisua, bestela, beharrezkoa ez den maisu berri baten aldeko botoa egingo da. Nodoek ez badute zirrikiturik, orduan arazo txiki bat da, baina zergatik behar ditugu aukera gehigarriak esklaboak lehenik ezaba ditzakegu.
• Maisuaren eta esklabuaren posizioak indarrez aldatu behar badituzu, kluster hutsegite komandoak balioko du. Borrokan deitzean, ulertu behar duzu maisua ez dela erabilgarri egongo operazioan zehar. Normalean etengailua segundo batean baino gutxiagoan gertatzen da, baina ez da atomikoa. Denbora horretan maisuari egindako eskaera batzuk huts egingo dutela espero dezakezu.
• Klusterretik nodo bat kendu aurretik, ez luke zirrikiturik geratu behar. Hobe da cluster reshard komandoa erabiliz birbanatzea. Slotak master batetik bestera transferituko dira. Eragiketa osoak minutu batzuk iraun ditzake, transferitzen den datu-bolumenaren araberakoa da, baina transferentzia-prozesua segurua da eta ez dio inola ere eragiten klusterraren funtzionamenduari. Horrela, datu guztiak zuzenean kargapean nodo batetik bestera transferi daitezke, eta bere erabilgarritasunaz kezkatu gabe. Hala ere, sotiltasunak ere badaude. Lehenik eta behin, datu-transferentzia karga jakin batekin lotzen da hartzailearen eta igorlearen nodoetan. Hartzailearen nodoa prozesadorean oso kargatuta badago, ez zenuke kargatu behar datu berriak jasotzearekin. Bigarrenik, bidaltzen duen maisuan zirrikitu bakar bat geratzen ez den bezain laster, bere esklabo guztiak berehala joango dira slot horiek transferitu ziren maisuarengana. Eta arazoa da esklabo guzti hauek aldi berean datuak sinkronizatu nahi dituztela. Eta zortea izango duzu sinkronizazio osoa baino partziala bada. Kontuan hartu hau eta konbinatu slots transferitzeko eta esklaboak desgaitzeko/transferitzeko eragiketak. Edo segurtasun-marjina nahikoa duzula espero.
• Zer egin behar duzu transferentzian zehar zure zirrikituak nonbait galdu dituzula ikusten baduzu? Espero dut arazo honek ez dizula eragitea, baina hala badagokio, kluster konponketa eragiketa bat dago. Gutxienez, zirrikituak nodoetan barreiatuko ditu ausazko ordenan. Bere funtzionamendua egiaztatzea gomendatzen dut lehenik klusterretik banatutako zirrikituak dituen nodoa kenduz. Esleitu gabeko zirrikituetako datuak dagoeneko erabilgarri ez daudenez, beranduegi da zirrikitu hauen erabilgarritasunarekin arazoak kezkatzeko. Aldi berean, eragiketak ez du eraginik izango banatutako zirrikituak.
• Beste eragiketa erabilgarria monitorea da. Nodora doazen eskaeren zerrenda osoa denbora errealean ikusteko aukera ematen du. Gainera, grep dezakezu eta beharrezkoa den trafikoa dagoen jakiteko.

Aipatzekoa da, halaber, failover master prozedura. Laburbilduz, existitzen da, eta, nire ustez, bikain funtzionatzen du. Hala ere, ez pentsa nodo nagusi bat duen makina batean korronte-kablea deskonektatzen baduzu, Redis berehala aldatuko dela eta bezeroek ez dutela galera nabarituko. Nire praktikan, aldaketa segundo gutxitan gertatzen da. Denbora horretan, datu batzuk ez dira erabilgarri egongo: maisuaren erabilgarritasunik eza detektatzen da, nodoek berri bat bozkatzen dute, esklaboak aldatzen dira, datuak sinkronizatu egiten dira. Eskemak funtzionatzen duela ziurtatzeko modurik onena tokiko ariketak egitea da. Altxa ezazu klusterra zure ordenagailu eramangarrian, eman gutxieneko karga bat, simulatu kraskadura bat (adibidez, portuak blokeatuz) eta ebaluatu aldatzeko abiadura. Nire ustez, modu honetan egun bat edo bi jolastu ondoren soilik konfiantza izan dezakezu teknologiaren funtzionamenduan. Beno, edo espero Interneten erdiak erabiltzen duen softwareak seguruenik funtzionatuko duela.

konfigurazioa

Askotan, konfigurazioa da tresnarekin lanean hasteko behar duzun lehen gauza. Eta dena funtzionatzen duenean, ez duzu konfigurazioa ukitu nahi ere. Ahalegin bat behar da zure burua ezarpenetara itzultzera eta arretaz pasatzera behartzeko. Nire oroimenean, gutxienez bi hutsegite larri izan genituen konfigurazioari arretarik ez izateagatik. Arreta berezia jarri puntu hauei:

• denbora-muga
  Konexio inaktiboak ixten direneko denbora (segundotan). 0 - ez itxi
  Gure liburutegi guztiek ez zuten gai izan konexioak behar bezala ixteko. Ezarpen hau desgaituz gero, bezero kopuruaren mugara iristeko arriskua dugu. Bestalde, halako arazoren bat baldin badago, galdutako konexioen amaiera automatikoak ezkutatuko du, eta agian ez gara ohartuko. Gainera, ez zenuke ezarpen hau gaitu behar iraunkorrak konexioak erabiltzen dituzunean.
• Gorde xy eta eranskinean bakarrik bai
  RDB argazki bat gordetzen.
  RDB/AOF gaiak zehatz-mehatz eztabaidatuko ditugu jarraian.
• stop-writes-on-bgsave-error ez eta slave-serve-stale-data bai
  Gaituta badago, RDB argazkia hausten bada, maisuak aldaketa-eskaerak onartzeari utziko dio. Maisuarekiko konexioa galtzen bada, esklaboak eskaerei erantzuten jarrai dezake (bai). Edo erantzuteari utziko dio (ez)
  Ez gaude pozik Redis kalabaza bilakatzen den egoerarekin.
• repl-ping-slave-period 5
  Denbora-tarte hori igarota, masterra matxuratu dela kezkatzen hasiko gara eta hutsegiteko prozedura burutzeko garaia dela.
  Eskuz positibo faltsuen eta hutsegite bat abiarazteko oreka bat aurkitu beharko duzu. Gure praktikan hau 5 segundo da.
• repl-backlog-size 1024mb eta epl-backlog-ttl 0
  Hainbeste datu gorde ditzakegu buffer batean huts egindako erreplika baterako. Buffer-a agortzen bada, guztiz sinkronizatu beharko duzu.
  Praktikak iradokitzen du hobe dela balio handiagoa ezartzea. Erreplika bat atzeratzen hasteko arrazoi asko daude. Atzeratuta badago, ziurrenik zure maisua aurre egiteko borrokan ari da jada, eta sinkronizazio osoa izango da azken txanpa.
• gehienez bezeroak 10000
  Bezero bakarreko gehienezko kopurua.
  Gure esperientziaren arabera, hobe da balio handiagoa ezartzea. Redis-ek 10k konexio ondo kudeatzen ditu. Ziurtatu sisteman nahikoa socket daudela.
• maxmemory-policy volatile-ttl
  Eskuragarri dagoen memoria-mugara iristen denean gakoak ezabatzeko araua.
  Hemen garrantzitsua dena ez da araua bera, hau nola gertatuko den ulertzea baizik. Redis memoria-mugara iristen denean normaltasunez lan egiteko duen gaitasuna goraipatu daiteke.

RDB eta AOF arazoak

Redis-ek berak informazio guztia RAMan gordetzen duen arren, datuak diskoan gordetzeko mekanismo bat ere badago. Zehazkiago, hiru mekanismo:

• RDB-snapshot - datu guztien argazki osoa. Ezarri GORDE XY konfigurazioa erabiliz eta "Gorde datu guztien argazki osoa X segundoro gutxienez Y teklak aldatu badira" dio.
• Erantsitzeko soilik fitxategia - eragiketen zerrenda egiten diren ordenan. Sarrerako eragiketa berriak gehitzen dizkio fitxategiari X segundoro edo Y eragiketa bakoitzean.
• RDB eta AOF aurreko bien konbinazioa dira.

Metodo guztiek beren abantailak eta desabantailak dituzte, ez ditut guztiak zerrendatuko, nire ustez begi-bistakoak ez diren puntuetan arreta jarriko dut.

Lehenik eta behin, RDB argazki bat gordetzeko FORK deitu behar da. Datu asko badaude, honek Redis guztiak zintzilikatu ditzake milisegundo batzuetatik segundo bateko tarte batean. Gainera, sistemak memoria esleitu behar du horrelako argazki baterako, eta horrek makina logikoan RAM hornidura bikoitza mantendu beharra dakar: Redis-erako 8 GB esleitzen badira, orduan 16 GB egon beharko luke makina birtualean. hura.

Bigarrenik, sinkronizazio partzialarekin arazoak daude. AOF moduan, esklaboa berriro konektatzen denean, sinkronizazio partziala egin beharrean, sinkronizazio osoa egin daiteke. Zergatik gertatzen den hau, ezin nuen ulertu. Baina merezi du hau gogoratzea.

Bi puntu hauek dagoeneko pentsarazten digute ea benetan behar ditugun datu horiek diskoan dena esklaboek bikoiztuta badago. Datuak esklabo guztiek huts egiten badute soilik galdu daitezke, eta hau "DC-ko sua" mailako arazoa da. Konpromiso gisa, esklaboetan soilik datuak gordetzea proposa dezakezu, baina kasu honetan ziurtatu behar duzu esklabo horiek ez direla inoiz maisu bihurtuko hondamendien berreskurapenean (horretarako esklaboen lehentasun-ezarpena dago haien konfigurazioan). Gure kabuz, kasu zehatz bakoitzean datuak diskoan gordetzea beharrezkoa den pentsatzen dugu, eta gehienetan "ez" da erantzuna.

Ondorioa

Amaitzeko, espero dut redis-cluster-ak nola funtzionatzen duen ideia orokor bat eman ahal izan dudala batere entzun ez dutenentzat, eta begi-bistakoak ez diren puntu batzuei ere arreta jarri didala erabiltzen ari direnentzat. denbora luzez.
Eskerrik asko zure denboragatik eta, beti bezala, gaiari buruzko iruzkinak ongi etorriak dira.

Iturria: www.habr.com