Če pridemo do izdelka, ki se je razvijal več kot desetletje, sploh ni presenetljivo, da v njem najdemo zastarele tehnologije. Kaj pa, če boste v šestih mesecih morali obdržati 10-krat večjo obremenitev in se bodo stroški padcev povečali stokrat? V tem primeru potrebujete kul Highload inženirja. A v odsotnosti sobarice so mi zaupali reševanje problema. V prvem delu članka vam bom povedal, kako smo iz Redisa prešli na Redis-cluster, v drugem delu pa bom svetoval, kako začeti uporabljati gručo in na kaj morate biti pozorni pri njeni uporabi.

Izbira tehnologije

Je tako hudo? loči Redis (samostojni redis) v konfiguraciji 1 glavnega in N podrejenih? Zakaj jo imenujem zastarela tehnologija?

Ne, Redis ni tako slab ... Vendar pa obstajajo nekatere pomanjkljivosti, ki jih ni mogoče prezreti.

• Prvič, Redis ne podpira mehanizmov za obnovitev po katastrofi po glavni napaki. Za rešitev tega problema smo uporabili konfiguracijo s samodejnim prenosom VIP-jev na novega masterja, spremembo vloge enega od podrejenih in zamenjavo ostalih. Ta mehanizem je deloval, vendar ga ni bilo mogoče imenovati zanesljiva rešitev. Prvič, pojavili so se lažni alarmi, in drugič, bil je za enkratno uporabo in po delovanju so bila potrebna ročna dejanja za polnjenje vzmeti.

• Drugič, samo en mojster je povzročil problem razrezovanja. Ustvariti smo morali več neodvisnih grozdov »1 master in N slaves«, nato ročno porazdeliti baze podatkov med te stroje in upati, da se jutri katera od baz ne bo tako razmahnila, da bi jo bilo treba premakniti na ločeno instanco.

Kakšne so možnosti?

• Najdražja in najbogatejša rešitev je Redis-Enterprise. To je škatlasta rešitev s popolno tehnično podporo. Kljub temu, da je s tehničnega vidika videti idealno, nam iz ideoloških razlogov ni ustrezalo.
• Redis-gruča. Že takoj je na voljo podpora za glavni preklop in razdeljevanje. Vmesnik se skoraj ne razlikuje od običajne različice. Videti je obetavno, kasneje bomo govorili o pasteh.
• Tarantool, Memcache, Aerospike in drugi. Vsa ta orodja delujejo skoraj enako. Toda vsak ima svoje pomanjkljivosti. Odločili smo se, da ne bomo dali vseh jajc v eno košaro. Za druga opravila uporabljamo Memcache in Tarantool in če pogledam naprej, bom rekel, da je bilo v naši praksi z njimi več težav.

Posebnosti uporabe

Oglejmo si, katere težave smo v preteklosti reševali z Redisom in katere funkcionalnosti smo uporabljali:

• Predpomnilnik pred zahtevami za oddaljene storitve, kot je 2GIS | Golang
  

  GET SET MGET MSET "IZBERI DB"

• Predpomnilnik pred MYSQL | PHP
  

  GET SET MGET MSET SCAN "KLJUČ PO VZORCU" "IZBERI DB"

• Glavni pomnilnik za storitev dela s sejami in voznikovimi koordinatami | Golang
  

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

Kot lahko vidite, ni višje matematike. V čem je potem težava? Oglejmo si vsako metodo posebej.

Metoda
Opis
Značilnosti grozda Redis
odločitev

PRIPRAVI SE
Tipka za pisanje/branje

MGET MSET
Pisanje/branje več ključev
Ključi bodo na različnih vozliščih. Pripravljene knjižnice lahko izvajajo več operacij samo znotraj enega vozlišča
Zamenjajte MGET s cevovodom N operacij GET

IZBERI DB
Izberite osnovo, s katero bomo delali
Ne podpira več baz podatkov
Vse postavite v eno bazo podatkov. Dodajte predpone ključem

SCAN
Preglejte vse ključe v bazi podatkov
Ker imamo eno bazo podatkov, je pregledovanje vseh ključev v gruči predrago
Ohranite invariant znotraj enega ključa in naredite HSCAN na tem ključu. Ali popolnoma zavrniti

GEO
Operacije z geoključem
Geoključ ni razdeljen

KLJUČ PO VZORCU
Iskanje ključa po vzorcu
Ker imamo eno bazo podatkov, bomo iskali po vseh ključih v gruči. Predrago
Zavrnite ali ohranite invarianto, kot v primeru SCAN

Redis proti Redis-gruči

