Når man kommer til et produkt som har vært under utvikling i over et tiår, er det slett ikke overraskende å finne utdaterte teknologier i det. Men hva om du om seks måneder må støtte en last som er 10 ganger høyere, og kostnadene ved feil øker hundrevis av ganger? I dette tilfellet trenger du en kul Highload Engineer. Men på grunn av mangelen på en slik tjenestepike ble jeg betrodd å løse problemet. I den første delen av artikkelen vil jeg fortelle deg hvordan vi gikk fra Redis til Redis-klyngen, og i den andre delen vil jeg gi råd om hvordan du begynner å bruke klyngen og hva du bør være oppmerksom på under drift.

Teknologivalg

Er det virkelig så ille? separate Redis (frittstående redis) i 1 master- og N slavekonfigurasjon? Hvorfor kaller jeg det eldre teknologi?

Nei, Redis er ikke så ille ... Det er imidlertid noen mangler som ikke kan ignoreres.

• For det første støtter ikke Redis mekanismer for nødgjenoppretting etter at masteren krasjer. For å løse dette problemet brukte vi en konfigurasjon med automatisk overføring av VIP-er til en ny master, endring av rollen til en av slavene og bytte av de andre. Denne mekanismen fungerte, men den kunne ikke kalles en pålitelig løsning. For det første var det falske positiver, og for det andre var det en engangsoperasjon, og etter utløsningen var det nødvendig med manuelle handlinger for å spenne fjæren.

• For det andre førte det til problemet med sharding at man bare hadde én master. Det var nødvendig å opprette flere uavhengige klynger med "1 master og N slaver", deretter distribuere databasene manuelt mellom disse maskinene og håpe at en av databasene i morgen ikke vil svulme så mye at den må flyttes til en egen instans.

Hva er alternativene?

• Den dyreste og mest omfattende løsningen er Redis-Enterprise. Det er en boksløsning med full teknisk støtte. Til tross for at den ser ideell ut fra et teknisk synspunkt, passet den ikke oss av ideologiske årsaker.
• Redis-klynge. Støtte for master failover og sharding er tilgjengelig rett ut av esken. Grensesnittet er nesten det samme som den vanlige versjonen. Ser lovende ut, vi skal snakke om fallgruvene senere.
• Tarantool, Memcache, Aerospike og andre. Alle disse verktøyene gjør omtrent det samme. Men hver har sine egne ulemper. Vi bestemte oss for å ikke legge alle eggene i én kurv. Vi bruker Memcache og Tarantool til andre oppgaver, og når jeg ser fremover, vil jeg si at det i vår praksis var flere problemer med dem.

Spesifikasjoner for bruk

La oss ta en titt på hvilke oppgaver vi historisk sett har løst med Redis og hvilken funksjonalitet vi har brukt:

• Bufre før forespørsler til eksterne tjenester som 2GIS | Golang
  

  HENT SET MGET MSET "VELG DB"

• Hurtigbuffer før MYSQL | PHP
  

  FÅ INNSTILLING MGET MSET SKANN "NØKKEL ETTER MØNSTER" "VELG DB"

• Hovedlagring for tjenesten for arbeid med økter og koordinater for sjåfører | Golang
  

  HENT ANGI MG HENT MSETT "VELG DB" "LEGG TIL GEO-NØKKEL" "HENT GEO-NØKKEL" SKANNING

Som du ser, ingen høyere matematikk. Hva er vanskelighetsgraden da? La oss se på hver metode separat.

metode
beskrivelse
Funksjoner i Redis-klyngen
beslutning

GJØR DEG KLAR
Skrive-/lesenøkkel

MGET MSET
Skriv/les flere nøkler
Nøklene vil være på forskjellige noder. Ferdige biblioteker kan bare utføre fleroperasjoner innenfor én node.
Erstatt MGET med en pipeline av N GET-operasjoner

VELG DB
Velg databasen vi skal jobbe med
Støtter ikke flere databaser
Sett alt i én database. Legg til prefikser til nøkler.

SCAN
Gå gjennom alle nøklene i databasen
Siden vi har én database, er det for dyrt å gå gjennom alle nøklene i klyngen.
Behold invarianten innenfor én nøkkel og utfør HSCAN på denne nøkkelen. Eller avvis den helt.

GEO
Geokey-operasjoner
Geokey er ikke shardet

