Redis Sentinel-Høy Tilgjengelighet: Alt DU trenger Å vite Fra DEV TIL PROD: Komplett Guide

hva betyr begrepet ‘Redis’ egentlig betyr?

Det betyr Ekstern Ordbok Server.

Ok! Det er mange Forskjellige Redis-artikler der ute, men jeg ønsket å dele min erfaring som utvikler Med Redis ved å lage En «alt i en riktig artikkel» som dekker de mest essensielle og viktige tingene som trengs og er nyttig for en utvikler eller en devops-ingeniør for å bygge En Svært Tilgjengelig Redis-klynge med Sentinel.

Så la oss komme i gang…

Redis, som er en åpen kildekode i minnet datastruktur butikken, er et svært populært utvalg blant utviklere som brukes for caching formål, som en melding megler og også hovedsakelig brukt som En NoSQL Nøkkel-Verdi database for ulike brukstilfeller.

i dette innlegget skal jeg spesifikt diskutere Og demo Om Redis sammen Med Master / Slave Replikering, Høy tilgjengelighet (Redis Sentinel), Automatisk Failover , noen produksjonsnivå optimalisering tips og overvåking aspekter. I tillegg, sammen med disse emnene, nevner jeg problemene og feilene jeg møtte under implementeringen Av Redis Sentinel med Ubuntu. Følgende viser OS-versjonen og Redis versjon detaljer.

OS version: Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-119-generic x86_64)
Redis Version: 4.0.9

I Tillegg vil Jeg fremheve At redis-dokumentasjonen er veldig informativ, og det er ‘the go to place’ hvis du trenger ytterligere avklaring På Redis.

Fortsett Til redis basics; Redis er en minnedatabase, noe som betyr At Redis kjører PÅ RAM. Du må også vite At Redis støtter flere datastrukturer som strenger, hashes, lister, sett, sorterte sett med utvalgsspørringer, bitmaps. Videre støtter den også atomoperasjoner som å legge til en streng, øke verdien i en hash, skyve et element til en liste og etc.

Vel, La oss få ting i gang Med Redis Høy Tilgjengelighet.

Redis sentinel Er Løsningen Med høy tilgjengelighet Som Redis tilbyr. I tilfelle feil I Redis-klyngen din, Oppdager Sentinel automatisk feilpunktet og bringer klyngen tilbake til stabil modus uten menneskelig inngrep.

hva skjer egentlig inne I Redis Sentinel ?

Sentinel kontrollerer alltid MASTER-og SLAVEFOREKOMSTENE I redis-klyngen, og kontrollerer om DE fungerer som forventet. Hvis sentinel oppdager en feil I hovednoden i en gitt klynge, Vil Sentinel starte en failover-prosess. Som et resultat, Sentinel vil plukke EN SLAVE forekomst og fremme DET Å MESTRE. Til slutt blir de andre gjenværende SLAVEFOREKOMSTENE automatisk omkonfigurert for å bruke den nye HOVEDFOREKOMSTEN.

Sentinel fungerer som en konfigurasjonsleverandør eller en autorisasjonskilde for tjenesteoppdagelse for klienter.

Hva betyr det ? Enkelt, programklienter koble Til Sentinels og Sentinels gi den nyeste Redis MASTER adresse til dem.

Videre Er Sentinel et robust distribuert system, der flere sentinels må være enige om at en gitt mester ikke lenger er tilgjengelig. Da starter bare failover-prosessen a velge en ny MASTER node. Denne sentinel avtalen er gjort i henhold til quorum verdi.

Hva er quorum ?

quorumsverdien er antall Sentinels som må være enige om at mesteren ikke kan nås. Men quorumet brukes bare til å oppdage feilen. For å faktisk utføre en failover, må En Av Sentinels velges leder for failover og være autorisert til å fortsette. Dette skjer bare med stemme fra flertallet Av Sentinel-prosessene.

La oss få våre hender skitne Med Redis Sentinel.

vi holder oss til det grunnleggende oppsettet med 3 serverforekomster.

vennligst se diagrammet ovenfor som illustrerer 3 server eksempel grunnleggende oppsett. Først og fremst sørg For At Ubuntu-forekomstene dine er oppdatert med relevante byggeavhengigheter. Noen ganger kan du trenge jemalloc også. Følgende viser trinnene for å installere Redis på serverforekomster.

sudo apt-get update 
sudo apt-get install build-essential tcl
sudo apt-get install libjemalloc-dev (Optional)curl -O http://download.redis.io/redis-stable.tar.gz
tar xzvf redis-stable.tar.gz
cd redis-stable
make
make test
sudo make install

