ProHoster > Blogg > Administrasjon > Om flyttingen fra Redis til Redis-cluster

Om flyttingen fra Redis til Redis-cluster

Om flyttingen fra Redis til Redis-cluster

NÄr man jobber med et produkt som har utviklet seg i over ti Är, er det ikke overraskende Ä finne utdaterte teknologier i det. Men hva skjer hvis du om seks mÄneder mÄ hÄndtere en belastning som er ti ganger hÞyere, og kostnaden ved nedetid Þker hundre ganger? I sÄ fall trenger du en dyktig Highload Engineer. Men siden vi ikke hadde en slik tilgjengelig, ble problemet overlatt til meg. I del én av artikkelen vil jeg fortelle om overgangen fra Redis til Redis-cluster, og i del to vil jeg gi rÄd om hvordan man begynner Ä bruke clusteren og hva man bÞr vÊre oppmerksom pÄ under driften.

Valg av teknologi

Er det sÄ ille med en egen Redis (standalone redis) i en konfigurasjon med 1 master og N slaver? Hvorfor kaller jeg det en utdatert teknologi?

Nei, Redis er ikke sÄ ille... Men det er noen ulemper som ikke kan ignoreres.

  • For det fĂžrste stĂžtter ikke Redis mekanismer for gjenoppretting etter feil pĂ„ masteren. For Ă„ lĂžse dette problemet brukte vi en konfigurasjon med automatisk overfĂžring av VIP-er til den nye masteren, endring av rollen til en av slavene og bytting av de andre. Denne mekanismen fungerte, men man kunne ikke kalle det en pĂ„litelig lĂžsning. For det fĂžrste oppsto det falske positive varsler, og for det andre var det engangsbruk, og etter en utlĂžsing var det behov for manuell hĂ„ndtering for Ă„ fĂ„ det tilbake til normal.

  • For det andre fĂžrte det Ă„ ha bare Ă©n master til problemer med sharding. Man mĂ„tte opprette flere uavhengige klynger med '1 master og N slaver', deretter manuelt fordele databasene pĂ„ disse maskinene og hĂ„pe at en av databasene ikke ble sĂ„ stor at den mĂ„tte flyttes til en egen instans.

Hva er alternativene?

  • Den dyreste og mest omfattende lĂžsningen er Redis-Enterprise. Dette er en pakkelĂžsning med full teknisk stĂžtte. Selv om det ser perfekt ut fra et teknisk synspunkt, passet det ikke for oss av ideologiske grunner.
  • Redis-cluster. Ut av boksen har det stĂžtte for automatisk failover av masteren og sharding. Grensesnittet er nesten identisk med den vanlige versjonen. Det ser lovende ut, og vi vil diskutere mulige fallgruver senere.
  • Tarantool, Memcache, Aerospike og andre. Alle disse verktĂžyene gjĂžr omtrent det samme. Men hver av dem har sine egne ulemper. Vi har bestemt oss for ikke Ă„ legge alle eggene i en kurv. Memcache og Tarantool bruker vi til andre oppgaver, og for Ă„ vĂŠre fĂžr vi kommer til poenget, skal jeg si at vi har hatt flere problemer med dem i vĂ„r praksis.

Spesifikasjonen for bruk

La oss se pÄ hvilke oppgaver vi historisk har lÞst med Redis og hvilken funksjonalitet vi har brukt:

  • Cache fĂžr forespĂžrselen til eksterne tjenester som 2GIS | Golang

    GET SET MGET MSET "SELECT DB"

  • Cache fĂžr MYSQL | PHP

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

  • Hovedlagring for tjenesten som arbeider med Ăžkter og koordinater til sjĂ„fĂžrer | Golang

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

Som du ser, ingen hÞyere matematikk. Hva er sÄ kompleksiteten? La oss se nÊrmere pÄ hver metode.

Metode
Description
Egenskaper ved Redis-kluster
Solution

GET SET
Skrive/lese nĂžkkel

MGET MSET
Skrive/lese flere nĂžkler
NÞklene vil ligge pÄ forskjellige noder. Ferdige biblioteker kan kun gjÞre Multi-operasjoner innenfor en node.
Erstatt MGET med en pipeline av N GET-operasjoner