NØKKEL ETTER MØNSTER
Søk etter en nøkkel etter mønster
Siden vi har én database, vil vi søke etter alle nøklene i klyngen. For dyrt.
Avvis eller støtte invarianten, som i tilfellet med SCAN

Redis vs. Redis-klynge

Hva taper vi og hva vinner vi når vi bytter til en klynge?

• Ulemper: vi mister funksjonaliteten til flere databaser.
  • Hvis vi ønsker å lagre logisk urelaterte data i én klynge, må vi lage krykker i form av prefikser.
  • Vi mister alle operasjoner «på databasen», som SCAN, DBSIZE, CLEAR DB, osv.
  • Multioperasjoner har blitt betydelig vanskeligere å implementere fordi de kan kreve tilgang til flere noder.
• fordeler:
  • Feiltoleranse i form av master-failover.
  • Sharding på Redis-siden.
  • Overfør data mellom noder atomisk og uten nedetid.
  • Legge til og omfordele kapasitet og last uten nedetid.

Jeg vil konkludere med at hvis du ikke trenger å tilby et høyt nivå av feiltoleranse, er det ikke verdt å gå over til en klynge, siden dette kan være en ikke-triviell oppgave. Men hvis du i utgangspunktet velger mellom en separat versjon og en klynge, bør du velge en klynge, siden den ikke er verre og i tillegg vil lindre deg for noen hodepiner.

Forbereder seg på å flytte

La oss starte med kravene for flytting:

• Det skal være sømløst. En fullstendig stopp i servicen på 5 minutter er ikke akseptabelt for oss.
• Det bør være så trygt og gradvis som mulig. Vi ønsker å ha en viss kontroll over situasjonen. Vi ønsker ikke å drikke alt på en gang og bare be om tilbakerullingsknappen.
• Minimalt datatap under migrering. Vi forstår at det vil være svært vanskelig å migrere atomisk, så vi tillater noe desynkronisering mellom data i vanlig og klynget Redis.

Klyngevedlikehold

Før vi flytter, bør vi tenke på om vi kan støtte klyngen:

• Grafer. Vi bruker Prometheus og Grafana til å lage grafer for CPU-belastning, minnebruk, antall klienter, antall GET-, SET- og AUTH-operasjoner osv.
• Ekspertise. Tenk deg at du i morgen vil være ansvarlig for en enorm klynge. Hvis den går i stykker, er det ingen andre enn deg som kan fikse den. Hvis den begynner å sakke ned, vil alle løpe til deg. Hvis du trenger å legge til ressurser eller omfordele belastningen, vil de komme til deg igjen. For ikke å bli grå som 25-åring, er det lurt å forutse disse tilfellene og sjekke på forhånd hvordan teknologien vil oppføre seg under visse handlinger. Vi vil snakke mer detaljert om dette i avsnittet "Ekspertise".
• Overvåking og varsler. Når en klynge slutter å virke, vil du være den første til å vite om det. Her har vi begrenset oss til et varsel om at alle noder returnerer den samme informasjonen om klyngetilstanden (ja, det kan være forskjellig). Andre problemer er raskere å oppdage fra varslene til Redis-klienttjenestene.

kryssing

Hvordan vi skal bevege oss:

• Først og fremst må vi forberede et bibliotek for å jobbe med en klynge. Vi tok go-redis som grunnlag for Go-versjonen og modifiserte det litt for oss selv. Vi implementerte multimetoder via pipelines, og justerte også reglene for gjentatte forespørsler litt. Det var flere problemer med PHP-versjonen, men til slutt bestemte vi oss for php-redis. De implementerte nylig klyngestøtte, og etter vår mening ser det bra ut.
• Deretter må du distribuere selve klyngen. Dette gjøres bokstavelig talt i to kommandoer basert på konfigurasjonsfilen. Vi vil diskutere oppsettet mer detaljert nedenfor.
• For en gradvis migrering bruker vi tørrmodus. Siden vi har to versjoner av biblioteket med samme grensesnitt (én for den vanlige versjonen, den andre for klyngen), er det enkelt å lage en wrapper som fungerer med en separat versjon og samtidig dupliserer alle forespørsler til klyngen, sammenligner svar og skriver avvik til logger (i vårt tilfelle til NewRelic). Dermed, selv om klyngeversjonen skulle bryte sammen under utrullingen, vil ikke produksjonen vår bli påvirket.
• Etter å ha rullet ut klyngen i tørrmodus, kan vi rolig se på grafen over responsavvik. Hvis andelen feil sakte, men sikkert beveger seg mot en liten konstant, er alt i orden. Hvorfor er det avvik likevel? Fordi registreringen i en separat versjon skjer noe tidligere enn i klyngen, og på grunn av mikroforsinkelsen kan dataene avvike. Alt som gjenstår er å se på avviksloggene, og hvis alle kan forklares med registreringens ikke-atomisitet, kan vi gå videre.
• Nå kan vi bytte tørrmodus i motsatt retning. Vi vil skrive og lese fra klyngen, og duplisere i en separat versjon. Hvorfor? I løpet av den neste uken ønsker vi å observere klyngens drift. Hvis det plutselig viser seg at det er problemer ved toppbelastning, eller vi ikke har tatt hensyn til noe, har vi alltid en nødrollback til den gamle koden og oppdaterte data takket være tørrmodus.
• Alt som gjenstår er å deaktivere tørrmodus og avinstallere den separate versjonen.