Kaj izgubimo in kaj pridobimo s prehodom na gručo?

• Slabosti: izgubimo funkcionalnost več baz podatkov.
  • Če želimo logično nepovezane podatke shraniti v eno gručo, bomo morali narediti bergle v obliki predpon.
  • Izgubimo vse »osnovne« operacije, kot so SCAN, DBSIZE, CLEAR DB itd.
  • Večoperacije je postalo veliko težje izvajati, ker lahko zahtevajo dostop do več vozlišč.
• Pluse:
  • Toleranca napak v obliki glavnega preklopa.
  • Sharding na strani Redis.
  • Prenašajte podatke med vozlišči atomsko in brez izpadov.
  • Dodajte in prerazporedite zmogljivost in obremenitve brez izpadov.

Sklenil bi, da če vam ni treba zagotoviti visoke stopnje tolerance napak, se prehod na gručo ne splača, ker je to lahko netrivialna naloga. Če pa na začetku izbirate med ločeno različico in gručno različico, potem raje izberite gručasto, saj ni nič slabša, poleg tega pa vas bo razbremenila nekaterih preglavic

Priprava na selitev

Začnimo z zahtevami za selitev:

• Moralo bi biti brezhibno. Popolna zaustavitev storitve za 5 minut nam ne ustreza.
• Poteka naj čim bolj varno in postopoma. Želim imeti nekaj nadzora nad situacijo. Nočemo pustiti vsega naenkrat in moliti nad gumbom za povrnitev.
• Minimalna izguba podatkov pri premikanju. Zavedamo se, da bo zelo težko premikati atomsko, zato dopuščamo nekaj desinhronizacije med podatki v navadnem in gručnem Redisu.

Vzdrževanje grozda

Tik pred selitvijo moramo razmisliti, ali lahko podpiramo grozd:

• Grafikoni. Prometheus in Grafana uporabljamo za prikaz grafov obremenitve procesorja, porabe pomnilnika, števila odjemalcev, števila operacij GET, SET, AUTH itd.
• Strokovnost. Predstavljajte si, da boste jutri imeli pod svojo odgovornostjo ogromen grozd. Če se pokvari, ga ne more popraviti nihče razen vas. Če začne upočasnjevati, bodo vsi tekli proti vam. Če morate dodati vire ali prerazporediti breme, se vrnite k sebi. Da ne bi postali sivi pri 25 letih, je priporočljivo predvideti te primere in vnaprej preveriti, kako se bo tehnologija obnašala pod določenimi dejanji. Pogovorimo se o tem podrobneje v razdelku »Strokovno znanje«.
• Spremljanje in opozorila. Ko se grozd pokvari, želite biti prvi, ki bo izvedel za to. Tu smo se omejili na obvestilo, da vsa vozlišča vrnejo enake informacije o stanju gruče (ja, zgodi se drugače). Druge težave pa lahko hitreje opazite z opozorili odjemalskih storitev Redis.

Selitev

Kako se bomo premikali:

• Najprej morate pripraviti knjižnico za delo z gručo. Za osnovo različice Go smo vzeli go-redis in ga nekoliko spremenili, da nam ustreza. Implementirali smo Multi-methods preko cevovodov in tudi nekoliko popravili pravila za ponavljajoče se zahteve. Različica PHP je imela več težav, vendar smo se na koncu odločili za php-redis. Pred kratkim so uvedli podporo za grozde in po našem mnenju izgleda dobro.
• Nato morate razmestiti samo gručo. To se izvede dobesedno v dveh ukazih, ki temeljita na konfiguracijski datoteki. Spodaj bomo podrobneje obravnavali nastavitev.
• Za postopno premikanje uporabljamo suhi način. Ker imamo dve različici knjižnice z enakim vmesnikom (eno za navadno različico, drugo za gručo), nič ne stane ustvariti ovoja, ki bo deloval z ločeno verzijo in vzporedno podvajal vse zahteve v gručo, primerjajte odgovore in zapišite neskladja v dnevnike (v našem primeru v NewRelic). Tudi če se različica gruče med uvajanjem pokvari, to ne bo vplivalo na našo proizvodnjo.
• Ko smo gručo razgrnili v suhem načinu, lahko mirno pogledamo graf neskladij odzivov. Če se stopnja napak počasi, a zanesljivo premika proti neki majhni konstanti, potem je vse v redu. Zakaj še vedno obstajajo odstopanja? Ker se snemanje v ločeni različici zgodi nekoliko prej kot v gruči, in zaradi mikrozamika se lahko podatki razlikujejo. Vse, kar ostane, je, da pogledamo dnevnike neskladij, in če so vsi razloženi z neatomičnostjo zapisa, potem lahko nadaljujemo.
• Zdaj lahko suhi način preklopite v nasprotno smer. Iz gruče bomo pisali in brali ter jo podvojili v ločeno različico. Za kaj? V naslednjem tednu bi rad opazoval delo grozda. Če se nenadoma izkaže, da obstajajo težave pri največji obremenitvi ali česa nismo upoštevali, imamo vedno v sili vrnitev na staro kodo in trenutne podatke zahvaljujoč suhemu načinu.
• Vse kar ostane je, da onemogočite suhi način in razstavite ločeno različico.

