Kom by 'n produk wat al meer as 'n dekade ontwikkel, is dit glad nie verbasend om verouderde tegnologieë daarin te vind nie. Maar wat as jy oor ses maande die vrag 10 keer hoër moet hou, en die koste van valle sal honderde kere toeneem? In hierdie geval het jy 'n gawe Highload Engineer nodig. Maar in die afwesigheid van 'n bediende, het hulle my toevertrou om die probleem op te los. In die eerste deel van die artikel sal ek jou vertel hoe ons van Redis na Redis-cluster beweeg het, en in die tweede deel sal ek raad gee oor hoe om die cluster te begin gebruik en waarna om op te let wanneer jy dit gebruik.

Tegnologie Keuse

Is dit so erg? skei Redis (selfstandige redis) in 'n opset van 1 meester en N slawe? Hoekom noem ek dit uitgediende tegnologie?

Nee, Redis is nie so erg nie... Daar is egter 'n paar tekortkominge wat nie geïgnoreer kan word nie.

• Eerstens ondersteun Redis nie rampherstelmeganismes na 'n meestermislukking nie. Om hierdie probleem op te los, het ons 'n konfigurasie gebruik met outomatiese oordrag van VIP's na 'n nuwe meester, die rol van een van die slawe verander en die res verander. Hierdie meganisme het gewerk, maar dit kon nie 'n betroubare oplossing genoem word nie. Eerstens het vals alarms voorgekom, en tweedens was dit weggooibaar, en na operasie was handhandelinge nodig om die veer te laai.

• Tweedens, om net een meester te hê, het gelei tot die probleem van skeuring. Ons moes verskeie onafhanklike groepe "1 meester en N slawe" skep, en dan die databasisse met die hand onder hierdie masjiene versprei en hoop dat een van die databasisse môre nie soveel sou swel dat dit na 'n aparte instansie geskuif moet word nie.

Wat is die opsies?

• Die duurste en rykste oplossing is Redis-Enterprise. Dit is 'n boksoplossing met volledige tegniese ondersteuning. Ten spyte van die feit dat dit uit ’n tegniese oogpunt ideaal lyk, het dit ons om ideologiese redes nie gepas nie.
• Redis-cluster. Uit die boks is daar ondersteuning vir meester-failover en sharding. Die koppelvlak verskil amper nie van die gewone weergawe nie. Dit lyk belowend, ons sal later oor die slaggate praat.
• Tarantool, Memcache, Aerospike en ander. Al hierdie gereedskap doen omtrent dieselfde ding. Maar elkeen het sy eie tekortkominge. Ons het besluit om nie al ons eiers in een mandjie te sit nie. Ons gebruik Memcache en Tarantool vir ander take, en as ek vorentoe kyk, sal ek sê dat ons in ons praktyk meer probleme daarmee gehad het.

Spesifieke gebruik

Kom ons kyk na watter probleme ons histories met Redis opgelos het en watter funksionaliteit ons gebruik het:

• Kas voor versoeke na afgeleë dienste soos 2GIS | Golang
  

  KRY STEL MGET MSET "KIES DB"

• Kas voor MYSQL | PHP
  

  KRY STEL MGET MSET SCAN "KEY BY PATTERN" "SELECT DB"

• Die hoofberging vir die diens van werk met sessies en bestuurderkoördinate | Golang
  

  KRY STEL MGET MSET "KIES DB" "VOEG GEO SLEUTEL BY" "KRY GEO SLEUTEL" SKANDEER

Soos jy kan sien, geen hoër wiskunde nie. Wat is dan die moeilikheid? Kom ons kyk na elke metode afsonderlik.

metode
Beskrywing
Kenmerke van Redis-cluster
besluit

GEREED
Skryf/lees sleutel

MGET MSET
Skryf/lees verskeie sleutels
Die sleutels sal op verskillende nodusse wees. Klaargemaakte biblioteke kan slegs multi-operasies binne een nodus uitvoer
Vervang MGET met 'n pyplyn van N GET-bedrywighede

