Redis ist ein unverzichtbarer Dienst für die aktuelle Webprogrammierung. Seine Eigenschaften liegen auf der Hand: Es kann ohne Datenverlust zwischengespeichert und neu gestartet werden, was sehr einfach zu verwenden ist. Die Frage ist also: Wie macht man das?
RDB
RDB ist ein Mittel zur Persistenz, das unter bestimmten Bedingungen Daten im Speicher auf die Festplatte schreibt. Unter welchen Bedingungen wird es also geschrieben? Es ist unmöglich, ohne nachzudenken zu schreiben. Es kann nicht lange dauern, bis der Computer ausfällt und alle Daten verloren gehen ist es besser, memcached zu verwenden. In der Redis-Konfiguration gibt es eine solche Konfiguration:
900 1 speichern
300 10 speichern
60 10000 speichern
Ein sehr wichtiger Teil der Konfiguration, der den Kern der RDB-Persistenz bildet. Es bedeutet:
1. Wenn innerhalb von 900 Sekunden eine Schlüsseländerung (Einfügung oder Aktualisierung) erfolgt, werde ich sie mit der Festplatte synchronisieren
2 Wenn in 300 Sekunden Wenn sich 10 Schlüssel ändern (Einfügen oder Aktualisieren), synchronisiere ich sie mit der Festplatte
3. Wenn sich in 60 Sekunden 10.000 Schlüssel ändern (Einfügen oder Aktualisieren), synchronisiere ich sie mit der Festplatte
Woher kennen wir diese Zeitpunkte und die Anzahl der Änderungen? Es gibt derzeit zwei weitere äußerst kritische Dinge, eines wird als Dirty Counter bezeichnet und das andere wird Lastsave (der Zeitpunkt der letzten Speicherung) genannt. Der Dirty-Zähler zeichnet insbesondere die Zeit seit der letzten Speicherung auf. Lastsave zeichnet die Zeit auf, zu der die Speicherung ausgeführt wurde. Die anfängliche Zeit ist beispielsweise time1 und Dirty ist 0. Zu diesem Zeitpunkt haben sich 20 Schlüssel geändert. Dirty ist 20, und dann ist die aktuelle Zeit time2, time2-time1 > ;= 300. Wenn die zweite Bedingung erfüllt ist, werden die Daten im Speicher gespeichert und Dirty auf 0 gelöscht. Warten Sie dann, bis die Bedingung erfüllt ist ausgelöst werden.
Wenn ich in 60 Sekunden 100.000 Schlüssel habe, tritt das Problem auf. Es kommt zu einer großen Anzahl von Festplatten-E/A-Vorgängen, und der Redis-Hauptprozess wird blockiert und alle Befehle während dieses Zeitraums werden nicht ausgeführt. Wie kann das gemacht werden? Also kam ein Prozess namens bgsave, der ein vom Haupt-Redis-Prozess abgespaltener Unterprozess ist, der auf die Durchführung von RDB-Persistenzarbeiten spezialisiert ist.
Das gespeicherte Dateiformat liegt im Binärformat vor. Wenn die Datenbank ausfällt, ist für die Wiederherstellung kein menschliches Eingreifen erforderlich, und Redis liest die Festplattendatei automatisch.
AOF
Im Gegensatz zu RDB speichert AOF die von Ihnen ausgeführten Befehle. Wenn die aof-Funktion aktiviert ist, wird der ausgeführte Aktualisierungsbefehl nicht direkt in die aof-Datei geschrieben Anstatt zuerst in einen AOF-Buf zu schreiben, wissen wir, dass wir nicht immer in den Buf schreiben können. Wann kann er also mit der Festplatte synchronisiert werden? Es gibt auch eine solche Konfiguration in Redis
appendfsync Always
appendfsync everysec
appendfsync no
bedeutet:
Solange Da es ein Update gibt, werde ich den Befehl synchronisieren
2. Wenn die letzte Synchronisierungszeit mehr als eine Sekunde entfernt ist, synchronisieren Sie
3. Wenn es nicht synchronisiert ist, warten Sie auf den Betrieb System selbst beurteilen (ich werde synchronisieren, wenn ich frei bin) )
Nach der Analyse ist die erste Art von IO häufig und der IO-Druck ist hoch, aber die Wahrscheinlichkeit eines Datenverlusts ist am geringsten Der io-Druck ist nicht sehr hoch und es geht höchstens etwa 1 Sekunde an Daten verloren. Der dritte io-Typ ist gering und die Wahrscheinlichkeit eines Datenverlusts ist zu hoch. Alles in allem ist es im Allgemeinen die zweite Option. Aber es gibt immer noch ein Problem. Logischerweise ist num 100. Es gibt 100 gleiche Befehle. Daran ist also nichts auszusetzen ? Das gleiche Ergebnis benötigt 99-mal mehr Platz, was sehr verschwenderisch ist. Wie erfolgt das Umschreiben? Es ist ganz einfach: Lesen Sie zuerst den aktuellen Wert aus der Datenbank und ersetzen Sie ihn dann durch einen Datensatz. Dies ist das Prinzip des AOF-Umschreibens. Das Umschreiben nimmt Zeit in Anspruch und wird daher von einem untergeordneten Prozess durchgeführt. Was soll ich tun, wenn während des Umschreibvorgangs ein neuer Befehl eingeht? Die alte Methode besteht darin, den Puffer nach Abschluss des Umschreibens an den neuen AOF anzuhängen und dann den alten AOF zu ersetzen neues aof. Das Umschreiben wurde implementiert.
Dieser Artikel stammt aus dem Redis-Tutorial, willkommen zum Lernen.
Das obige ist der detaillierte Inhalt vonSo erreichen Sie Persistenz in Redis. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!