Ekspertise

Først en kort oversikt over klyngestrukturen.

Først og fremst er Redis et nøkkel-verdi-lager. Vilkårlige strenger brukes som nøkler. Tall, strenger og hele strukturer kan brukes som verdier. Det finnes mange av de sistnevnte, men dette er ikke viktig for at vi skal forstå den generelle strukturen.
Det neste abstraksjonsnivået etter nøkler er spor (SLOTS). Hver nøkkel tilhører en av 16 383 spor. Innenfor hver spor kan det være et hvilket som helst antall nøkler. Dermed er alle nøkler delt inn i 16 383 disjunkte sett.

Deretter bør det være N masternoder i klyngen. Hver node kan betraktes som en separat Redis-instans som vet alt om de andre nodene i klyngen. Hver masternode inneholder et visst antall spor. Hvert spor tilhører bare én masternode. Alle spor må fordeles mellom noder. Hvis noen spor ikke er fordelt, vil nøklene som er lagret i dem være utilgjengelige. Det er fornuftig å kjøre hver masternode på en separat logisk eller fysisk maskin. Det er også verdt å huske at hver node bare kjører på én kjerne, og hvis du vil kjøre flere Redis-instanser på én logisk maskin, må du sørge for at de kjører på forskjellige kjerner (vi har ikke prøvd dette, men i teorien bør alt fungere). I hovedsak gir masternoder regelmessig sharding, og et større antall masternoder lar deg skalere skrive- og leseforespørsler.

Når alle nøklene er fordelt på tvers av spor, og sporene er fordelt på tvers av masternoder, kan et hvilket som helst antall slavenoder legges til hver masternode. Regelmessig replikering vil operere innenfor hver slik master-slave-kobling. Slaver er nødvendige for å skalere leseforespørsler og for nødbytte i tilfelle masterfeil.

La oss nå snakke om operasjoner som det ville være bedre å kunne utføre.

Vi vil få tilgang til systemet via Redis-CLI. Siden Redis ikke har et enkelt inngangspunkt, kan følgende operasjoner utføres på hvilken som helst av nodene. I hvert punkt vil jeg separat gjøre oppmerksom på muligheten for å utføre operasjonen under belastning.