KIES DB
Kies die basis waarmee ons sal werk
Ondersteun nie veelvuldige databasisse nie
Plaas alles in een databasis. Voeg voorvoegsels by sleutels

SCAN
Gaan deur al die sleutels in die databasis
Aangesien ons een databasis het, is dit te duur om deur al die sleutels in die groepie te gaan
Handhaaf 'n onveranderlike binne een sleutel en doen 'n HSCAN op hierdie sleutel. Of weier heeltemal

GEO
Bedrywighede met 'n geosleutel
Die geosleutel is nie geskeur nie

SLEUTEL BY PATROON
Soek 'n sleutel volgens patroon
Aangesien ons een databasis het, sal ons oor alle sleutels in die groepie soek. Te duur
Weier of handhaaf die onveranderlike, soos in die geval van SCAN

Redis vs Redis-groepering

Wat verloor ons en wat kry ons as ons na 'n groep oorskakel?

• Nadele: ons verloor die funksionaliteit van verskeie databasisse.
  • As ons logies onverwante data in een groepie wil stoor, sal ons krukke in die vorm van voorvoegsels moet maak.
  • Ons verloor alle "basis" bewerkings, soos SCAN, DBSIZE, CLEAR DB, ens.
  • Multi-operasies het baie moeiliker geword om te implementeer omdat dit toegang tot verskeie nodusse kan vereis.
• voordele:
  • Foutverdraagsaamheid in die vorm van meester-failover.
  • Sharding aan die Redis-kant.
  • Dra data tussen nodusse atomies en sonder stilstand oor.
  • Voeg kapasiteit en vragte by en herverdeel dit sonder stilstand.

Ek sou tot die gevolgtrekking kom dat as jy nie 'n hoë vlak van foutverdraagsaamheid hoef te verskaf nie, dan is dit nie die moeite werd om na 'n kluster te beweeg nie, want dit kan 'n nie-triviale taak wees. Maar as jy aanvanklik tussen 'n aparte weergawe en 'n groepweergawe kies, moet jy 'n tros kies, aangesien dit nie erger is nie en jou boonop van die hoofpyne sal verlig

Berei voor om te beweeg

Kom ons begin met die vereistes vir verhuising:

• Dit moet naatloos wees. 'n Volledige stop van diens vir 5 minute pas ons nie.
• Dit moet so veilig en geleidelik as moontlik wees. Ek wil bietjie beheer oor die situasie hê. Ons wil nie alles op een slag gooi en oor die terugrol-knoppie bid nie.
• Minimale verlies aan data wanneer jy beweeg. Ons verstaan ​​dat dit baie moeilik sal wees om atomies te beweeg, so ons laat 'n mate van desinchronisasie toe tussen data in gereelde en gegroepeerde Redis.

Kluster instandhouding

Net voor die skuif moet ons dink of ons die groep kan ondersteun:

• Grafieke. Ons gebruik Prometheus en Grafana om SVE-lading, geheuegebruik, aantal kliënte, aantal GET-, SET-, AUTH-bewerkings, ens.
• Kundigheid. Stel jou voor dat jy môre 'n groot groep onder jou verantwoordelikheid sal hê. As dit breek, kan niemand anders as jy dit regmaak nie. As hy begin stadiger word, sal almal na jou toe hardloop. As jy hulpbronne moet byvoeg of die vrag moet herverdeel, kom terug na jou toe. Om nie op 25 grys te word nie, is dit raadsaam om vir hierdie gevalle voorsiening te maak en vooraf te kyk hoe die tegnologie onder sekere aksies sal optree. Kom ons praat in meer besonderhede hieroor in die afdeling "Kundigheid".
• Monitering en waarskuwings. Wanneer 'n groep breek, wil jy die eerste wees wat daarvan weet. Hier het ons onsself beperk tot 'n kennisgewing dat alle nodusse dieselfde inligting oor die toestand van die groep terugstuur (ja, dit gebeur anders). En ander probleme kan vinniger opgemerk word deur waarskuwings van Redis-kliëntedienste.

kruising

Hoe ons sal beweeg:

