Redis-databaser kan lagre små, kortvarige og komplekse gjenstander som vedvarer i flere måneder. Uansett kompleksitet og størrelse på objektene, er kontinuerlig tilgjengelighet av disse dataene et must å tilby sømløs back-end-tjeneste til klienten.Vanligvis er den frittstående Redis -installasjonen enkel å konfigurere og bruke. Men det er ikke det beste alternativet å bruke i et miljø der nodefeil kan oppstå. Data holdbarhet kan beholdes med Redis Apply-bare fil (AOF) -funksjon i Redis, men er ikke den ideelle løsningen for høy tilgjengelighet. Tilsvarende kan Redis RDB-filene brukes som et sikkerhetskopieringsalternativ som er en poeng i tid-representasjon av dataene. Begge disse alternativene løser ikke problemet med plutselige redis -nodefeil.Så Redis introduserte flere innebygde funksjoner for å støtte den høye tilgjengeligheten av Redis-databaser omtalt i følgende avsnitt.

Database replikering

Database replikering er den grunnleggende teknikken bak å lage en databasesystem feiltoleranse og kontinuerlig tilgjengelig. Replikering kopierer data fra Master Database (Primary Database) til en eller flere slavedatabaser (replikker) som sikrer at dataene er tilgjengelige når som helst hvis en masternode mislykkes. Denne prosessen er kombinert med en automatisk failover -prosess som fremmer en ny mester fra de tilgjengelige replika -nodene når masternoden mislykkes.

Innebygd redis replikasjon

Redis begynte å støtte replikering fra de tidligste versjonene og forbedret enormt. Den frittstående versjonen støtter grunnleggende replikering med slaveof -kommandoen ved å konvertere en eksisterende node til en slave av den primære databaseknuten. Redis Sentinel -funksjonen muliggjør også replikering med en mer avansert failover -funksjon. I tillegg støtter Redis-klyngen et rikt sett med funksjoner med høy tilgjengelighet for mer distribuerte og store databasesystemer.

Grunnleggende redis replikasjon med slaveof -kommandoen

En av de grunnleggende måtene å oppnå Redis -replikasjonen på er ved å bruke slave av kommandoen.

Det er et skritt unna å lage en Redis -forekomst til en slaveknute. Følgende linje skal legges til konfigurasjonsfilen til den aktuelle forekomsten:

slaveof

Bruk sak

Følgende eksempel demonstrerer et scenario der en gitt Redis -forekomst er konfigurert til å være en slaveknute av en masternode som kjører i 127.0.0.1 adresse ved 7000 havn.

Med denne konfigurasjonen vil masterdatabasen kopiere alle dataene til slaveknuten som sikrer at slaven er en eksakt kopi av den primære databaseknuten.

Når masternoden er i gang på 127.0.0.1 og port 7000, la oss starte den andre forekomsten hvis konfigurasjonsfil inneholder slaveofkonfigurasjonen. Den nye forekomsten vil kjøre på port 7001.

Den nye forekomsten startes vellykket og synkronisert med masterløp på 127.0.0.1 (port 7000).

Hvis du skriver noen data til hovednoden, kan de leses fra slaven som følger. Det betyr at master og replika har blitt synkronisert ordentlig.

Å skrive data til hovednoden kjører på Port 7000 som følger.

Lese data fra slaveknuten kjører på Port 7001 som vist i følgende:

Med dette oppsettet, når Redis Master mislykkes, har vi allerede en eksakt kopi av den primære databasen som kjører på Port 7001. Tilsvarende kan du konfigurere flere slaver for en gitt masternode. Den eneste ulempen i dette oppsettet er at du må ta vare på failover -prosessen manuelt.

Fordeler

• Enkel og mindre tidkrevende å sette opp.
• Dette oppsettet vil fungere så lenge en enkelt masternode er tilgjengelig og selv uten en enkelt slaveknute.
• Mulig å automatisere med konfigurasjonsstyringsverktøy.

Ulemper

