Redis är en avancerad nyckelvärdesdatabas. Det liknar memcached, men datan kan bevaras och datatyperna är rika. Det finns strängar, länkade listor, set och ordnade samlingar. Den stödjer beräkning av summa, korsning och kompletterande (differens) av samlingar på serversidan, och stöder även en mängd sorteringsfunktioner. Så Redis kan också ses som en server för datastrukturer.
All Redis-data lagras i minnet och lagras sedan asynkront på disk från tid till annan (detta kallas "semi-persistent mode"); Du kan också skriva varje dataändring i en Append Only File (AOF) (detta kallas "full persistensläge").
Den första metoden är filsnapshotting: standardredis sparar data på disken i form av en snapshot (en binär fil, dump.rdb, detta filnamn kan specificeras), och formatet i konfigurationsfilen är: save N M betyder att inom N sekunder tar redis en snapshot till disk om minst M ändringar sker i redis. Självklart kan vi också manuellt utföra save eller bgsave (asynkront) för att ta snapshots.
Här är en kort introduktion till hur det fungerar: När Redis behöver fortsätta kommer Redis att forka en barnprocess; Barnprocessen skriver datan till en tillfällig RDB-fil på disken; När delprocessen är klar med att skriva den temporära filen ersätter den den ursprungliga RDB, som har fördelen av copy-on-write
Det finns också en persistensmetod Append-only:filesnapshotting-metod. När redis är onormalt död förloras den senaste datan (mängden förlorad data beror på konfigurationen av din sparpolicy), så detta är dess största nackdel, när affärsvolymen är stor är den förlorade datan mycket. Append-only-metoden kan uppnå all dataförlust, men prestandan hos redis är sämre. AOF kan bevaras under hela processen, behöver bara aktiveras i konfigurationsfilen (standard är nej), appendendast ja. Efter att AOF är aktiverad, varje gång redis utför ett kommando för att ändra data, läggs det till i aof-filen, och när redis startas om läses AOF-filen för "replay" för att återställas till sista stund innan redis stängs.
LOG-omskrivning När AOF-filen blir större och större när datan modifieras, registrerar många av dessa förändringar i en nyckel. Därför har redis en intressant funktion: att rekonstruera AOF-filen i bakgrunden utan att påverka klientsidans operation. Att köra BGREWRITEAOF-kommandot när som helst skriver den kortaste sekvensen av kommandon i det aktuella minnet till disken, och dessa kommandon kan fullt ut konstruera den aktuella datasituationen utan onödiga förändringar (såsom tillståndsändringar, räknarändringar, etc.), vilket minskar storleken på AOF-filen. Så när du använder OF rekommenderar Redis att du också använder BGREWRITEAOF.
Det finns tre sätt att uppdatera AOF-filen, se konfigurationsparametern appendfsync: appendfsync anropar alltid fsync för att flusha till AOF-filen varje gång ett modifieringskommando skickas in, vilket är mycket, mycket långsamt men också mycket säkert; appendfsync everysec anropar fsync varje sekund för att snabbt rensa till AOF-filen, men kan förlora data inom en sekund; appendfsync no förlitar sig på att operativsystemet uppdateras, Redis uppdaterar inte aktivt OV:en, vilket är snabbast, men säkerheten är dålig. Uppdatering per sekund rekommenderas som standard, så att både hastighet och säkerhet tas i beaktande.
Det kan bero på systemorsaker som AOF:en är korrupt, Redis kan inte längre ladda denna OF OV, du kan följa stegen nedan för att åtgärda det: Gör först en backup av AOF-filen och kopiera den till ett annat ställe; Fixa originalfilen OF, kör: $redis-check-aof –fix; Du kan använda kommandot diff –u för att se var filerna är inkonsekventa före och efter reparationen. Starta om Redis-tjänsten.
Hur LOG Rewrite fungerar: Samma använder copy-on-write: först förgrenar redis en underprocess; Barnprocessen skriver den senaste AOF till en tillfällig fil; Föräldraprocessen skriver inkrementellt de senaste exekverade ändringarna i minnet (vid denna tidpunkt är den gamla AOF:en fortfarande skriven, och det är säkert att skriva om om den misslyckas); När barnprocessen är klar med att skriva om den tillfälliga filen tar föräldraprocessen emot en signal och skriver de tidigare inkrementella minnesändringarna till slutet av den tillfälliga filen. Redis byter namn på den gamla OF-filen, byter namn på den temporära filen och börjar skriva till den nya OF-filen.
Slutligen, för säkerhets skull (maskinen eller disken krascher), kom ihåg att regelbundet säkerhetskopiera *rdb *.aof-filen som genereras med filsnapshotting eller Append-only på den fjärranslutna maskinen. Jag använder en Crontab för att SCP:a var halvtimme. Jag använde inte Redis master-slave-funktion, eftersom en halvtimmes backup borde räcka, och jag tycker det är lite slöseri med maskinen om man har en master-slave. Detta beror i slutändan på applikationen.
|
Publicerad på 2017-08-24 16:37:45
|
|
|