• Eerstens moet jy 'n biblioteek voorberei om met die groepering te werk. Ons het go-redis as basis vir die Go-weergawe geneem en dit 'n bietjie verander om onsself te pas. Ons het Multi-metodes deur pyplyne geïmplementeer, en het ook die reëls vir herhaling van versoeke effens reggestel. Die PHP-weergawe het meer probleme gehad, maar ons het uiteindelik op php-redis besluit. Hulle het onlangs groepsondersteuning ingestel en dit lyk na ons mening goed.
• Vervolgens moet u die groep self ontplooi. Dit word letterlik gedoen in twee opdragte gebaseer op die konfigurasielêer. Ons sal die instelling hieronder in meer besonderhede bespreek.
• Vir geleidelike beweging gebruik ons ​​droë-modus. Aangesien ons twee weergawes van die biblioteek het met dieselfde koppelvlak (een vir die gewone weergawe, die ander vir die cluster), kos dit niks om 'n omhulsel te skep wat met 'n aparte weergawe sal werk en in parallel alle versoeke na die cluster dupliseer, vergelyk antwoorde en skryf teenstrydighede in die logs (in ons geval in NewRelic). Dus, selfs al breek die groepweergawe tydens ontplooiing, sal ons produksie nie geraak word nie.
• Nadat ons die groep in droë modus uitgerol het, kan ons rustig na die grafiek van reaksieverskille kyk. As die foutkoers stadig maar seker na een of ander klein konstante beweeg, dan is alles in orde. Hoekom is daar nog teenstrydighede? Omdat opname in 'n aparte weergawe 'n bietjie vroeër as in die groep plaasvind, en as gevolg van mikrolag, kan die data verskil. Al wat oorbly is om te kyk na die teenstrydigheid logs, en as hulle almal verklaar word deur die nie-atomisiteit van die rekord, dan kan ons aanbeweeg.
• Nou kan jy droë-modus in die teenoorgestelde rigting verander. Ons sal uit die groep skryf en lees, en dit in 'n aparte weergawe dupliseer. Vir wat? Oor die volgende week wil ek graag die werk van die groep waarneem. As dit skielik blyk dat daar probleme met spitslading is, of ons het iets nie in ag geneem nie, het ons altyd 'n noodherstel na die ou kode en huidige data danksy droë-modus.
• Al wat oorbly, is om droëmodus uit te skakel en die aparte weergawe uitmekaar te haal.

Kundigheid

Eerstens, kortliks oor die groepontwerp.

Eerstens is Redis 'n sleutelwaardewinkel. Arbitrêre snare word as sleutels gebruik. Getalle, stringe en hele strukture kan as waardes gebruik word. Daar is baie van laasgenoemde, maar om die algemene struktuur te verstaan ​​is dit nie vir ons belangrik nie.
Die volgende vlak van abstraksie na sleutels is slots (SLOTS). Elke sleutel behoort aan een van 16 383 gleuwe. Daar kan enige aantal sleutels binne elke gleuf wees. Dus word alle sleutels in 16 383 onsamehangende stelle verdeel.

Vervolgens moet daar N meesternodusse in die groep wees. Elke nodus kan beskou word as 'n aparte Redis-instansie wat alles van ander nodusse binne die groep weet. Elke meesternodus bevat 'n aantal gleuwe. Elke gleuf behoort aan slegs een hoofnodus. Alle gleuwe moet tussen nodusse versprei word. As sommige gleuwe nie toegewys word nie, sal die sleutels wat daarin gestoor is, ontoeganklik wees. Dit maak sin om elke hoofnodus op 'n aparte logiese of fisiese masjien te laat loop. Dit is ook die moeite werd om te onthou dat elke nodus net op een kern loop, en as jy verskeie Redis-gevalle op dieselfde logiese masjien wil laat loop, maak seker dat hulle op verskillende kerns loop (ons het dit nie probeer nie, maar in teorie behoort dit te werk) . In wese bied meesternodusse gereelde versplintering, en meer meesternodusse laat skryf- en leesversoeke toe om te skaal.