Nå i redis-katalogen bør du kunne se begge redis.conf og sentinel.conf konfigurasjonsfiler.

Før Vi kjører Redis, la oss gjøre noen nødvendige grunnleggende konfigurasjoner for å opp og kjøre En Redis-klynge. FØLGENDE ER IP-adressene til dette oppsettet.

10.52.209.46 (Initial Master Node)
10.52.209.47 (Initial Slave Node)
10.52.209.49 (Initial Slave Node)

Standardport for Redis-server er 6379 Og Sentinel er 26379. Derfor må du sørge for at du åpner denne porten ved hjelp av,

sudo ufw allow 6379
sudo ufw allow 26379

redis-konfigurasjonene (begge i redis.conf og sentinel.conf) i de ovennevnte serverne skal konfigureres som følger.

for grunnleggende oppsett ovenfor konfigurasjoner vil være nok, men for produksjonsnivå kan du vurdere tipsene nevnt i siste del av dette innlegget. Den eneste forskjellen i redis.conf-filer i 3-servere er at alle slaver må ha følgende config. 10.52.209.46 Er Hoved IP-adressen.

slaveof 10.52.209.46 6379

slaveof forteller Redis cluster å gjøre denne spesielle serverforekomsten som EN SLAVEFOREKOMST av DEN gitte HOVEDNODEN (10.52.209.46).

i sentinel.conf, etter config varsle Sentinels å starte klyngen overvåking med følgende innledende innstillinger. Etterpå kan denne config-innstillingen automatisk oppdateres tilsvarende.

sentinel monitor mymaster 10.52.209.46 6379 2
(This tells sentinel to monitor the master node. And the last argument which is 2 is the quorum value)

Videre, sentinel.conf inkluderer følgende config verdier også.

sentinel down-after-milliseconds mymaster 5000
(Means server will unresponsive for 5 seconds before being classified as +down and consequently activating a +vote to elect a new master node.)sentinel failover-timeout mymaster 10000
(Specifies the failover timeout in milliseconds.)

Okie Dokie! Nå … la Oss kjøre Redis.

Det er mange måter Å kjøre Redis på. I denne demoen holder jeg meg til følgende kommando.

(Go to src folder.)
cd src/ && redis-server ../redis.conf &
cd src/ && redis-server ../sentinel.conf — sentinel &(Or else you can simply use cd utils && ./install_server.sh.)

Etter Det kan du bare sjekke Redis-prosessene via ps-ef / grep redis-kommandoen. Hver serverforekomst skal kjøre både En Redis-prosess og En Sentinel-prosess. Hvis alt går til planen, bør det være 2 prosesser som kjører som følger.

koble Nå Til Redis-klienten via en av følgende kommando og test om Redis fungerer bra.

redis-cli ping
or
redis-cli -h IP_Address pingYou should get a output of PONG.

Fantastisk! Nå har Du Redis oppe og går. La oss fokusere på Master/Slave replikering.

Master/Slave Replikering

nå hvis du sjekker redis.logg (som ligger på stedet vi definerte i redis.conf) av hver forekomst, kan du få se Master-Slave synkronisering skjedde.

Hovednode — redis.logg inn

Slave node-redis.logg inn

Kontrollerer Replikeringsstatus

du kan sjekke replikasjonsinformasjonen via info replication-kommandoen i Redis CLI også. Under rolleattributtet nevner det om den aktuelle noden er EN MESTER eller EN SLAVE(gul boks). i Tillegg viser Den i Hovednoden detaljene for alle tilkoblede slaver. (grønn boks)

la Oss nå undersøke hva sentinel.logg indikerer. (som ligger i stedet vi definerte i sentinel.conf)

Videre, hvis du sjekker sentinel.conf fil, kan du få se at conf filen oppdateres automatisk med de nyeste configs, inkludert sentinel kjent-slave og sentinel kjent-sentinel verdier.

Kult! La oss nå lage en prøveverdi i alle noder.

127.0.0.1:6739> set demokey "Amila"

SOM du kan se i diagrammet ovenfor, ER SLAVER KUN LEST, derfor kan du bare skrive data Til Master. Siden Redis asynkront replikerer med alle de gjenværende slavene, kan du hente den innsatte verdien fra Noen Redis slaver med samme gitt nøkkel. I tillegg via,KEYS* kan du liste alle tastene som er satt inn. Over diagrammet beskriver tydelig hva vi nettopp snakket om.

la Oss nå sjekke Hvordan Redis Sentinel Automatisk Failover fungerer.