Экспертиза

Najprej na kratko o zasnovi grozda.

Prvič, Redis je trgovina s ključno vrednostjo. Kot ključi se uporabljajo poljubni nizi. Kot vrednosti se lahko uporabljajo številke, nizi in celotne strukture. Slednjih je zelo veliko, vendar za razumevanje splošne strukture to za nas ni pomembno.
Naslednja stopnja abstrakcije po ključih so reže (SLOTS). Vsak ključ pripada eni od 16 rež. V vsaki reži je lahko poljubno število ključev. Tako so vsi ključi razdeljeni na 383 disjunktnih nizov.

Nato mora biti v gruči N glavnih vozlišč. Vsako vozlišče si lahko predstavljamo kot ločen primer Redisa, ki ve vse o drugih vozliščih znotraj gruče. Vsako glavno vozlišče vsebuje več rež. Vsaka reža pripada samo enemu glavnemu vozlišču. Vse reže je treba porazdeliti med vozlišča. Če nekatere reže niso dodeljene, bodo ključi, shranjeni v njih, nedostopni. Smiselno je zagnati vsako glavno vozlišče na ločenem logičnem ali fizičnem računalniku. Prav tako si velja zapomniti, da vsako vozlišče deluje samo v enem jedru, in če želite zagnati več primerkov Redisa na istem logičnem stroju, se prepričajte, da delujejo v različnih jedrih (tega nismo poskusili, a v teoriji bi moralo delovati) . V bistvu glavna vozlišča zagotavljajo redno razčlenjevanje, več glavnih vozlišč pa omogoča pisalne in bralne zahteve v merilu.

Ko so vsi ključi porazdeljeni med reže in so reže razpršene med glavnimi vozlišči, lahko vsakemu glavnemu vozlišču dodate poljubno število podrejenih vozlišč. Znotraj vsake take povezave glavni-podrejeni bo normalno podvajanje delovalo. Podrejeni so potrebni za prilagajanje zahtev za branje in za samodejni preklop v primeru okvare glavnega.

Zdaj pa se pogovorimo o operacijah, ki bi jih bilo bolje izvesti.

Do sistema bomo dostopali preko Redis-CLI. Ker Redis nima ene same vstopne točke, lahko izvajate naslednje operacije na katerem koli od vozlišč. Pri vsaki točki posebej opozarjam na možnost izvedbe operacije pod obremenitvijo.