Nadat al die sleutels onder die gleuwe versprei is, en die gleuwe onder die meesternodusse versprei is, kan 'n arbitrêre aantal slaafnodusse by elke meesterknooppunt gevoeg word. Binne elke so 'n meester-slaaf skakel, sal normale replikasie werk. Slawe word benodig om leesversoeke te skaal en vir failover in geval van meestermislukking.

Kom ons praat nou oor operasies wat dit beter sal wees om te kan doen.

Ons sal toegang tot die stelsel verkry deur Redis-CLI. Aangesien Redis nie 'n enkele toegangspunt het nie, kan jy die volgende bewerkings op enige van die nodusse uitvoer. Op elke punt vestig ek afsonderlik die aandag op die moontlikheid om die operasie onder las uit te voer.

• Die eerste en belangrikste ding wat ons nodig het, is die kluster nodusse werking. Dit gee die toestand van die groep terug, wys 'n lys nodusse, hul rolle, gleufverspreiding, ens. Meer inligting kan verkry word deur gebruik te maak van groepinligting en groepgleuwe.
• Dit sal lekker wees om nodusse te kan byvoeg en verwyder. Vir hierdie doel is daar cluster meet en cluster vergeet bedrywighede. Neem asseblief kennis dat groepvergeet op ELKE nodus toegepas moet word, beide meesters en replikas. En cluster meet hoef net op een nodus geroep te word. Hierdie verskil kan ontstellend wees, daarom is dit die beste om daaroor te leer voordat jy met jou groep gaan woon. Die byvoeging van 'n nodus word veilig in die geveg gedoen en beïnvloed op geen manier die werking van die groepering nie (wat logies is). As jy 'n nodus uit die cluster gaan verwyder, moet jy seker maak dat daar geen gleuwe daarop oor is nie (anders loop jy die risiko om toegang tot al die sleutels op hierdie node te verloor). Moet ook nie 'n meester uitvee wat slawe het nie, anders sal 'n onnodige stem vir 'n nuwe meester uitgevoer word. As die nodusse nie meer gleuwe het nie, dan is dit 'n klein probleem, maar hoekom het ons ekstra keuses nodig as ons eers die slawe kan uitvee.
• As jy die meester- en slaafposisies met geweld moet omruil, sal die cluster failover-opdrag werk. As u dit in die geveg noem, moet u verstaan ​​dat die meester nie tydens die operasie beskikbaar sal wees nie. Tipies vind die skakelaar in minder as 'n sekonde plaas, maar is nie atoom nie. Jy kan verwag dat sommige versoeke aan die meester gedurende hierdie tyd sal misluk.
• Voordat 'n nodus uit die groep verwyder word, moet daar geen gleuwe daarop oorbly nie. Dit is beter om hulle te herverdeel met behulp van die cluster reshard-opdrag. Slots sal van een meester na 'n ander oorgedra word. Die hele operasie kan 'n paar minute neem, dit hang af van die volume data wat oorgedra word, maar die oordragproses is veilig en beïnvloed op geen manier die werking van die groepering nie. Dus kan alle data direk onder vrag van een nodus na 'n ander oorgedra word, en sonder om bekommerd te wees oor die beskikbaarheid daarvan. Daar is egter ook subtiliteite. Eerstens word data-oordrag geassosieer met 'n sekere las op die ontvanger en sender nodusse. As die ontvanger nodus reeds swaar op die verwerker gelaai is, moet jy dit nie laai met die ontvangs van nuwe data nie. Tweedens, sodra daar nie 'n enkele gleuf op die stuurmeester oor is nie, sal al sy slawe onmiddellik na die meester gaan waarheen hierdie gleuwe oorgeplaas is. En die probleem is dat al hierdie slawe data op een slag wil sinchroniseer. En jy sal gelukkig wees as dit gedeeltelike eerder as volledige sinchronisasie is. Neem dit in ag en kombineer die bedrywighede van die oordrag van gleuwe en die deaktivering/oordrag van slawe. Of hoop dat jy 'n voldoende veiligheidsmarge het.
• Wat moet jy doen as jy tydens die oordrag vind dat jy jou gleuwe iewers verloor het? Ek hoop nie hierdie probleem raak jou nie, maar as dit wel gebeur, is daar 'n cluster fix-operasie. Sy sal ten minste die gleuwe oor die nodusse in 'n ewekansige volgorde strooi. Ek beveel aan dat u die werking daarvan nagaan deur eers die nodus met verspreide gleuwe uit die groepie te verwyder. Aangesien data in ongeallokeerde gleuwe reeds nie beskikbaar is nie, is dit te laat om bekommerd te wees oor probleme met die beskikbaarheid van hierdie gleuwe. Op sy beurt sal die operasie nie verspreide gleuwe beïnvloed nie.
• Nog 'n nuttige operasie is monitor. Dit laat jou toe om intyds die hele lys van versoeke wat na die nodus gaan, te sien. Boonop kan jy dit grep en uitvind of daar die nodige verkeer is.

