Redis er en avanceret nøgle-værdi-database. Det ligner memcached, men dataene kan bevares, og datatyperne er rigelige. Der findes strenge, linkede lister, sæt og ordnede samlinger. Den understøtter beregning af summering, skæring og komplementering (forskel) af samlinger på serversiden og understøtter også en række sorteringsfunktioner. Så Redis kan også ses som en datastrukturserver.
Alle Redis-data gemmes i hukommelsen og lagres derefter asynkront på disken fra tid til anden (dette kaldes "semi-persistent mode"); Du kan også skrive alle dataændringer ind i en Append Only File (AOF) (dette kaldes "fuld persistenstilstand").
Den første metode er filsnapshotting: Standard redis vil lagre data på disken i form af et snapshot (en binær fil, dump.rdb, dette filnavn kan angives), og formatet i konfigurationsfilen er: gem N M betyder, at inden for N sekunder vil redis tage et snapshot til disken, hvis mindst M ændringer sker i redis. Selvfølgelig kan vi også manuelt udføre save eller bgsave (asynkront) for at tage snapshots.
Her er en kort introduktion til, hvordan det fungerer: Når Redis skal fortsætte, vil Redis forke en child process; Børneprocessen skriver dataene til en midlertidig RDB-fil på disken; Når delprocessen er færdig med at skrive den midlertidige fil, erstatter den den oprindelige RDB, som har fordelen af copy-on-write
Der findes også en persistensmetode Append-only:filesnapshotting-metode. Når redis er unormalt død, vil de seneste data gå tabt (mængden af tabte data afhænger af konfigurationen af din gemmepolitik), så dette er dens største ulempe; når forretningsvolumen er stor, er de tabte data mange. Append-only-metoden kan opnå alt datatab, men ydeevnen af redis er dårligere. AOF kan bevares gennem hele processen, skal kun slås til i konfigurationsfilen (standard er nej), appendonly ja. Efter AOF er aktiveret, vil hver gang redis udfører en kommando for at ændre data, blive tilføjet til aof-filen, og når redis genstartes, vil AOF-filen blive læst for at "afspille" for at gendanne til sidste øjeblik, før redis lukkes.
LOG-omskrivning Efterhånden som AOF-filen bliver større og større, efterhånden som dataene ændres, registrerer mange ændringer i en nøgle. Derfor har redis en interessant funktion: rekonstruer AOF-filen i baggrunden uden at påvirke klient-side operationen. Udførelse af BGREWRITEAOF-kommandoen når som helst vil skrive den korteste sekvens af kommandoer i den aktuelle hukommelse til disken, og disse kommandoer kan fuldt ud konstruere den aktuelle datasituation uden unødvendige ændringer (såsom tilstandsændringer, modændringer osv.), hvilket reducerer størrelsen på AOF-filen. Så når man bruger OF, anbefaler Redis også at bruge BGREWRITEAOF.
Der er tre måder at opdatere AOF-filen på, se konfigurationsparameteren appendfsync: appendfsync kalder altid fsync for at flushe til AOF-filen hver gang en ændringskommando indsendes, hvilket er meget, meget langsomt, men også meget sikkert; appendfsync everysec kalder fsync hvert sekund for hurtigt at flushe til AOF-filen, men kan miste data inden for et sekund; appendfsync no er afhængig af, at operativsystemet opdaterer, Redis opdaterer ikke aktivt OV'en, som er den hurtigste, men sikkerheden er dårlig. Opdatering pr. sekund anbefales som standard, så både hastighed og sikkerhed tages i betragtning.
Det kan skyldes systemårsager, at AOF'en er korrupt, redis kan ikke længere indlæse denne OF OV, du kan følge nedenstående trin for at rette det: Først laver du en backup af AOF-filen og kopierer den til et andet sted; Fix den oprindelige OF-fil, udfør: $redis-check-aof –fix; Du kan bruge diff –u-kommandoen til at se, hvor filerne er inkonsistente før og efter reparationen. Genstart Redis-tjenesten.
Sådan fungerer LOG Rewrite: Det samme bruger copy-on-write: først vil redis forke en child process; Børneprocessen skriver den seneste AOF til en midlertidig fil; Forældreprocessen skriver inkrementellvis de seneste udførte ændringer i hukommelsen (på dette tidspunkt er den gamle AOF stadig skrevet, og det er sikkert at omskrive, hvis den fejler); Når børneprocessen er færdig med at omskrive den midlertidige fil, modtager forældreprocessen et signal og skriver de tidligere inkrementelle ændringer i hukommelsen til slutningen af den midlertidige fil. Redis omdøber den gamle OF-fil, omdøber den midlertidige fil og begynder at skrive til den nye OF.
Endelig, bare for en sikkerheds skyld (maskinen crasher eller disken crasher), husk regelmæssigt at tage backup af *rdb *.aof-filen, der genereres ved hjælp af filesnapshotting eller kun Append-only på den eksterne maskine. Jeg bruger en Crontab til SCP hver halve time. Jeg brugte ikke Redis' master-slave-funktion, fordi en halv times backup burde være fint, og jeg synes, det er lidt spild af maskinen, hvis man har en master-slave. Det afhænger i sidste ende af anvendelsen.
|
Opslået på 24/08/2017 16.37.45
|
|
|