• Det første og viktigste vi trenger er operasjonen for klyngenoder. Den returnerer klyngens tilstand, viser listen over noder, deres roller, plassfordeling osv. Ytterligere informasjon kan fås ved å bruke klyngeinfo og klyngeplasser.
• Det hadde vært fint å kunne legge til og fjerne noder. Det finnes cluster meet- og cluster forget-operasjoner for dette. Merk at cluster forget må brukes på HVER node, både mastere og replikaer. Og cluster meet trenger bare å kalles på én node. Denne forskjellen kan være forvirrende, så det er bedre å vite om den før du setter clusteren i produksjon. Å legge til en node gjøres trygt i kamp og påvirker ikke driften av clusteren på noen måte (noe som er logisk). Hvis du skal fjerne en node fra clusteren, bør du sørge for at det ikke er noen spor igjen på den (ellers risikerer du å miste tilgang til alle nøkler på denne noden). Ikke fjern en master som har slaver, ellers vil det bli en unødvendig avstemning om en ny master. Hvis det ikke er noen spor på nodene, er dette et lite problem, men hvorfor trenger vi ekstra valg hvis vi først kan fjerne slavene.
• Hvis du må tvinge master og slave til å bytte, vil cluster failover-kommandoen fungere. Når du kaller den i kamp, ​​må du være klar over at masteren vil være utilgjengelig under operasjonen. Vanligvis skjer byttet på under et sekund, men ikke atomært. Du kan forvente at noen forespørsler til masteren vil ende med en feil i løpet av denne tiden.
• Før du sletter en node fra en klynge, bør det ikke være noen spor igjen på den. Det er bedre å omfordele dem ved hjelp av cluster reshard-kommandoen. Sporene vil bli overført fra en master til en annen. Hele operasjonen kan ta flere minutter, avhengig av mengden data som overføres, men overføringsprosessen er trygg og påvirker ikke driften av klyngen på noen måte. Dermed kan alle data overføres fra en node til en annen direkte under belastning, og du trenger ikke å bekymre deg for tilgjengeligheten deres. Det er imidlertid noen finesser. For det første er dataoverføring forbundet med en viss belastning på mottaker- og avsendernodene. Hvis mottakernoden allerede er tungt belastet når det gjelder prosessor, bør du ikke laste den med å motta nye data. For det andre, så snart det ikke er noen spor igjen på avsendermasteren, vil alle slavene umiddelbart gå til masteren som disse sporene ble overført til. Og problemet er at alle disse slavene vil ønske å synkronisere dataene samtidig. Og du vil være heldig hvis det er delvis synkronisering, ikke full synkronisering. Ta hensyn til dette, og kombiner sporoverføringsoperasjoner med slavefrakobling/overføring. Eller håpe at du har en tilstrekkelig sikkerhetsmargin.
• Hva skal du gjøre hvis du oppdager at du har mistet spor et sted under overføringen? Forhåpentligvis vil ikke dette problemet påvirke deg, men hvis det gjør det, er det klyngereparasjonsoperasjonen. Den vil i beste fall fordele spor på tvers av noder i en tilfeldig rekkefølge. Jeg anbefaler å sjekke driften ved først å slette noden med distribuerte spor fra klyngen. Siden dataene i udistribuerte spor allerede er utilgjengelige, er det for sent å bekymre seg for problemer med tilgjengeligheten av disse sporene. Operasjonen vil igjen ikke påvirke distribuerte spor.
• En annen nyttig operasjon er monitor. Den lar deg se hele listen over forespørsler som går til noden i sanntid. Dessuten kan du grepe den og finne ut om det er nødvendig trafikk.

Det er også verdt å nevne master failover-prosedyren. Kort sagt, den finnes, og etter min mening fungerer den utmerket. Du bør imidlertid ikke tro at hvis du trekker ut støpselet til maskinen med masternoden, vil Redis umiddelbart bytte over, og klientene vil ikke merke tapet. Etter min erfaring tar byttet noen sekunder. I løpet av denne tiden vil noen data være utilgjengelige: masteren oppdages som utilgjengelig, nodene stemmer for en ny, slavene bytter over, og dataene synkroniseres. Den beste måten å sikre at ordningen fungerer på, er å utføre lokale øvelser. Start en klynge på den bærbare datamaskinen din, gi den en minimumsbelastning, simuler et fall (for eksempel ved å blokkere porter), og evaluer byttehastigheten. Etter min mening kan du bare være sikker på at teknologien fungerer etter å ha eksperimentert slik i en dag eller to. Vel, eller håpe at programvaren som halve Internett bruker sannsynligvis fungerer.

Konfigurasjon

Konfigurasjon er ofte det første du trenger for å begynne å jobbe med et verktøy. Og når alt fungerer, vil du ikke røre konfigurasjonen. Det krever litt innsats å tvinge deg selv til å gå tilbake til innstillingene og gå grundig gjennom dem. Jeg husker minst to alvorlige feil på grunn av manglende oppmerksomhet til konfigurasjonen. Vær spesielt oppmerksom på følgende punkter:

• timeout 0
  Tiden det tar før inaktive tilkoblinger lukkes (i sekunder). 0 - ikke lukket
  Ikke alle bibliotekene vi har klarte å lukke tilkoblinger riktig. Ved å deaktivere denne innstillingen risikerer vi å støte på grensen for antall klienter. Hvis et slikt problem derimot eksisterer, vil automatisk avslutning av tapte tilkoblinger maskere det, og vi legger kanskje ikke merke til det. I tillegg bør du ikke aktivere denne innstillingen når du bruker vedvarende tilkoblinger.
• Lagre xy og bare legge til ja
  Lagrer RDB-øyeblikksbilde.
  Vi vil diskutere RDB/AOF-problemene i detalj nedenfor.