• Master failover -prosessen er ikke automatisert.
• Siden lesene er asynkrone, kan foreldede lesninger oppstå.
• Master og slaveutnyttelse er ikke lik på grunn av at shardingen ikke støttes.

Høy tilgjengelighet med Redis Sentinel

Redis Sentinel ble introdusert for å håndtere ulempene med den forrige løsningen. Redis Sentinel er et distribuert system som fungerer som en avansert løsning med høy tilgjengelighet for Redis sammen med andre funksjoner som varslingsleverandør, overvåkingsverktøy og konfigurasjonsleverandør for klienter.

Sentinel er i stand til å fremme en slave til en mesternode automatisk uten menneskelig inngripen. Master failover -prosessen starter hvis det spesifiserte maksimale antall sentinelnoder (quorum) er enig i at masternoden ikke er tilgjengelig. Så tilgjengeligheten til Sentinel -nodene er viktig. Det anbefales imidlertid å bruke en egen Sentinel -klynge for å kjøre Sentinel -noder separat fra mesternoder. Med dette oppsettet snakker Redis -klienter først med Sentinel -noden og ber om informasjon om den for øyeblikket Running Master Node. Da vil bare klientene samarbeide med den nåværende mesteren.

Det er mulig å starte en Redis -server i Sentinel -modus som vist i følgende kommando:

Redis-server --vakt

Som vist i følgende utgang, er serveren startet i Sentinel -modus.

Videre kan Redis Sentinels også samles med Redis -serverne.

Fordeler

• Automatisk failover -funksjon
• Enkel og mindre tidkrevende for å konfigurere

Ulemper

• Sentinel trenger en egen klynge hvis ikke samlet seg med Redis Server -nodene
• Master- og slaveknuteutnyttelse er ubalansert på grunn av intet sharding -alternativ tilgjengelig
• Redis Sentinel er et distribuert system og innebærer en betydelig mengde vedlikehold

Høy tilgjengelighet med Redis -klynging

Med de siste Redis -utgivelsene ble en klyngekomponent lagt til Redis Stack. Det støtter:

• Sharding
• Replikering
• Høy tilgjengelighet

Så Redis -klyngen tar for seg flere aspekter som mangler i tidligere løsninger. Det ble enormt gunstig for store bedrifter som genererer og lagrer en stor mengde data. Fordi Sharding distribuerer dataene dine blant flere mestere, har hver en delmengde av hele nøkkelplassen. Det gir deg et massivt ytelsesøkning.

Samtidig er replikering tilgjengelig i Redis -klynger der du kan konfigurere flere slaveknuter for en gitt master. Vanligvis bør en klyngeknute inneholde nøyaktig en Redis Server -forekomst. Men det er mulig å konfigurere kryssreplikasjon ved å distribuere flere forekomster i en enkelt node.

I tillegg er det automatiske failover -alternativet levert av Redis -klyngene der slaveknuten vil promotere for en mester. I et klyngeoppsett er ikke quorumet pålagt å markedsføre en ny masternode eller sharding for å jobbe. Masternoden Quorum er bare nødvendig for at hele klyngen skal løpe.

Så Redis Cluster-løsningen kan sees på som en alt-i-ett-løsning for de som leter etter sharding, replikering og høy tilgjengelighet i applikasjonene sine.

Fordeler

• Støtter sharding som gir et ytelsesøkning når du spør Redis Data Store.
• Gir automatisk failover -løsning
• Master-replica-støtte

Ulemper

• Å opprettholde en klynge kan være en betydelig mengde arbeid
• Mangel på bibliotekstøtte

Konklusjon

Redis støtter høy tilgjengelighet med frittstående Redis, Redis Sentinel-modell og innebygd klyngekomponent. Alle tre løsningene har sine fordeler og ulemper som diskutert ovenfor. Totalt sett er Redis Sentinel alternativet hvis du bare leter etter høy tilgjengelighet og ikke bryr deg om ytelse. Men hvis du leter etter en balanse mellom ytelse og høy tilgjengelighet med kryssreplikasjon, er uten tvil Redis-klyngen den beste blant alle tre.