SELECT DB
Velge databasen vi skal bruke
StĂžtter ikke flere databaser
Oppbevar alt i Ă©n database. Legg til prefikser til nĂžklene

SCAN
GĂ„ gjennom alle nĂžklene i databasen
Siden vi har én database, er det for kostbart Ä gÄ gjennom alle nÞklene i klusteret.
Opprettholde invariant innenfor en nÞkkel og gjÞre HSCAN pÄ denne nÞkkelen. Eller avstÄ helt.

GEO
Operasjoner med geonĂžkkel
GeonĂžkkelen deles ikke opp.

KEY BY PATTERN
SÞke etter nÞkkel basert pÄ mÞnster
Siden vi har Ă©n database, skal vi sĂžke gjennom alle nĂžklene i klusteret. For kostbart.
AvstÄ eller opprettholde invariant, som i tilfellet med SCAN.

Redis vs Redis-kluster

Hva mister vi og hva fÄr vi ved Ä gÄ over til kluster?

  • Ulemper: vi mister funksjonaliteten til flere databaser.
    • Hvis vi vil lagre logisk usammenhengende data i ett kluster, mĂ„ vi lage lĂžsninger med prefikser.
    • Vi mister alle operasjoner "per database", som SCAN, DBSIZE, CLEAR DB osv.
    • Multi-operasjoner har blitt betydelig vanskeligere Ă„ implementere, fordi det kan kreve tilgang til flere noder.
  • Fordeler:
    • Feiltoleranse i form av nĂždskifting av hovedserver.
    • Shardingside pĂ„ Redis.
    • OverfĂžring av data mellom noder atomisk og uten nedetid.
    • Legge til og omfordele kapasitet og belastninger uten nedetid.

Jeg vil konkludere med at si at hvis du ikke trenger Ä sikre et hÞyt nivÄ av tilgjengelighet, sÄ er det ikke verdt Ä flytte til en klynge, da dette kan vÊre en krevende oppgave. Men hvis man fÞrst velger mellom en separat versjon og en klynge, bÞr man velge klyngen, da den ikke er dÄrligere, og i tillegg vil den ta bort noe av bekymringen.

Forberedelse til flytting

Vi begynner med kravene til flyttingen:

  • Den mĂ„ vĂŠre sĂžmlĂžs. En total stopp av tjenesten i 5 minutter er uakseptabelt for oss.
  • Den bĂžr vĂŠre sĂ„ sikker og gradvis som mulig. Vi Ăžnsker Ă„ ha kontroll over situasjonen. Å kaste alt pĂ„ en gang og stole pĂ„ nedgraderingsknappen er ikke noe vi Ăžnsker.
  • Minimale datatap under flyttingen. Vi forstĂ„r at det vil vĂŠre svĂŠrt vanskelig Ă„ flytte atomĂŠrt, sĂ„ vi aksepterer en viss desynkronisering mellom dataene i vanlig og klynge Redis.

Vedlikehold av klyngen

FĂžr selve flyttingen, bĂžr vi vurdere om vi kan vedlikeholde klyngen:

  • Grafikk. Vi bruker Prometheus og Grafana for grafikk over CPU-bruk, minnebruk, antall klienter, antall GET, SET, AUTH-operasjoner, osv.
  • Ekspertise. Tenk deg at i morgen vil du ha ansvaret for en enorm klynge. Hvis den krasjer, sĂ„ er det ingen andre enn deg som kan fikse den. Hvis den begynner Ă„ fungere sakte - vil alle komme til deg. Hvis ressurser mĂ„ legges til eller belastning mĂ„ omfordeles - igjen til deg. For Ă„ unngĂ„ Ă„ bli grĂ„hĂ„ret i en alder av 25, bĂžr man forutse disse situasjonene og teste pĂ„ forhĂ„nd hvordan teknologien vil oppfĂžre seg under ulike handlinger. Vi vil diskutere dette nĂŠrmere i delen om 'Ekspertise'.
  • OvervĂ„kning og varsler. NĂ„r klyngen krasjer, Ăžnsker vi Ă„ bli informert fĂžrst. Her har vi begrenset oss til varsler om at alle noder returnerer den samme informasjonen om klyngens tilstand (ja, det kan vĂŠre annerledes). Andre problemer blir raskere oppdaget gjennom varsler fra Redis-klienttjenester.

