1. Forord
Nylig har Redis blitt brukt som en cache i prosjektet for å legge til rette for datadeling mellom flere forretningsprosesser. Siden Redis-data lagres i minnet, hvis persistens ikke er konfigurert, vil all data gå tapt etter restart av Redis, så du må aktivere persistensfunksjonen til Redis for å lagre dataene på disken, og når Redis startes på nytt, kan du gjenopprette data fra disken. Redis tilbyr to måter å opprettholde på: RDB-persistens (prinsippet er å dumpe Reids' databaseposter i minnet til RDB-persistens på disken) og den andre er AOF-persistens (prinsippet er å skrive Reids' operasjonslogger til en fil i form av et appendiks). Så hva er forskjellen mellom disse to persistensmetodene, og hvordan velger man å endre det? Det meste jeg leser på Internett introduserer hvordan man konfigurerer og bruker disse to metodene, men det finnes ingen introduksjon til forskjellen mellom de to, eller i hvilke applikasjonsscenarier man skal bruke.
2. Forskjellen mellom de to
RDB-persistens refererer til å skrive et øyeblikksbilde av datasettet i minnet til disk innen et spesifisert tidsintervall, og den faktiske operasjonsprosessen er å forke en delprosess, først skrive datasettet til en midlertidig fil, deretter erstatte den forrige filen etter at skrivingen er vellykket, og lagre den med binær komprimering.
AOF-persistensen registrerer hver skrive- og sletteoperasjon som serveren behandler i form av en logg, og spørringsoperasjonen vil ikke bli registrert, men vil bli registrert i tekst, og du kan åpne filen for å se den detaljerte operasjonsposten.
3. Fordeler og ulemper ved de to
Hva er fordelene med RDB?
1). Når dette er brukt, vil hele Redis-databasen din inneholde bare én fil, noe som er perfekt for sikkerhetskopiering. For eksempel kan du ønske å arkivere de siste 24 timene hver time, og også arkivere de siste 30 dagene hver dag. Med en slik backup-strategi kan vi enkelt gjenopprette ved en katastrofal systemfeil.
2). RDB er et veldig godt valg for katastrofegjenoppretting. Fordi vi enkelt kan komprimere en enkelt fil og overføre den til et annet lagringsmedium.
3). Maksimer ytelsen. For Redis-tjenesteprosessen er det eneste den trenger å gjøre når den starter persistens, å forke ut barneprosessene, og deretter vil barneprosessene fullføre disse persistensoppgavene, noe som i stor grad kan unngå at serviceprosessen utfører IO-operasjoner.
4). Sammenlignet med AOF-mekanismen, hvis datasettet er stort, vil oppstartseffektiviteten til RDB være høyere.
Hva er ulempene med RDB?
1). Hvis du ønsker å sikre høy tilgjengelighet av data, altså unngå datatap i størst mulig grad, vil RDB ikke være et godt valg. For når systemet går ned før planlagt persistens, vil dataene som tidligere ble skrevet til disken gå tapt.
2). Siden RDB hjelper til med datapersistens gjennom fork-underprosesser, kan datasettet få hele serveren til å stoppe tjenesten i hundrevis av millisekunder, eller til og med 1 sekund.
Hva er fordelene med AOF?
1). Denne mekanismen kan gi større datasikkerhet, altså datapersistens. Det finnes tre synkroniseringsstrategier i Redis, nemlig synkronisering per sekund, synkronisering per modifikasjon og desynkronisering. Faktisk gjøres synkroniseringen per sekund også asynkront, og effektiviteten er også svært høy; forskjellen er at når systemet går ned, vil de modifiserte dataene gå tapt i løpet av dette sekundet. Og hver gang en endring synkroniseres, kan vi tenke på det som synkroniseringspersistens, det vil si at hver dataendring som skjer blir umiddelbart registrert på disk. Det er forutsigbart at denne metoden er den minst effektive. Når det gjelder ingen synkronisering, er det ikke nødvendig å si mer, jeg tror alle kan forstå det riktig.
2). Siden mekanismen benytter append-modus for å skrive loggfiler, vil innholdet som allerede finnes i loggfilen ikke bli ødelagt selv om det er nedetid under skriveprosessen. Men hvis vi bare skriver halvparten av dataene og systemet krasjer denne gangen, ikke bekymre deg, vi kan bruke redis-check-aof-verktøyet for å hjelpe oss med å løse problemet med datakonsistens før neste start av Redis.
3). Hvis loggen er for stor, kan Redis automatisk aktivere omskrivingsmekanismen. Det vil si at Redis kontinuerlig skriver modifikasjonsdataene til den gamle diskfilen i append-modus, og Redis vil også opprette en ny fil for å registrere hvilke modifikasjonskommandoer som utføres i denne perioden. Derfor kan datasikkerhet garanteres bedre når man bytter mellom omskrivinger.
4). AOF inneholder en klar, lettforståelig loggfil som registrerer alle endringer. Faktisk kan vi også fullføre rekonstruksjonen av dataene gjennom denne filen.
Hva er ulempene med OV?
1). For samme antall datasett er OF-filer vanligvis større enn RDB-filer. RDB gjenoppretter store datasett raskere enn AOF.
2). Avhengig av synkroniseringsstrategien har AOF en tendens til å være tregere enn RDB når det gjelder kjøreeffektivitet. Kort sagt er effektiviteten til synkroniseringspolicyen per sekund relativt høy, og effektiviteten til den synkrone deaktiveringspolicyen er like effektiv som for RDB.
Kriteriene for å velge de to er om systemet er villig til å ofre noe ytelse i bytte mot høyere cache-konsistens (AOF), eller om det er villig til å ikke aktivere sikkerhetskopier i bytte mot høyere ytelse når skriveoperasjoner er hyppige, og deretter gjøre sikkerhetskopier (RDB) når lagret kjøres manuelt. rdb har en mer endelig og konsistent betydning. Men produksjonsmiljøet er faktisk mer en kombinasjon av de to.
4. Vanlige konfigurasjoner
RDB-persistenskonfigurasjon
Redis dumper et øyeblikksbilde av datasettet i dump.rdb-filen. I tillegg kan vi også endre hyppigheten av Redis server-dump-snapshots gjennom konfigurasjonsfilen, etter å ha åpnet 6379.conf-filen, søker vi etter save, og vi kan se følgende konfigurasjonsinformasjon:
AOF persistent konfigurasjon
Det finnes tre måter å synkronisere i Redis-profilen på, de er:
Fullstendig konfigurasjon:
En ny fil "appendonly.aof" vil bli opprettet under testkatalogen, som følger:
|
Publisert på 04.02.2021 13:47:27
|
|
|
|
Vert|
Publisert på 08.02.2021 11:45:25
|
Publisert på 22.09.2021 20:26:16