• Prva in najpomembnejša stvar, ki jo potrebujemo, je delovanje vozlišč gruče. Vrne stanje gruče, prikaže seznam vozlišč, njihove vloge, porazdelitev rež itd. Več informacij je mogoče pridobiti z informacijami o gruči in režami za gruče.
• Lepo bi bilo, če bi lahko dodajali in odstranjevali vozlišča. V ta namen obstajata operaciji srečanja gruče in pozabe gruče. Upoštevajte, da je treba pozabo gruče uporabiti za VSAKO vozlišče, tako glavne kot replike. In srečanje gruče je treba poklicati samo na enem vozlišču. Ta razlika je lahko zaskrbljujoča, zato je najbolje, da se o njej poučite, preden začnete uporabljati svojo gručo. Dodajanje vozlišča poteka varno v bitki in na noben način ne vpliva na delovanje gruče (kar je logično). Če nameravate vozlišče odstraniti iz gruče, se prepričajte, da na njem ni več nobenih rež (sicer tvegate izgubo dostopa do vseh ključev na tem vozlišču). Prav tako ne brišite masterja, ki ima podrejene, sicer bo izvedeno nepotrebno glasovanje za novega masterja. Če vozlišča nimajo več rež, potem je to majhen problem, ampak zakaj potrebujemo dodatne možnosti, če lahko najprej izbrišemo podrejene.
• Če morate na silo zamenjati glavni in podrejeni položaj, bo zadostoval ukaz za preklop gruče. Ko ga kličete v bitki, morate razumeti, da poveljnik med operacijo ne bo na voljo. Običajno se preklop zgodi v manj kot sekundi, vendar ni atomaren. Pričakujete lahko, da bodo nekatere zahteve do glavnega v tem času neuspešne.
• Preden vozlišče odstranite iz gruče, na njem ne sme ostati nobena reža. Bolje jih je prerazporediti z ukazom cluster reshard. Reže bodo prenesene z enega masterja na drugega. Celotna operacija lahko traja nekaj minut, odvisno od količine podatkov, ki se prenašajo, vendar je proces prenosa varen in na noben način ne vpliva na delovanje gruče. Tako se lahko vsi podatki prenašajo iz enega vozlišča v drugega neposredno pod obremenitvijo in brez skrbi glede njihove razpoložljivosti. Vendar pa obstajajo tudi tankosti. Prvič, prenos podatkov je povezan z določeno obremenitvijo vozlišč prejemnika in pošiljatelja. Če je prejemno vozlišče že močno obremenjeno na procesorju, ga ne smete obremenjevati s sprejemanjem novih podatkov. Drugič, takoj ko na glavnem pošiljatelju ne ostane nobena reža, bodo vsi njegovi podrejeni takoj odšli na glavni, na katerega so bile te reže prenesene. In težava je v tem, da bodo vsi ti sužnji želeli sinhronizirati podatke hkrati. Imeli boste srečo, če bo šlo za delno in ne popolno sinhronizacijo. Upoštevajte to in kombinirajte operacije prenosa slotov in onemogočanje/prenos podrejenih. Ali upajte, da imate dovolj varnostne rezerve.
• Kaj storiti, če med prenosom ugotovite, da ste nekje izgubili svoja mesta? Upam, da ta težava ne vpliva na vas, če pa se, obstaja operacija popravka gruče. Vsaj razpršila bo reže po vozliščih v naključnem vrstnem redu. Priporočam, da preverite njegovo delovanje tako, da najprej odstranite vozlišče s porazdeljenimi režami iz gruče. Ker podatki v nedodeljenih slotih že niso na voljo, je prepozno skrbeti za težave z razpoložljivostjo teh slotov. Po drugi strani pa operacija ne bo vplivala na porazdeljene reže.
• Druga uporabna operacija je monitor. Omogoča vam, da si v realnem času ogledate celoten seznam zahtev, ki gredo v vozlišče. Poleg tega ga lahko grep in ugotovite, ali je potreben promet.

Omeniti velja tudi postopek master failover. Skratka, obstaja in po mojem mnenju deluje odlično. Vendar ne mislite, da če izključite napajalni kabel na napravi z glavnim vozliščem, bo Redis takoj preklopil in stranke ne bodo opazile izgube. V moji praksi se preklop zgodi v nekaj sekundah. V tem času nekateri podatki ne bodo na voljo: zaznana je nerazpoložljivost nadrejenega, vozlišča glasujejo za novega, podrejeni so preklopljeni, podatki se sinhronizirajo. Najboljši način, da se prepričate, da shema deluje, je izvajanje lokalnih vaj. Dvignite gručo na prenosnem računalniku, ji dajte minimalno obremenitev, simulirajte zrušitev (na primer z blokiranjem vrat) in ocenite hitrost preklapljanja. Po mojem mnenju si šele po takem igranju dan ali dva lahko prepričan v delovanje tehnologije. No, ali upam, da programska oprema, ki jo uporablja polovica interneta, verjetno deluje.

Konfiguracija

Pogosto je konfiguracija prva stvar, ki jo potrebujete za začetek dela z orodjem. In ko vse deluje, se konfiguracije sploh ne želite dotakniti. Potrebujete nekaj truda, da se prisilite, da se vrnete na nastavitve in jih natančno pregledate. V mojem spominu smo imeli vsaj dve hudi okvari zaradi nepazljivosti pri konfiguraciji. Bodite posebno pozorni na naslednje točke:

• časovna omejitev 0
  Čas, po katerem se neaktivne povezave zaprejo (v sekundah). 0 - ne zapri
  Ni vsaka naša knjižnica znala pravilno zapreti povezav. Če onemogočimo to nastavitev, tvegamo, da dosežemo omejitev števila strank. Po drugi strani pa, če obstaja taka težava, jo samodejno prekinitev izgubljenih povezav prikrije in morda ne bomo opazili. Poleg tega ne smete omogočiti te nastavitve, ko uporabljate trajne povezave.
• Shrani xy & appendonly da
  Shranjevanje posnetka RDB.
  Spodaj bomo podrobno obravnavali vprašanja RDB/AOF.
