|
|
Publicerad på 2021-02-04 13:47:27
|
|
|
|

1. Förord
Nyligen har Redis använts som en cache i projektet för att underlätta datadelning mellan flera affärsprocesser. Eftersom Redis-data lagras i minnet, om persistens inte är konfigurerad, förloras all data efter redis-omstart, så du måste aktivera persistensfunktionen i redis för att spara datan på disken, och när redis startas om kan du återställa data från disken. Redis erbjuder två sätt att persistera, RDB-persistens (principen är att dumpa Reids databasposter i minnet till RDB-persistens på disken) och det andra är AOF-persistens (principen är att skriva Reids operationsloggar till en fil i form av ett appendix). Så vad är skillnaden mellan dessa två persistensmetoder, och hur väljer man att ändra dem? Det mesta jag läser på internet introducerar hur man konfigurerar och använder dessa två metoder, men det finns ingen introduktion till skillnaden mellan dem och i vilka applikationsscenarier man ska använda.
2. Skillnaden mellan de två
RDB-persistens avser att skriva en ögonblicksbild av datamängden i minnet till disk inom ett angivet tidsintervall, och den faktiska processen är att forka en delprocess, först skriva datasetet till en temporär fil, sedan ersätta den föregående filen efter att skrivandet är lyckat, och lagra den med binär komprimering.
AOF-persistensen registrerar varje skriv- och borttagningsoperation som bearbetas av servern i form av en logg, och frågeoperationen kommer inte att registreras, utan kommer att registreras i text, och du kan öppna filen för att se den detaljerade operationsposten.
3. Fördelar och nackdelar med de två
Vilka är fördelarna med RDB?
1). När detta är använt kommer hela din Redis-databas bara att innehålla en fil, vilket är perfekt för filbackuper. Till exempel kan du vilja arkivera de senaste 24 timmarna varje timme, och även arkivera de senaste 30 dagarna varje dag. Med en sådan reservstrategi kan vi enkelt återhämta oss vid ett katastrofalt systemfel.
2). RDB är ett mycket bra val för katastrofåterställning. För vi kan enkelt komprimera en enda fil och överföra den till ett annat lagringsmedium.
3). Maximera prestationen. För Redis-tjänsteprocessen är det enda den behöver göra när persistens startar att forka ut barnprocesserna, och sedan kommer barnprocesserna att utföra dessa persistensuppgifter, vilket i hög grad kan förhindra att serviceprocessen utför IO-operationer.
4). Jämfört med AOF-mekanismen, om datamängden är stor, kommer uppstartseffektiviteten för RDB att vara högre.
Vilka är nackdelarna med RDB?
1). Om du vill säkerställa hög tillgång till data, det vill säga undvika dataförlust i största utsträckning, är RDB inte ett bra val. För när systemet går ner innan den schemalagda persistensen, kommer data som tidigare skrevs till disk att gå förlorad.
2). Eftersom RDB hjälper till med datapersistens via fork-delprocesser, kan datamängden om den är stor få hela servern att stanna tjänsten i hundratals millisekunder, eller till och med 1 sekund.
Vilka är fördelarna med AOF?
1). Denna mekanism kan ge större datasäkerhet, dvs. databeständighet. Det finns tre synkroniseringsstrategier i Redis, nämligen synkronisering per sekund, synkronisering per modifiering och desynkronisering. Faktum är att synkroniseringen per sekund också görs asynkront, och dess effektivitet är också mycket hög, skillnaden är att när systemet går ner, så förloras den modifierade datan inom denna sekund. Och varje gång en ändring synkroniseras kan vi tänka på det som synkroniseringspersistens, det vill säga varje dataändring som sker registreras omedelbart på disken. Det är förutsebart att denna metod är den minst effektiva. När det gäller ingen synkronisering finns det inget behov av att säga mer, jag tror att alla kan förstå det korrekt.
2). Eftersom mekanismen använder append-läget för att skriva loggfiler, kommer innehållet som redan finns i loggfilen inte att förstöras även om det finns en nedetid under skrivprocessen. Men om vi bara skriver hälften av datan och systemet kraschar den här gången, oroa dig inte, vi kan använda verktyget redis-check-aof för att hjälpa oss lösa problemet med datakonsistens innan nästa start av Redis.
3). Om loggen är för stor kan Redis automatiskt aktivera omskrivningsmekanismen. Det vill säga, Redis skriver kontinuerligt modifieringsdata till den gamla diskfilen i tilläggsläget, och Redis skapar också en ny fil för att registrera vilka modifieringskommandon som utförs under denna period. Därför kan datasäkerhet garanteras bättre när man byter mellan omskrivningar.
4). AOF innehåller en tydlig, lättförståelig loggfil som registrerar alla ändringar. Faktum är att vi också kan slutföra rekonstruktionen av datan genom denna fil.
Vilka är nackdelarna med OV?
1). För samma antal dataset är OF-filer vanligtvis större än RDB-filer. RDB återställer stora datamängder snabbare än AOF.
2). Beroende på synkroniseringsstrategin tenderar AOF att vara långsammare än RDB när det gäller körningseffektivitet. Kort sagt är effektiviteten hos synkroniseringspolicyn per sekund relativt hög, och effektiviteten hos den synkrona avstängningspolicyn är lika effektiv som för RDB.
Kriterierna för att välja de två är om systemet är villigt att offra viss prestanda i utbyte mot högre cache-konsistens (AOF), eller om det är villigt att inte aktivera säkerhetskopior i utbyte mot högre prestanda när skrivoperationer är frekventa, och sedan göra backuper (RDB) när sparfilen körs manuellt. RDB har en mer slutgiltig och konsekvent betydelse. Produktionsmiljön är dock egentligen mer en kombination av de två.
4. Vanliga konfigurationer
RDB-persistenskonfiguration
Redis dumpar en ögonblicksbild av datasetet i dump.rdb-filen. Dessutom kan vi också ändra frekvensen av Redis serverdump-snapshots genom konfigurationsfilen, efter att ha öppnat 6379.conf-filen söker vi efter save och kan se följande konfigurationsinformation:
AOF persistent konfiguration
Det finns tre sätt att synkronisera i Redis-profilen, de är:
Fullständig konfiguration:
En ny fil "appendonly.aof" kommer att skapas under testkatalogen, enligt följande:
|
Föregående:DataTables implementerar tabellexport Excel, CSV och utskriftNästa:SQL Server sätter nivån för transaktionsisolering
|