Redis er en avansert nøkkelverdidatabase. Det ligner på memcached, men dataene kan lagres og datatypene er rike. Det finnes strenger, lenkede lister, sett og ordnede samlinger. Den støtter beregning av summering, kryssing og komplement (forskjell) av samlinger på serversiden, og støtter også en rekke sorteringsfunksjoner. Så Redis kan også sees på som en datastrukturserver.
All Redis-data lagres i minnet og lagres deretter asynkront på disk fra tid til annen (dette kalles "semi-persistent modus"); Du kan også skrive hver dataendring inn i en Append Only File (AOF) (dette kalles "full persistensmodus").
Den første metoden er filesnapshotting: Standard redis vil lagre data på disken i form av et snapshot (en binær fil, dump.rdb, dette filnavnet kan spesifiseres), og formatet i konfigurasjonsfilen er: save N M betyr at innen N sekunder vil redis ta et snapshot til disken hvis minst M endringer skjer i redis. Selvfølgelig kan vi også manuelt utføre save eller bgsave (asynkront) for å ta snapshots.
Her er en kort introduksjon til hvordan det fungerer: Når Redis trenger å bestå, vil Redis forke en barneprosess; Barneprosessen skriver dataene til en midlertidig RDB-fil på disk; Når delprosessen er ferdig med å skrive den midlertidige filen, erstatter den den opprinnelige RDB-en, som har fordelen av copy-on-write
Det finnes også en persistensmetode, Append-only:filesnapshotting-metode. Når redis er unormalt død, vil de nylige dataene gå tapt (mengden tapt data avhenger av konfigurasjonen av lagringspolicyen din), så dette er den største ulempen; når forretningsvolumet er stort, er det mange tapte data. Append-only-metoden kan oppnå all datatap, men ytelsen til Redis er dårligere. AOF kan bevares gjennom hele prosessen, trenger bare å slås på i konfigurasjonsfilen (standard er nei), legg bare til ja. Etter at AOF er aktivert, vil hver gang redis utfører en kommando for å endre data, legges den til aof-filen, og når redis startes på nytt, vil AOF-filen bli lest for "replay" for å gjenopprette til siste øyeblikk før redis lukkes.
LOG-omskriving Etter hvert som AOF-filen blir større og større etter hvert som dataene endres, registrerer mange endringer i en nøkkel. Derfor har redis en interessant funksjon: å rekonstruere AOF-filen i bakgrunnen uten å påvirke klientoperasjonen. Å kjøre BGREWRITEAOF-kommandoen når som helst vil skrive den korteste sekvensen av kommandoer i det nåværende minnet til disken, og disse kommandoene kan fullstendig konstruere den nåværende datasituasjonen uten unødvendige endringer (som tilstandsendringer, tellerendringer osv.), noe som reduserer størrelsen på AOF-filen. Så når du bruker OF, anbefaler Redis også å bruke BGREWRITEAOF.
Det finnes tre måter å oppdatere AOF-filen på, se konfigurasjonsparameteren appendfsync: appendfsync kaller alltid fsync for å flushe til AOF-filen hver gang en modifikasjonskommando sendes inn, noe som er veldig, veldig tregt, men også veldig trygt; appendfsync everysec kaller fsync hvert sekund for raskt å flushe til AOF-filen, men kan miste data innen et sekund; appendfsync no er avhengig av at operativsystemet oppdaterer, Redis oppdaterer ikke aktivt OV-en, som er raskest, men sikkerheten er dårlig. Oppdatering per sekund anbefales som standard, slik at både hastighet og sikkerhet tas i betraktning.
Det kan skyldes systemårsaker at AOF-en er korrupt, Redis kan ikke lenger laste inn denne OV-en, du kan følge trinnene nedenfor for å fikse det: Først, ta en sikkerhetskopi av AOF-filen og kopier den til et annet sted; Fiks den originale OF-filen, kjør: $redis-check-aof –fix; Du kan bruke diff –u-kommandoen for å se hvor filene er inkonsistente før og etter reparasjonen. Start Redis-tjenesten på nytt.
Hvordan LOG Rewrite fungerer: Det samme bruker copy-on-write: først vil redis forke en barneprosess; Barneprosessen skriver den siste AOF til en midlertidig fil; Foreldreprosessen skriver gradvis de siste utførte endringene i minnet (på dette tidspunktet er den gamle AOF-en fortsatt skrevet, og det er trygt å omskrive hvis den feiler); Når barneprosessen er ferdig med å omskrive den midlertidige filen, mottar foreldreprosessen et signal og skriver de tidligere inkrementelle endringene i minnet til slutten av den midlertidige filen. Redis gir nytt navn til den gamle OF-filen, gir den midlertidige filen nytt navn, og begynner å skrive til den nye OF-filen.
Til slutt, bare i tilfelle (maskinen krasjer eller disken krasjer), husk å jevnlig ta sikkerhetskopi av *rdb *.aof-filen som genereres ved hjelp av filesnapshotting eller Append-only på den eksterne maskinen. Jeg bruker en Crontab for å SCP hver halvtime. Jeg brukte ikke Redis sin master-slave-funksjon, fordi en halvtimes backup burde være greit, og jeg synes det er litt bortkastet maskin hvis du har en master-slave. Dette avhenger til syvende og sist av applikasjonen.
|
Publisert på 24.08.2017 16:37:45
|
|
|