Dit is ook die moeite werd om die meester failover-prosedure te noem. Kortom, dit bestaan, en na my mening werk dit uitstekend. Moet egter nie dink dat as jy die kragkoord op 'n masjien met 'n meesterknoop loskoppel, Redis dadelik sal oorskakel en kliënte sal nie die verlies agterkom nie. In my praktyk vind die oorskakeling in 'n paar sekondes plaas. Gedurende hierdie tyd sal sommige van die data onbeskikbaar wees: die meester se onbeskikbaarheid word bespeur, nodusse stem vir 'n nuwe een, slawe word oorgeskakel, data word gesinchroniseer. Die beste manier om self seker te maak dat die skema werk, is om plaaslike oefeninge uit te voer. Lig die groepie op jou skootrekenaar op, gee dit 'n minimum las, simuleer 'n ongeluk (byvoorbeeld deur die poorte te blokkeer), en evalueer die skakelspoed. Na my mening, eers nadat jy vir 'n dag of twee op hierdie manier gespeel het, kan jy vol vertroue wees in die werking van die tegnologie. Wel, of hoop dat die sagteware wat die helfte van die internet gebruik waarskynlik werk.

opset

Dikwels is die konfigurasie die eerste ding wat jy nodig het om met die nutsding te begin werk. En wanneer alles werk, wil jy nie eers aan die konfigurasie raak nie. Dit verg 'n bietjie moeite om jouself te dwing om terug te gaan na die instellings en dit noukeurig deur te gaan. In my geheue het ons ten minste twee ernstige mislukkings gehad as gevolg van onoplettendheid aan die konfigurasie. Gee spesiale aandag aan die volgende punte:

• time-out 0
  Tyd waarna onaktiewe verbindings gesluit word (in sekondes). 0 - moenie toemaak nie
  Nie elke biblioteek van ons kon verbindings korrek sluit nie. Deur hierdie instelling te deaktiveer, loop ons die risiko om die limiet op die aantal kliënte te bereik. Aan die ander kant, as daar so 'n probleem is, sal outomatiese beëindiging van verlore verbindings dit masker, en ons sal dit dalk nie sien nie. Boonop moet u nie hierdie instelling aktiveer wanneer u aanhoudende verbindings gebruik nie.
• Stoor xy en bykomende ja
  Stoor tans 'n RDB-snapshot.
  Ons sal RDB/AOF-kwessies hieronder in detail bespreek.
• stop-skryf-op-bgsave-fout nee & slaaf-dien-verouderde-data ja
  Indien geaktiveer, as die RDB-snapshot breek, sal die meester ophou om veranderingsversoeke te aanvaar. As die verbinding met die meester verloor word, kan die slaaf voortgaan om op versoeke te reageer (ja). Of sal ophou reageer (nee)
  Ons is nie gelukkig met die situasie waarin Redis in 'n pampoen verander nie.
• repl-ping-slaaf-tydperk 5
  Na hierdie tydperk sal ons begin bekommerd wees dat die meester gebreek het en dit is tyd om die failover-prosedure uit te voer.
  U sal met die hand 'n balans moet vind tussen vals positiewe en die aanvang van 'n failover. In ons praktyk is dit 5 sekondes.