Redis Sentinel Automatisk Failover

Okiee! La oss simulere et automatisk failover-scenario. For å simulere et failover-scenario kan du bare stoppe Redis-serveren eller drepe Redis-prosessen i HOVEDFOREKOMSTEN. Selv Du kan sove Redis prosessen også. Du kan velge hva du vil.

kill -9 <process id>
or
redis-cli -p 6379 DEBUG sleep 30
or
redis-cli -p 6379 DEBUG SEGFAULT

som illustrert i diagrammet ovenfor, i et failover-scenario, hvis HOVEDNODEN mislykkes, vil de 2 gjenværende Sentinelene bestemme failoveren, og hvis begge er enige (siden kvorumverdien er 2), vil en ny MASTER bli valgt fra de 2 gjenværende noder.

Følgende viser logghalen for dette failover-scenariet.

redis.logg Av Slave noder.

sentinel.logg Av Slave noder

nå la oss se etter replikering status via info replikering kommando.

videre utdype logghale,

Hver Sentinel oppdager at mesteren er nede med en +sdown – hendelse. (+sdown betyr at den angitte forekomsten nå Er Subjektivt Nede.)

+ new-epoch betyr at den nåværende epoken ble oppdatert.

+sdown hendelsen eskaleres senere til +odown, noe som betyr at flere Sentinels er enige om at mesteren ikke kan nås. (+odown betyr at den angitte forekomsten nå Er I Objektivt Nede tilstand.)

Sentinels +stem På En Sentinel som vil starte det første failover-forsøket.

failover skjer.

videre viser følgende oppstartjobber.

Oppstart For Redis

description "Redis Server"start on runlevel 
stop on runlevel script
echo $$ > /var/run/redis.pid
su - amila -c "cd /home/amila/redis-stable/src/; redis-server ../redis.conf"
end scriptpost-stop script
rm -f /var/run/redis.pid
end script

Oppstart For Sentinel

description "Redis Sentinel Server"start on runlevel 
stop on runlevel script
echo $$ > /var/run/redis.pid
su - amila -c "cd /home/amila/redis-stable/src/; redis-server ../sentinel.conf --sentinel"
end scriptpost-stop script
rm -f /var/run/redis.pid
end script

Gratulerer! Det er bare det. Slik håndterer Redis Høy Tilgjengelighet og Automatisk Failover. La oss nå se på noen interessante Redis-fakta før vi hopper inn for å optimalisere tips og triks.

Interessante fakta Om Redis.

Redis kan håndtere opptil 2 32 nøkler, og ble testet i praksis for å håndtere minst 250 millioner nøkler per forekomst.

en tom forekomst bruker ~ 3 MB minne.

1 Million små Nøkler- > Strengverdipar bruker ~ 85 MB minne.

1 Million Keys -> Hash verdi, som representerer et objekt med 5 felt, bruk ~ 160 MB minne.

Redis er enkelt gjenget. Hvordan kan jeg utnytte flere CPU / kjerner?

DET er ikke så ofte AT CPU blir flaskehalsen din Med Redis, Da Redis vanligvis er enten minne eller nettverksbundet. Hvis det er tilfelle, vil horisontal eller vertikal skalering Av Redis-forekomster bidra til å redusere CPU – relaterte flaskehalser.

Redis Er en minne, men vedvarende på diskdatabase.

Vedvarende Redis -> RDB : punkt-i-tid øyeblikksbilder av datasettet på angitte intervaller. (Data backup)| aof : logger hver skriveoperasjon mottatt av serveren. (Mer Holdbar)

hvis Du bruker Java, kan Du bruke Jedis som er en java-klient, for å koble Java-programmet Med Redis. Merk: Jedis bruker Apache Commons Pool for tilkobling pooling (GenericObjectPool). A single Jedis instance is not threadsafe! for å unngå disse problemene, bør Du bruke JedisPool, som er en threadsafe pool av nettverkstilkoblinger. Standard maks tilkoblingsbassengstørrelse er 8.

la Oss nå fokusere på problemene / feilene du kan få og noen produksjonsytelsesoptimaliseringstips og triks for Redis.

Problemer / Feil som du kan få& optimaliseringstips og triks For produksjonsytelse

Først av alt, i redis.conf og sentinel.conf, alle configs er i en ordre så ikke rotet opp med ordren. Ellers vil du få config feil som følger.

*** FATAL CONFIG FILE ERROR ***
Reading the configuration file, at line 98
>>> 'sentinel down-after-milliseconds mymaster 5000'
No such master with specified name.