Flytting

Hvordan vi skal flytte:

  • FĂžrst mĂ„ vi forberede biblioteket for Ă„ arbeide med klyngen. Som grunnlag for versjonen i Go har vi tatt go-redis og tilpasset det litt. Vi implementerte Multi-metoder gjennom pipelines og justerte reglene for gjentakelse av forespĂžrslene. Med PHP-versjonen oppsto det flere problemer, men til slutt har vi landet pĂ„ php-redis. Nylig har de introdusert stĂžtte for klynger, og etter vĂ„rt syn ser det bra ut.
  • Deretter mĂ„ vi sette opp selve klyngen. Dette gjĂžres bokstavelig talt med to kommandoer basert pĂ„ konfigurasjonsfilen. Vi vil diskutere innstillingene mer detaljert nedenfor.
  • For en gradvis overgang bruker vi dry-mode. Siden vi har to versjoner av biblioteket med identisk grensesnitt (en for vanlig versjon og en for klynge), er det enkelt Ă„ lage en wrapper som jobber med den separate versjonen og samtidig dupliserer alle forespĂžrslene til klyngen, sammenligner svarene og skriver avvikene i loggene (i vĂ„rt tilfelle i NewRelic). Dermed, selv om klyngeversjonen bryter ved utrullingen, vil produksjonen vĂ„r ikke bli berĂžrt.
  • NĂ„r vi lanserer klyngen i dry-modus, kan vi rolig se pĂ„ diagrammet over avvik i svarene. Hvis andelen feil sakte men sikkert beveger seg mot en liten konstant, betyr det at alt er i orden. Hvorfor er det fortsatt avvik? Fordi opptak i den separate versjonen skjer litt tidligere enn i klyngen, og pĂ„ grunn av mikrologgene kan dataene avvike. Det gjenstĂ„r bare Ă„ se pĂ„ avviksloggene, og hvis alle er forklarlige med hensyn til ikke-atomaritet i opptakene, kan vi gĂ„ videre.
  • NĂ„ kan vi skifte dry-mode tilbake. Vi vil skrive og lese fra klyngen, samtidig som vi dupliserer til den separate versjonen. Hvorfor? I lĂžpet av den neste uken Ăžnsker vi Ă„ observere hvordan klyngen fungerer. Hvis det viser seg at det er problemer under hĂžy belastning, eller vi har oversett noe, har vi alltid en nĂždprosess for Ă„ gĂ„ tilbake til gammel kode og aktuelle data takket vĂŠre dry-mode.
  • Det gjenstĂ„r bare Ă„ deaktivere dry-mode og demontere den separate versjonen.

Ekspertise

FĂžrst en kort oversikt over hvordan klyngen er strukturert.

FÞrst og fremst er Redis et key-value lagringssystem. VilkÄrlige strenger brukes som nÞkler. Verdiene kan vÊre tall, strenger og komplekse strukturer. Det finnes et stort antall av de siste, men for Ä forstÄ den generelle strukturen er dette ikke viktig.
Det neste nivÄet av abstraksjon etter nÞklene er slottene (SLOTS). Hver nÞkkel tilhÞrer en av 16 383 slots. Inne i hver slot kan det vÊre sÄ mange nÞkler som Þnskes. Dermed deles alle nÞkler opp i 16 383 ikke-overlappende mengder.
Om flyttingen fra Redis til Redis-cluster

Videre mÄ det vÊre N master-noder i klyngen. Hver node kan betraktes som en separat Redis-instans som vet alt om de andre nodene inne i klyngen. Hver master-node inneholder et visst antall slots. Hver slot tilhÞrer bare én master-node. Alle slots mÄ fordeles mellom nodene. Hvis noen slots ikke er fordelt, vil nÞklene som lagres i dem vÊre utilgjengelige. Hver master-node gir mening Ä kjÞre pÄ en separat logisk eller fysisk maskin. Det er ogsÄ viktig Ä huske at hver node kun kjÞrer pÄ én kjerne, og hvis du Þnsker Ä kjÞre flere Redis-instanserer pÄ en logisk maskin, mÄ du sÞrge for at de kjÞrer pÄ forskjellige kjerner (vi har ikke prÞvd dette, men i teorien skal det fungere). I hovedsak gir master-nodene vanlig sharding, og flere master-noder gjÞr det mulig Ä skalere bÄde skrive- og leseforespÞrslene.

