Redis is een geavanceerde sleutelwaardedatabase. Het lijkt op memcached, maar de data kan behouden blijven en de datatypes zijn rijk. Er zijn strings, gekoppelde lijsten, sets en geordende collecties. Het ondersteunt het berekenen van het optellen, snijden en complementeren (verschil) van verzamelingen aan de serverzijde, en ondersteunt ook diverse sorteerfuncties. Redis kan dus ook worden gezien als een datastructuurserver.
Alle Redis-gegevens worden in het geheugen opgeslagen en vervolgens van tijd tot tijd asynchroon op de schijf opgeslagen (dit wordt "semi-persistent modus" genoemd); Je kunt ook elke datawijziging in een Append Only File (AOF) schrijven (dit heet "full persistence mode").
De eerste methode is filesnapshotting: de standaard redis bewaart gegevens op de schijf in de vorm van een snapshot (een binair bestand, dump.rdb, deze bestandsnaam kan worden opgegeven), en het formaat in het configuratiebestand is: save N M betekent dat redis binnen N seconden een snapshot naar de schijf zal maken als er minstens M wijzigingen in redis plaatsvinden. Natuurlijk kunnen we ook handmatig save of bgsave (asynchrone) uitvoeren om snapshots te maken.
Hier is een korte introductie van hoe het werkt: Wanneer Redis moet blijven bestaan, zal Redis een kindproces forken; Het kindproces schrijft de gegevens naar een tijdelijk RDB-bestand op de schijf; Wanneer het subproces het tijdelijke bestand heeft geschreven, vervangt het de originele RDB, wat het voordeel heeft van copy-on-write
Er is ook een persistentiemethode Append-only:filesnapshotting-methode. Wanneer redis abnormaal dood is, gaat de recente data verloren (de hoeveelheid verloren data hangt af van de configuratie van je save-beleid), dus dit is het grootste nadeel: als het bedrijfsvolume groot is, is de verloren data veel. De append-only methode kan alle dataverlies veroorzaken, maar de prestaties van Redis zijn slechter. AOF kan gedurende het hele proces worden gehandhaafd, hoeft alleen ingeschakeld te worden in het configuratiebestand (standaard is nee), appendonly yes. Nadat AOF is ingeschakeld, wordt elke keer dat redis een commando uitvoert om data te wijzigen, toegevoegd aan het aof-bestand, en wanneer redis opnieuw wordt opgestart, wordt het AOF-bestand gelezen voor "replay" om het te herstellen tot het laatste moment voordat redis wordt gesloten.
LOG-herschrijven Naarmate het AOF-bestand steeds groter wordt naarmate de data wordt gewijzigd, waarvan vele wijzigingen in een sleutel registreren. Daarom heeft redis een interessante functie: het AOF-bestand op de achtergrond reconstrueren zonder de client-side operatie te beïnvloeden. Het uitvoeren van het BGREWRITEAOF-commando op elk moment schrijft de kortste reeks commando's in het huidige geheugen naar de schijf, en deze commando's kunnen de huidige datasituatie volledig construeren zonder onnodige wijzigingen (zoals toestandswijzigingen, tellerwijzigingen, enz.), waardoor de grootte van het AOF-bestand wordt verkleind. Dus bij het gebruik van OF raadt Redis ook BGREWRITEAOF aan.
Er zijn drie manieren om het AOF-bestand te verversen, zie de configuratieparameter appendfsync: appendfsync roept altijd fsync aan om naar het AOF-bestand te spoelen telkens wanneer een wijzigingscommando wordt ingediend, wat heel, heel traag is, maar ook zeer veilig; appendfsync everysec roept fsync elke seconde aan om snel naar het AOF-bestand te spoelen, maar kan binnen een seconde data verliezen; appendfsync no vertrouwt op het besturingssysteem om te verversen, Redis ververst de OV niet actief, wat het snelst is, maar de beveiliging is slecht. Verversen per seconde wordt standaard aanbevolen, zodat zowel snelheid als veiligheid worden meegenomen.
Het kan door systeemredenen komen dat de AOF beschadigd is, Redis kan deze OF de OV niet meer laden, je kunt de onderstaande stappen volgen om het te repareren: Maak eerst een back-up van het AOF-bestand en kopieer het naar een andere plek; Fix het originele OF-bestand, voer uit: $redis-check-aof –fix; Je kunt het diff –u commando gebruiken om te zien waar de bestanden inconsistent zijn voor en na de reparatie. Herstart de Redis-dienst.
Hoe LOG Rewrite werkt: Hetzelfde gebruikt copy-on-write: eerst vertakkt Redis een kindproces; Het kindproces schrijft de laatste AOF naar een tijdelijk bestand; Het ouderproces schrijft incrementeel de laatst uitgevoerde wijzigingen in het geheugen (op dit moment is de oude AOF nog steeds geschreven en is het veilig om te herschrijven als deze faalt); Wanneer het kindproces het tijdelijke bestand heeft herschreven, ontvangt het ouderproces een signaal en schrijft de eerdere incrementele wijzigingen in het geheugen naar het einde van het tijdelijke bestand. Redis hernoemt het oude OF-bestand, hernoemt het tijdelijke bestand en begint te schrijven naar het nieuwe OF-bestand.
Tot slot, voor het geval dat (machine crasht of schijfcrasht), vergeet niet regelmatig een back-up te maken van het *rdb *.aof-bestand dat is gegenereerd met filesnapshotting of Append-only op de externe machine. Ik gebruik elke half uur een Crontab om SCP te gebruiken. Ik heb de master-slave functie van Redis niet gebruikt, omdat een back-up van een half uur prima zou moeten zijn, en ik vind het een beetje zonde van de machine als je een master-slave hebt. Dit hangt uiteindelijk af van de toepassing.
|
Geplaatst op 24-08-2017 16:37:45
|
|
|