• stopp-skriver-på-bgsave-feil nei og slave-serve-stale-data ja
  Hvis aktivert, vil masteren slutte å godta endringsforespørsler hvis RDB-snapshotet er ødelagt. Hvis forbindelsen til masteren brytes, kan slaven fortsette å svare på forespørsler (ja). Eller den vil slutte å svare (nei).
  Vi er ikke fornøyde med situasjonen der Redis forvandles til et gresskar.
• repl-ping-slave-periode 5
  Etter denne perioden vil vi begynne å bekymre oss for at masteren har brutt sammen, og at det er på tide å utføre en failover-prosedyre.
  Du må manuelt finne en balanse mellom falske positiver og å starte en failover. Etter vår erfaring er dette 5 sekunder.
• repl-backlog-størrelse 1024 MB og epl-backlog-ttl 0
  Vi kan lagre akkurat så mye data i bufferen for en mislykket replika. Hvis bufferen går tom, må vi synkronisere fullstendig.
  Erfaring viser at det er bedre å sette en høyere verdi. Det er mange grunner til at en replika kan begynne å ha dårlig tid. Hvis den har dårlig tid, er det mest sannsynlig at masteren din allerede sliter med å takle det, og full synkronisering vil være dråpen som får begeret til å renne over.
• maksklienter 10000
  Maksimalt antall samtidige klienter.
  Etter vår erfaring er det bedre å sette en høyere verdi. Redis håndterer 10K-tilkoblinger helt fint. Bare sørg for at du har nok sockets i systemet ditt.
• maksminnepolicy volatile-ttl
  Regelen som bruker for å slette nøkler når den tilgjengelige minnegrensen er nådd.
  Det som er viktig her er ikke selve regelen, men forståelsen av hvordan det vil skje. Redis kan roses for sin evne til å fungere normalt når minnegrensen er nådd.

RDB- og AOF-problemer

Selv om Redis lagrer all informasjon i RAM, finnes det også en mekanisme for å lagre data på disk. Mer presist, tre mekanismer:

• RDB-snapshot – et fullstendig snapshot av alle data. Settes med SAVE XY-konfigurasjonen og leses som «Lagre et fullstendig snapshot av alle data hvert X sekund hvis minst Y nøkler har endret seg.»
• Tilleggsfil – en liste over operasjoner i den rekkefølgen de utføres. Legger til nye innkommende operasjoner i filen hvert X sekund eller hver Y operasjon.
• RDB og AOF er en kombinasjon av de to foregående.

Alle metoder har sine fordeler og ulemper, jeg vil ikke liste opp alle, men bare rette oppmerksomheten mot det jeg anser som ikke-åpenbare punkter.

For å lagre et RDB-snapshot må du først kalle FORK. Hvis det er mye data, kan dette henge hele Redis i en periode på flere millisekunder til et sekund. I tillegg må systemet allokere minne til et slikt snapshot, noe som fører til behovet for å ha en dobbel reserve av RAM på den logiske maskinen: hvis 8 GB er allokert til Redis, bør 16 være tilgjengelig på den virtuelle maskinen som følger med.

For det andre er det problemer med delvis synkronisering. I AOF-modus, når man kobler til en slave på nytt, kan full synkronisering utføres i stedet for delvis. Jeg klarte ikke å finne ut hvorfor dette skjer. Men det er verdt å huske på.

Disse to punktene får oss allerede til å tenke på om vi virkelig trenger disse dataene på disken, hvis alt uansett dupliseres av slaver. Data kan bare gå tapt hvis alle slaver svikter, og dette er et problem på nivået "brann i DC". Som et kompromiss kan vi foreslå å lagre data bare på slaver, men i dette tilfellet må vi sørge for at disse slavene aldri blir mastere under nødgjenoppretting (for dette er det en slaveprioritetsinnstilling i konfigurasjonen deres). For oss selv tenker vi i hvert spesifikke tilfelle på om det er nødvendig å lagre data på disk, og oftest er svaret "nei".

Konklusjon

Avslutningsvis håper jeg at jeg har klart å gi en generell idé om hvordan redis-cluster fungerer til de som aldri har hørt om det, og også rettet oppmerksomheten mot noen ikke-åpenbare punkter for de som har brukt det lenge.
Takk for tiden din, og som alltid er alle kommentarer om dette emnet velkomne.

Kilde: www.habr.com