Etter at alle nÞkler er fordelt pÄ slots, og slots er fordelt pÄ master-nodene, kan det legges til et vilkÄrlig antall slave-noder til hver master-node. Inne i hver «master-slave» kobling vil vanlig replikering fungere. Slaver er nÞdvendige for Ä skalere leseforespÞrslene og for failover i tilfelle masteren svikter.
Om flyttingen fra Redis til Redis-cluster

La oss nÄ snakke om operasjonene vi helst bÞr kunne utfÞre.

Vi vil kontakte systemet via Redis-CLI. Siden Redis ikke har et enkelt tilgangspunkt, kan de fÞlgende operasjonene utfÞres pÄ hvilken som helst av nodene. Jeg vil spesifisere hver enkelt operasjon med tanke pÄ muligheten for Ä utfÞre den under belastning.

  • Det fĂžrste og viktigste vi trenger: operasjonen cluster nodes. Den returnerer tilstanden til klyngen, viser listen over noder, deres roller, fordelingen av slots osv. Ytterligere informasjon kan fĂ„s ved hjelp av cluster info og cluster slots.
  • Det ville vĂŠre bra Ă„ kunne legge til og fjerne noder. For dette finnes operasjonene cluster meet og cluster forget. VĂŠr oppmerksom pĂ„ at cluster forget mĂ„ brukes pĂ„ HVER node, bĂ„de pĂ„ mastere og replikaer. Og cluster meet trenger kun kalles pĂ„ Ă©n node. Denne forskjellen kan vĂŠre forvirrende, sĂ„ det er best Ă„ bli klar over den fĂžr man setter klusteret i drift. Å legge til en node gjĂžres trygt i drift og pĂ„virker ikke arbeidet til klusteret (noe som er logisk). Hvis du imidlertid planlegger Ă„ fjerne en node fra klusteret, bĂžr du forsikre deg om at det ikke er noen slots igjen (ellers risikerer du Ă„ miste tilgang til alle nĂžklene pĂ„ denne noden). Fjern heller ikke masteren hvis den har slaver, ellers vil det bli unĂždvendig avstemning for en ny master. Hvis det ikke er noen slots igjen pĂ„ nodene, er det et lite problem, men hvorfor velge det unĂždvendige, hvis man kan fjerne slavene fĂžrst.
  • Hvis du mĂ„ tvinge bytte mellom master og slave, kan kommandoen cluster failover brukes. NĂ„r du kaller denne i drift, mĂ„ du forstĂ„ at masteren vil vĂŠre utilgjengelig under operasjonen. Vanligvis skjer byttet pĂ„ mindre enn et sekund, men det er ikke atomisk. Du kan forvente at deler av forespĂžrslene til masteren vil feile i lĂžpet av denne tiden.
  • FĂžr du fjerner en node fra klyngen, bĂžr det ikke vĂŠre noen slots igjen pĂ„ den. Det er best Ă„ omfordele dem med kommandoen cluster reshard. Slots vil bli overfĂžrt fra en master til en annen. Hele operasjonen kan ta flere minutter, avhengig av mengden data som overfĂžres, men prosessen er trygg og pĂ„virker ikke driften av klyngen. Dermed kan alle data overfĂžres fra en node til en annen selv under belastning, uten Ă„ bekymre seg for tilgjengeligheten. Imidlertid er det visse nyanser. For det fĂžrste er dataoverfĂžring forbundet med en viss belastning pĂ„ bĂ„de mottaker- og avsender-noden. Hvis mottakeren allerede er sterkt belastet pĂ„ prosessoren, bĂžr du ikke belaste den med mottak av nye data. For det andre, sĂ„ snart det ikke er noen slots igjen pĂ„ master-avsenderen, vil alle dens slaves umiddelbart gĂ„ over til den masteren hvor disse slotsene ble flyttet. Problemet er at alle disse slave-nodene vil Ăžnske Ă„ synkronisere dataene samtidig. Og du er heldig hvis dette er delvis, og ikke full synkronisering. Ta hensyn til dette, og kombiner operasjoner med flytting av slots med Ă„ frakoble/flytte slaves. Eller hĂ„p at du har tilstrekkelig kapasitet.
  • Hva gjĂžr du hvis du oppdager at du har mistet slots under overfĂžringen? Jeg hĂ„per dette problemet ikke vil berĂžre deg, men hvis det skjer, finnes det en operasjon kalt cluster fix. Den vil tilfeldigvis fordele slotsene pĂ„ nodene. Jeg anbefaler Ă„ sjekke hvordan den fungerer ved Ă„ fjerne en node med fordelte slots fra klyngen fĂžrst. Siden data i ufordelte slots allerede er utilgjengelige, er det for sent Ă„ bekymre seg for tilgangen til disse slotsene. PĂ„ sin side vil operasjonen ikke pĂ„virke de fordelte slotsene.
  • En annen nyttig operasjon er monitor. Den lar deg se hele listen over forespĂžrslene som kommer til noden i sanntid. Dessuten kan du bruke grep pĂ„ den for Ă„ finne ut om det er Ăžnsket trafikk.

