1. Forord
For nylig er Redis blevet brugt som en cache i projektet for at lette datadeling mellem flere forretningsprocesser. Da Redis-data gemmes i hukommelsen, vil alle data gå tabt efter redis-genstart, hvis persistens ikke er konfigureret, så du skal aktivere persistensfunktionen i redis for at gemme dataene på disken, og når redis genstartes, kan du gendanne data fra disken. Redis tilbyder to måder at bevare på: RDB-persistens (princippet er at dumpe Reids' databaseposter i hukommelsen til RDB-persistens på disken) og den anden er AOF-persistens (princippet er at skrive Reids' operationslogs til en fil i form af et appendiks). Så hvad er forskellen mellem disse to persistensmetoder, og hvordan vælger man at ændre det? De fleste ting, jeg læser på internettet, introducerer, hvordan man konfigurerer og bruger disse to metoder, men der er ingen introduktion til forskellen mellem de to, eller i hvilke applikationsscenarier man skal bruge.
2. Forskellen mellem de to
RDB-persistens refererer til at skrive et øjebliksbillede af datasættet i hukommelsen til disk inden for et angivet tidsinterval, og den faktiske driftsproces er at forke en delproces, først skrive datasættet til en midlertidig fil, derefter erstatte den forrige fil, når skrivningen er vellykket, og gemme den med binær komprimering.
AOF-persistensen registrerer hver skrive- og sletteoperation, som serveren behandlede, i form af en log, og forespørgselsoperationen vil ikke blive registreret, men vil blive registreret i tekst, og du kan åbne filen for at se den detaljerede operationspost.
3. Fordele og ulemper ved de to
Hvad er fordelene ved RDB?
1). Når denne er brugt, vil hele din Redis-database kun indeholde én fil, hvilket er perfekt til filbackup. For eksempel kan du ønske at arkivere de sidste 24 timer hver time og også arkivere de sidste 30 dage hver dag. Med en sådan backup-strategi kan vi nemt komme os i tilfælde af en katastrofal systemfejl.
2). RDB er et rigtig godt valg til katastrofeberedskab. Fordi vi nemt kan komprimere en enkelt fil og overføre den til et andet lagringsmedie.
3). Maksimer præstationen. For Redis-serviceprocessen er det eneste, den behøver at gøre, når persistens startes, at forke ud af børneprocesserne, og derefter vil børneprocesserne udføre disse persistensopgaver, hvilket i høj grad kan undgå, at serviceprocessen udfører IO-operationer.
4). Sammenlignet med AOF-mekanismen, hvis datasættet er stort, vil opstartseffektiviteten af RDB være højere.
Hvad er ulemperne ved RDB?
1). Hvis du ønsker at sikre høj tilgængelighed af data, dvs. undgå datatab i størst omfang, vil RDB ikke være et godt valg. For når systemet går ned før den planlagte persistens, vil de data, der tidligere blev skrevet til disk, gå tabt.
2). Da RDB hjælper med datapersistens gennem fork-underprocesser, kan datasættet, hvis datasættet er stort, få hele serveren til at stoppe tjenesten i hundreder af millisekunder eller endda 1 sekund.
Hvad er fordelene ved AOF?
1). Denne mekanisme kan give større datasikkerhed, dvs. datapersistens. Der findes 3 synkroniseringsstrategier i Redis, nemlig synkronisering per sekund, synkronisering pr. modifikation og desynkronisering. Faktisk sker synkroniseringen per sekund også asynkront, og effektiviteten er også meget høj; forskellen er, at når systemet går ned, vil de modificerede data gå tabt inden for dette sekund. Og hver gang en ændring synkroniseres, kan vi betragte det som synkroniseringspersistens, det vil sige, at hver dataændring, der sker, straks registreres på disken. Det er forudsigeligt, at denne metode er den mindst effektive. Hvad angår ingen synkronisering, er der ikke behov for at sige mere, jeg tror, alle kan forstå det korrekt.
2). Da mekanismen anvender append-tilstand til at skrive logfiler, vil indholdet, der allerede eksisterer i logfilen, ikke blive ødelagt selv under skriveprocessen. Men hvis vi kun skriver halvdelen af dataene, og systemet crasher denne gang, skal du ikke bekymre dig, vi kan bruge redis-check-aof-værktøjet til at hjælpe os med at løse datakonsistensproblemet inden næste start af Redis.
3). Hvis logen er for stor, kan Redis automatisk aktivere omskrivningsmekanismen. Det vil sige, at Redis kontinuerligt skriver modifikationsdataene til den gamle diskfil i append-tilstand, og Redis opretter også en ny fil til at registrere, hvilke modifikationskommandoer der udføres i denne periode. Derfor kan datasikkerhed bedre garanteres, når man skifter mellem omskrivninger.
4). AOF indeholder en klar, letforståelig logfil, der registrerer alle ændringer. Faktisk kan vi også fuldføre rekonstruktionen af dataene gennem denne fil.
Hvad er ulemperne ved OV?
1). For det samme antal datasæt er OF-filer normalt større end RDB-filer. RDB gendanner store datasæt hurtigere end AOF.
2). Afhængigt af synkroniseringsstrategien har AOF en tendens til at være langsommere end RDB med hensyn til driftseffektivitet. Kort sagt er effektiviteten af synkroniseringspolitikken pr. sekund relativt høj, og effektiviteten af den synkrone deaktiverelsespolitik er lige så effektiv som for RDB.
Kriterierne for valget af de to er, om systemet er villigt til at ofre noget ydeevne til fordel for højere cache-konsistens (AOF), eller om det er villigt til ikke at aktivere backups til fordel for højere ydeevne, når skriveoperationer er hyppige, og derefter lave backups (RDB) ved manuel kørsel af save. RDB har en mere endelig, konsekvent betydning. Produktionsmiljøet er dog faktisk mere en kombination af de to.
4. Almindelige konfigurationer
RDB-persistenskonfiguration
Redis dumper et snapshot af datasættet i dump.rdb-filen. Derudover kan vi også ændre hyppigheden af Redis server-dump-snapshots gennem konfigurationsfilen; efter åbning af 6379.conf-filen søger vi efter save, og vi kan se følgende konfigurationsinformation:
AOF persistent konfiguration
Der er tre måder at synkronisere i Redis-profilen, de er:
Fuldstændig konfiguration:
En ny fil "appendonly.aof" vil blive oprettet under testmappen som følger:
|
Opslået på 04/02/2021 13.47.27
|
|
|
|
Udlejer|
Opslået på 08/02/2021 11.45.25
|
Opslået på 22/09/2021 20.26.16