Redis ist eine fortschrittliche Key-Value-Datenbank. Es ist ähnlich wie Memcached, aber die Daten können gespeichert werden und die Datentypen sind reichhaltig. Es gibt Strings, verkettete Listen, Sets und geordnete Sammlungen. Es unterstützt die Berechnung der Summierung, des Schneidens und der Komplementierung (Differenz) von Sammlungen auf der Serverseite und unterstützt außerdem eine Vielzahl von Sortierfunktionen. Redis kann also auch als Datenstrukturserver betrachtet werden.
Alle Redis-Daten werden im Speicher gespeichert und dann von Zeit zu Zeit asynchron auf der Festplatte gespeichert (dies wird als "semi-persistenter Modus" bezeichnet); Du kannst auch jede Datenänderung in eine Append Only File (AOF) schreiben (das nennt man "Full Persistence Mode").
Die erste Methode ist Filesnapshotting: Das Standard-Redis speichert Daten auf der Festplatte in Form eines Snapshots (eine Binärdatei, dump.rdb, dieser Dateiname kann angegeben werden), und das Format in der Konfigurationsdatei lautet: Save N M bedeutet, dass Redis innerhalb von N Sekunden einen Snapshot auf die Festplatte übernimmt, wenn mindestens M Änderungen in Redis vorgenommen werden. Natürlich können wir auch manuell Save oder bgsave (asynchron) ausführen, um Schnappschüsse zu machen.
Hier eine kurze Einführung in die Funktionsweise: Wenn Redis bestehen muss, forkt Redis einen Kind-Prozess; Der Kindprozess schreibt die Daten in eine temporäre RDB-Datei auf der Festplatte; Wenn der Unterprozess die temporäre Datei fertig geschrieben hat, ersetzt er das ursprüngliche RDB, das den Vorteil des Copy-on-Write-Modus hat
Es gibt auch eine Persistenzmethode, Append-only:filesnapshotting-Methode. Wenn Redis abnormal tot ist, gehen die aktuellen Daten verloren (die Menge der verlorenen Daten hängt von der Konfiguration Ihrer Speicherstrategie ab), daher ist dies der größte Nachteil: Wenn das Geschäftsvolumen groß ist, sind die verlorenen Daten sehr umfangreich. Die Append-only-Methode kann alle Datenverluste verursachen, aber die Leistung von Redis ist schlechter. AOF kann während des gesamten Prozesses beibehalten werden, muss nur in der Konfigurationsdatei aktiviert werden (standardmäßig ist nein), nur anhängen ja. Nachdem AOF aktiviert ist, wird jedes Mal, wenn Redis einen Befehl zur Datenänderung ausführt, zur Aof-Datei hinzugefügt, und wenn Redis neu gestartet wird, wird die AOF-Datei für "Replay" gelesen, um sie bis zum letzten Moment vor dem Schließen von Redis wiederherzustellen.
LOG-Umschreibung Während die AOF-Datei mit der Änderung der Daten immer größer wird, von denen viele Änderungen in einem Schlüssel aufzeichnen. Daher hat Redis eine interessante Funktion: Die AOF-Datei wird im Hintergrund rekonstruiert, ohne die clientseitige Operation zu beeinträchtigen. Das Ausführen des BGREWRITEAOF-Befehls zu jedem Zeitpunkt schreibt die kürzeste Folge von Befehlen im aktuellen Speicher auf die Festplatte, und diese Befehle können die aktuelle Datensituation vollständig konstruieren, ohne unnötige Änderungen (wie Zustandsänderungen, Zähleränderungen usw.), wodurch die Größe der AOF-Datei reduziert wird. Deshalb empfiehlt Redis beim Einsatz von OF auch BGREWRITEAOF.
Es gibt drei Möglichkeiten, die AOF-Datei zu aktualisieren, siehe den Konfigurationsparameter appendfsync: appendfsync ruft immer fsync auf, um bei jedem Änderungsbefehl mit der AOF-Datei zu flushen, was sehr, sehr langsam, aber auch sehr sicher ist; appendfsync everysec ruft fsync jede Sekunde auf, um schnell auf die AOF-Datei zu springen, kann aber innerhalb einer Sekunde Daten verlieren; appendfsync no verlässt sich auf das Betriebssystem zum Aktualisieren, Redis aktualisiert den OV nicht aktiv, was am schnellsten ist, aber die Sicherheit ist schlecht. Ein Refresh pro Sekunde wird standardmäßig empfohlen, sodass sowohl Geschwindigkeit als auch Sicherheit berücksichtigt werden.
Es könnte an systemtechnischen Gründen liegen, dass die AOF beschädigt ist, Redis kann diese OF der OV nicht mehr laden, du kannst die folgenden Schritte befolgen, um das zu beheben: Zuerst machst du ein Backup der AOF-Datei und kopierst sie an einen anderen Ort; Die ursprüngliche OF-Datei reparieren, ausführen: $redis-check-aof –fix; Du kannst den Befehl diff –u verwenden, um zu sehen, wo die Dateien vor und nach der Reparatur inkonsistent sind. Starte den Redis-Dienst neu.
Wie LOG Rewrite funktioniert: Dasselbe verwendet Copy-on-Write: Zuerst verteilt Redis einen Kindprozess; Der Kindprozess schreibt die neueste AOF in eine temporäre Datei; Der Elternprozess schreibt inkrementell die zuletzt ausgeführten Änderungen im Speicher (zu diesem Zeitpunkt ist die alte AOF noch geschrieben, und es ist sicher, sie neu zu schreiben, falls sie fehlschlägt); Wenn der Kindprozess die temporäre Datei umgeschrieben hat, erhält der Elternprozess ein Signal und schreibt die vorherigen inkrementellen Änderungen im Speicher bis zum Ende der temporären Datei. Redis benennt die alte OF-Datei um, benennt die temporäre Datei um und beginnt, an die neue OF zu schreiben.
Und schließlich, falls (Rechner oder Festplattenabstürze) abstürzt, denkt daran, regelmäßig die *rdb *.aof-Datei, die mit Filesnapshotting oder Append-only auf dem entfernten Rechner generiert wurde, zu sichern. Ich benutze alle halbe Stunde einen Crontab, um SCP zu machen. Ich habe die Master-Slave-Funktion von Redis nicht benutzt, weil ein halbstündiges Backup ausreichen sollte, und ich finde, es ist eine Verschwendung der Maschine, wenn man einen Master-Slave hat. Das hängt letztlich von der Anwendung ab.
|
Veröffentlicht am 24.08.2017 16:37:45
|
|
|