Det er ogsÄ viktig Ä nevne prosedyren for nÞdovergang til master. Kort sagt er det en prosedyre, og etter min mening fungerer den utmerket. Men man skal ikke tro at hvis man trekker ut stikkontakten fra maskinen med master-noden, vil Redis umiddelbart overta og kundene ikke vil merke noen avbrudd. Etter min erfaring tar det flere sekunder fÞr overgangen skjer. I lÞpet av denne tiden vil deler av dataene vÊre utilgjengelige: masterens utilgjengelighet oppdages, nodene stemmer over ny, slaver byttes over, og data synkroniseres. Den beste mÄten Ä sikre seg om at systemet fungerer, er Ä gjennomfÞre lokale Þvelser. Sett opp en klynge pÄ din bÊrbare PC, gi minimal last, simuler et nedbrudd (for eksempel ved Ä blokkere porter), og evaluer overgangen. Etter min mening kan man fÞrst vÊre sikker pÄ teknologiens funksjonalitet etter Ä ha lekt med det i en dag eller to. Eller hÄpe pÄ at programvaren som brukes av halve internett, fungerer som den skal.

Konfigurasjon

Som regel er konfigurasjonen det fÞrste man trenger for Ä begynne Ä bruke verktÞyet. Og nÄr alt er oppe og gÄr, Þnsker man ikke Ä rÞre konfigurasjonen. Det kreves spesifikke anstrengelser for Ä tvinge seg selv tilbake til innstillingene og gÄ dem grundig igjennom. Etter min erfaring har vi hatt minst to alvorlige feil pÄ grunn av uoppmerksomhet mot konfigurasjonen. VÊr spesielt oppmerksom pÄ fÞlgende punkter:

  • timeout 0
    Tiden det tar fþr inaktive forbindelser lukkes (i sekunder). 0 — lukkes ikke
    Ikke alle vÄre biblioteker var i stand til Ä lukke forbindelser riktig. Ved Ä deaktivere denne innstillingen risikerer vi Ä nÄ grensen for antall klienter. PÄ den annen side, hvis et slikt problem eksisterer, vil automatisk brudd av tapte forbindelser maskere det, og vi kan gÄ glipp av det. Videre bÞr man ikke aktivere denne innstillingen nÄr man bruker persist-forbindelser.
  • Save x y & appendonly yes
    Lagring av RDB-snapshot.
    Problemer knyttet til RDB/AOF vil vi diskutere i detalj nedenfor.
  • stop-writes-on-bgsave-error no & slave-serve-stale-data yes
    Hvis aktivert, vil master slutte Ä ta imot endringsforespÞrsel ved et RDB-snapshot-feil. Hvis forbindelsen til master er tapt, kan slaven fortsette Ä svare pÄ forespÞrsel (yes). Eller slutte Ä svare (no)
    Vi er ikke komfortable med situasjonen der Redis blir til en gresskar.
  • repl-ping-slave-period 5
    I lĂžpet av denne tidsperioden vil vi begynne Ă„ bekymre oss for at masteren er brutt sammen og at vi bĂžr utfĂžre en failover-prosedyre.
    Vi mÄ manuelt finne balansen mellom falske alarmer og utlÞsing av failover. I vÄr erfaring tar dette 5 sekunder.
  • repl-backlog-size 1024mb & epl-backlog-ttl 0
    Slik mengde data kan vi lagre i bufferet for en avvikende replika. Hvis bufferet fylles opp, mÄ vi synkronisere helt.
    Erfaringen tilsier at det er bedre Ä sette verdien litt hÞyere. Det finnes flere grunner til at en replika kan begynne Ä henge etter. Hvis den henger etter, er det sannsynlig at masteren din allerede sliter, og full synkronisering vil bli drÄpen som fÄr begeret til Ä renne over.
  • maxclients 10000
    Det maksimale antallet samtidige klienter.
    IfÞlge vÄr erfaring er det bedre Ä sette verdien hÞyere. Redis klarer seg fint med 10 000 tilkoblinger. Bare sÞrg for at systemet har nok sokler.
  • maxmemory-policy volatile-ttl
    Reglene for hvordan nÞkler blir fjernet nÄr grensen for tilgjengelig minne nÄs.
    Her er det viktigere ikke selve regelen, men forstÄelsen av hvordan dette vil skje. Redis kan roses for dets evne til Ä fungere godt nÄr minnegrensen nÄs.