• stop-writes-on-bgsave-error no & slave-serve-stale-data da
  Če je omogočeno, če se posnetek RDB pokvari, glavni ne bo več sprejemal zahtev za spremembe. Če se povezava z nadrejenim prekine, lahko podrejeni še naprej odgovarja na zahteve (da). Ali se ne bo več odzival (ne)
  Nismo zadovoljni s situacijo, v kateri se Redis spreminja v bučo.
• repl-ping-slave-period 5
  Po tem času nas bo začelo skrbeti, da se je master pokvaril in je čas, da izvedemo postopek preklopa.
  Ročno boste morali najti ravnotežje med lažnimi pozitivnimi rezultati in sprožitvijo samodejnega preklopa. V naši praksi je to 5 sekund.
• repl-backlog-size 1024mb & epl-backlog-ttl 0
  Točno toliko podatkov lahko shranimo v medpomnilnik za neuspešno repliko. Če medpomnilnika zmanjka, se boste morali popolnoma sinhronizirati.
  Praksa kaže, da je bolje nastaviti višjo vrednost. Obstaja veliko razlogov, zakaj lahko replika začne zaostajati. Če zaostaja, potem se najverjetneje vaš mojster že trudi obvladati in popolna sinhronizacija bo zadnja slama.
• največje število strank 10000
  Največje število enkratnih strank.
  Po naših izkušnjah je bolje nastaviti višjo vrednost. Redis dobro obvlada 10k povezav. Prepričajte se le, da je v sistemu dovolj vtičnic.
• maxmemory-policy volatile-ttl
  Pravilo, po katerem se ključi izbrišejo, ko je dosežena omejitev razpoložljivega pomnilnika.
  Pri tem ni pomembno samo pravilo, ampak razumevanje, kako se bo to zgodilo. Redis lahko pohvalimo za normalno delovanje, ko je dosežena omejitev pomnilnika.

Težave z RDB in AOF

Čeprav Redis sam shranjuje vse informacije v RAM, obstaja tudi mehanizem za shranjevanje podatkov na disk. Natančneje, trije mehanizmi:

• RDB-posnetek - popoln posnetek vseh podatkov. Nastavite s konfiguracijo SAVE XY in se glasi »Shrani celoten posnetek vseh podatkov vsakih X sekund, če so se spremenile vsaj Y tipke.«
• Datoteka samo za dodajanje – seznam operacij v vrstnem redu, v katerem so izvedene. Doda nove dohodne operacije v datoteko vsakih X sekund ali vsakih Y operacij.
• RDB in AOF sta kombinacija prejšnjih dveh.

Vse metode imajo svoje prednosti in slabosti, ne bom našteval vseh, opozoril bom le na točke, ki po mojem mnenju niso očitne.

Prvič, shranjevanje posnetka RDB zahteva klic FORK. Če je podatkov veliko, lahko to prekine ves Redis za nekaj milisekund do sekunde. Poleg tega mora sistem dodeliti pomnilnik za takšen posnetek, kar vodi do potrebe po dvojni zalogi RAM-a na logičnem stroju: če je za Redis dodeljenih 8 GB, mora biti na virtualnem stroju na voljo 16 GB z to.

Drugič, obstajajo težave z delno sinhronizacijo. V načinu AOF, ko je podrejena enota ponovno povezana, se namesto delne sinhronizacije lahko izvede popolna sinhronizacija. Zakaj se to zgodi, nisem mogel razumeti. Toda to je vredno zapomniti.

Že ti dve točki nam dajeta misliti, ali res potrebujemo te podatke na disku, če je vse že podvojeno s sužnji. Podatki se lahko izgubijo le, če vsi podrejeni odpovejo, in to je težava na ravni "požara v DC". Kot kompromis lahko predlagate shranjevanje podatkov samo na podrejene, vendar se morate v tem primeru prepričati, da ti podrejeni med obnovitvijo po katastrofi ne bodo nikoli postali glavni (za to obstaja prednostna nastavitev podrejenega v njihovi konfiguraciji). Zase v vsakem konkretnem primeru razmišljamo, ali je potrebno shraniti podatke na disk, in najpogosteje je odgovor "ne".

Zaključek

Na koncu upam, da sem lahko dal splošno predstavo o tem, kako deluje redis-cluster za tiste, ki zanj sploh še niso slišali, in opozoril na nekaj neočitnih točk za tiste, ki so ga uporabljali za dolgo časa.
Hvala za vaš čas in kot vedno so komentarji na to temo dobrodošli.

Vir: www.habr.com