• repl-backlog-grootte 1024mb & epl-backlog-ttl 0
  Ons kan presies soveel data in 'n buffer stoor vir 'n mislukte replika. As die buffer opraak, sal jy heeltemal moet sinchroniseer.
  Die praktyk dui daarop dat dit beter is om 'n hoër waarde te stel. Daar is baie redes waarom 'n replika kan begin agterbly. As dit agterbly, sukkel u meester waarskynlik reeds om dit te hanteer, en volle sinchronisasie sal die laaste strooi wees.
• maksimum kliënte 10000
  Maksimum aantal eenmalige kliënte.
  In ons ervaring is dit beter om 'n hoër waarde te stel. Redis hanteer 10k verbindings goed. Maak net seker daar is genoeg voetstukke op die stelsel.
• maxmemory-beleid wisselvallige-ttl
  Die reël waarvolgens sleutels uitgevee word wanneer die beskikbare geheuelimiet bereik word.
  Wat hier belangrik is, is nie die reël self nie, maar die begrip van hoe dit sal gebeur. Redis kan geprys word vir sy vermoë om normaal te werk wanneer die geheuelimiet bereik word.

RDB en AOF probleme

Alhoewel Redis self alle inligting in RAM stoor, is daar ook 'n meganisme om data op skyf te stoor. Meer presies, drie meganismes:

• RDB-snapshot - 'n volledige momentopname van alle data. Stel met behulp van die SAVE XY-konfigurasie en lees "Stoor 'n volledige momentopname van alle data elke X sekondes as ten minste Y-sleutels verander het."
• Slegs byvoeg-lêer - 'n lys van bewerkings in die volgorde wat hulle uitgevoer word. Voeg nuwe inkomende bewerkings by die lêer elke X sekondes of elke Y bewerkings.
• RDB en AOF is 'n kombinasie van die vorige twee.

Alle metodes het hul voor- en nadele, ek sal nie almal lys nie, ek sal net die aandag vestig op punte wat na my mening nie voor die hand liggend is nie.

Eerstens, om 'n RDB-kiekie te stoor, vereis dat jy FORK roep. As daar baie data is, kan dit die hele Redis vir 'n tydperk van 'n paar millisekondes tot 'n sekonde hang. Daarbenewens moet die stelsel geheue toewys vir so 'n momentopname, wat lei tot die behoefte om 'n dubbele voorraad RAM op die logiese masjien te hou: as 8 GB vir Redis toegeken word, moet 16 GB beskikbaar wees op die virtuele masjien met Dit.

Tweedens is daar probleme met gedeeltelike sinchronisasie. In AOF-modus, wanneer die slaaf weer gekoppel is, in plaas van gedeeltelike sinchronisasie, kan volle sinchronisasie uitgevoer word. Hoekom dit gebeur, kon ek nie verstaan ​​nie. Maar dit is die moeite werd om dit te onthou.

Hierdie twee punte laat ons reeds dink of ons regtig hierdie data op die skyf nodig het as alles reeds deur slawe gedupliseer is. Data kan slegs verlore gaan as alle slawe misluk, en dit is 'n "brand in die DC" vlak probleem. As 'n kompromie kan jy voorstel om data slegs op slawe te stoor, maar in hierdie geval moet jy seker maak dat hierdie slawe nooit 'n meester sal word tydens rampherstel nie (hiervoor is daar 'n slaaf-prioriteitinstelling in hul konfigurasie). Vir onsself dink ons ​​in elke spesifieke geval aan of dit nodig is om data op skyf te stoor, en die antwoord is meestal "nee".

Gevolgtrekking

Ten slotte, ek hoop dat ek 'n algemene idee kon gee van hoe redis-cluster werk vir diegene wat glad nie daarvan gehoor het nie, en het ook die aandag gevestig op 'n paar nie-vanselfsprekende punte vir diegene wat dit gebruik het vir 'n lang tyd.
Dankie vir jou tyd en, soos altyd, is kommentaar oor die onderwerp welkom.

Bron: will.com