Problemer med RDB og AOF

Selv om Redis lagrer all informasjon i RAM, finnes det ogsÄ mekanismer for Ä lagre data pÄ disk. NÊrmere bestemt finnes det tre mekanismer:

  • RDB-snapshot — et fullt snapshot av all data. Settes opp med konfigurasjonen SAVE X Y og leses som "Lagre et fullstendig snapshot av alle data hvert X sekunder, hvis minst Y nĂžkler har blitt endret."
  • Append-only file — en liste over operasjoner i rekkefĂžlge etter utfĂžrelse. Legger til nye ankomne operasjoner til filen hvert X sekunder eller hver Y operasjoner.
  • RDB og AOF — en kombinasjon av de to forrige.

Alle metodene har sine fordeler og ulemper, jeg vil ikke liste dem alle, men vil bare pÄpeke det som, etter min mening, ikke er sÄ Äpenbare punkter.

For det fÞrste, for Ä lagre en RDB-snapshot kreves det Ä kalle FORK. Hvis det er mye data, kan dette hengslet hele Redis i en periode fra noen millisekunder til ett 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 tildelt Redis, mÄ det vÊre tilgjengelig 16 GB pÄ den virtuelle maskinen.

For det andre er det problemer med delvis synkronisering. I AOF-modus kan det, ved gjenoppretting av slave, utfÞres en fullstendig synkronisering i stedet for delvis. Hvorfor dette skjer, klarte jeg ikke Ä forstÄ. Men det er verdt Ä huske pÄ.

Disse to punktene fÄr oss allerede til Ä tenke pÄ om vi virkelig trenger disse dataene pÄ disk, nÄr de allerede er duplisert av slavene. Data kan bare gÄ tapt dersom alle slavene svikter, og det er et problem av "brann i datasenteret"-nivÄ. Som et kompromiss kan man foreslÄ Ä lagre data kun pÄ slavene, men i sÄ fall mÄ man sÞrge for at disse slavene aldri blir master ved nÞdgjenoppretting (det finnes en innstilling for prioritering av slaver i deres konfigurasjon). I hvert enkelt tilfelle vurderer vi om vi skal lagre data pÄ disk, og vi svarer oftest "nei".

Konklusjon

Avslutningsvis hÄper jeg jeg har gitt en generell oversikt over hvordan redis-cluster fungerer til de som aldri har hÞrt om det, og ogsÄ pÄpekt noen ikke-Äpenbare punkter for de som allerede har brukt det en stund.
Takk for tiden din, og som alltid er kommentarer om emnet velkomne.

Kilde: habr.com

KjĂžp pĂ„litelig hosting for nettsteder med DDoS-beskyttelse, VPS VDS-servere đŸ”„ KjĂžp pĂ„litelig hosting for nettsteder med DDoS-beskyttelse, VPS VDS-servere | ProHoster