fra sikkerhetsperspektiv setter du opp et passord for å autentisere med master og slaver. For dette kan du enkelt endre redis.conf og sentinel.conf tilsvarende med følgende config verdi.

In sentinel.conf
sentinel auth-pass <master-name> <password>In redis.conf
masterauth <master-password>

Gjør At tcp-backlog-innstillingen (Maks.tilkoblinger) er 511. Du kan angi denne verdien tilsvarende (Vurderer serverspesifikasjonen) med følgende trinn.

sudo nano /etc/rc.local
Add this:
sysctl -w net.core.somaxconn=65535When you reboot the next time, the new setting will be to allow 65535 connections instead of 128 as before. When you add the line to rc.local make sure it's before the exit 0.

noen av advarslene som du kanskje kommer over fra redis.logg kan være,

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.You can add this via following command as well as using a cat command you can makesure whether the value is set properly.echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf
cat /etc/sysctl.conf

Du må kanskje deaktivere THP Eller Gjennomsiktig Stor Side.

WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.Fixsudo nano /etc/rc.local
echo never > /sys/kernel/mm/transparent_hugepage/enabled

BRUK AV UNIX socket i stedet FOR TCP-port 6379 vil også bidra til Redis ytelsesgevinst.

for å oppnå dette, redis.conf bør endres til følgende innstilling.

unixsocket /var/run/redis.sock
unixsocketperm 777# Accept connections on the specified port, default is 6379.
# If port 0 is specified Redis will not listen on a TCP socket.
port 0

i Tillegg, avhengig Av brukssaken, kan Du også konfigurere redis persistence-alternativet.

hvis du ønsker det, kan du deaktivere utholdenhet i det hele tatt, hvis du vil at dataene dine bare skal eksistere så lenge serveren kjører. Merk: du kan deaktivere RDB utholdenhet ved å kommentere alle» lagre » linjer i redis.conf som følger.

Comment out these 3 values in redis.conf
save 900 1
save 300 10
save 60 10000rdbcompression no
rdbchecksum no

aof persistance (Tilføy Bare Fil) er deaktivert som standard i redis.conf.

appendonly no

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Overvåking Redis

Fra Overvåkingsperspektiv er det flere verktøy for å overvåke Redis. NewRelic gir forhånd evner til å overvåke Og analysere Redis inkludert «Mest tid konsumert db operasjoner», «operations by throughput», «operations by query time» og etc.

Mer informasjon Om New Relic Redis er nevnt her. I tillegg Er Redis-stat også en god opensource Redis overvåkingsverktøy.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

AWS ElasticCache

AWS tilbyr også en in-memory cache cloud-tjeneste kalt «ElastiCache», som også kommer Med Redis inkludert. Den kan spesifiseres som en effektiv, brukervennlig skytjeneste, som avlaster de fleste manuelle konfigurasjoner og administrative oppgaver.

ElastiCache Er en webtjeneste som gjør det enklere å starte, administrere og skalere en distribuert minnebuffer i skyen.

Interessant, det leveres med fantastiske avanserte funksjoner som Cluster-Modus med sharding innen få klikk, Multi-AZ Med Auto-Failover, Kryptering i ro, Kryptering i transitt, Import RDB-fil Til S3, Aktiver automatisk sikkerhetskopiering og mange flere.

Den Kuleste funksjonen I AWS ElastichCache er at DEN tilbyr et omfattende overvåkingsdashbord for Redis-klyngen din, inkludert overvåkingsaspekter som CPU/Minneutnyttelse (Bytte og Ledig minne), Tilkoblingsantall, Elementantall, Utkastelser, Streng;Nøkkel;Hash-Basert Kommandotelling, Replikeringslag og mange flere.

Vel … det er ganske mye det for dette innlegget!

som jeg nevnte i begynnelsen av dette innlegget, er det mange Forskjellige Redis-artikler der ute, men jeg ønsket å lage en «alt i en riktig artikkel» som dekker de mest essensielle fakta og tips som er nødvendig og nyttig for en utvikler eller en devops-ingeniør for å bygge En Svært Tilgjengelig Redis-klynge med Sentinel.

før jeg avsluttet dette innlegget, var En av de interessante artiklene Jeg fant, Hvordan Flickr implementerte Redis Sentinel. Vennligst sørg for å sjekke at innlegget også.

OK. Så takk så mye for å lese denne artikkelen, og jeg ser frem til å komme opp med en annen interessant artikkel snart, dele min erfaring som utvikler. Inntil Da, Skål! God Koding!