Wir alle wissen, dass sich alle Redis-Daten im Speicher befinden. Wenn es zu einem plötzlichen Ausfall kommt, gehen alle Daten verloren.
Daher muss es einen Mechanismus geben, der sicherstellt, dass Redis-Daten nicht aufgrund von Fehlern verloren gehen. Dieser Mechanismus ist der Persistenzmechanismus von Redis. (Empfohlenes Lernen: Redis-Video-Tutorial)
Redis verfügt über zwei Persistenzmechanismen: Der erste ist ein Snapshot und der zweite ist ein AOF-Protokoll. Ein Snapshot ist eine vollständige Sicherung und ein AOF-Protokoll ist eine kontinuierliche inkrementelle Sicherung. Snapshots sind binär serialisierte Formen von Speicherdaten und sind sehr kompakt im Speicher, während AOF-Protokolle den Anweisungsdatensatztext von Speicherdatenänderungen aufzeichnen. AOF-Protokolle werden während des Langzeitbetriebs extrem groß. Wenn die Datenbank neu gestartet wird, müssen die AOF-Protokolle für die Befehlswiedergabe geladen werden, was extrem lange dauern wird. Daher müssen AOF-Protokolle regelmäßig neu geschrieben werden AOF-Protokolle.
Snapshot-Prinzip
Wir wissen, dass Redis ein Single-Thread-Programm ist. Dieser Thread ist für gleichzeitige Lese- und Schreibvorgänge mehrerer Client-Sockets und Speicherdatenstrukturen verantwortlich Logisches Lesen und Schreiben zugleich.
Während der Anforderung über die Serviceleitung muss Redis auch Speicher-Snapshots durchführen. Für Speicher-Snapshots muss Redis Datei-E/A-Vorgänge ausführen, Datei-E/A-Vorgänge können jedoch nicht die Multiplexing-API verwenden.
Das bedeutet, dass ein einzelner Thread, während er Anfragen auf der Service-Leitung stellt, auch Datei-E/A-Vorgänge ausführen muss und Datei-E/A-Vorgänge die Leistung von Serveranforderungen erheblich beeinträchtigen.
Es gibt noch ein weiteres wichtiges Problem: Um das Online-Geschäft nicht zu blockieren, muss Redis bei der Beantwortung von Kundenanfragen beharrlich bleiben. Während der Speicherung ändert sich die Speicherdatenstruktur immer noch. Beispielsweise wird ein großes Hash-Wörterbuch beibehalten, aber es kommt eine Anfrage und löscht es, aber es wurde noch nicht beibehalten.
Redis verwendet den Multiprozess-COW-Mechanismus (Copy On Write) des Betriebssystems, um Snapshot-Persistenz zu erreichen. Dieser Mechanismus ist sehr interessant und nur wenige Menschen wissen davon.
AOF-Prinzip
Das AOF-Protokoll speichert die sequentielle Befehlssequenz des Redis-Servers. Das AOF-Protokoll zeichnet nur Anweisungen auf, die den Speicher ändern.
Angenommen, das AOF-Protokoll zeichnet alle geänderten Befehlssequenzen seit der Erstellung der Redis-Instanz auf, dann kann Redis wiederhergestellt werden, indem alle Anweisungen nacheinander auf einer leeren Redis-Instanz ausgeführt werden – d. h. „Wiederholen“ des Status der Die In-Memory-Datenstrukturen der aktuellen Instanz.
Redis führt nach Erhalt des Client-Änderungsbefehls eine Parameterüberprüfung und Logikverarbeitung durch. Wenn kein Problem vorliegt, wird der Befehlstext sofort im AOF-Protokoll gespeichert. Mit anderen Worten, der Befehl wird zuerst ausgeführt. Protokoll speichern. Dies unterscheidet sich von Speicher-Engines wie leveldb und hbase, die zuerst Protokolle speichern und dann eine logische Verarbeitung durchführen.
Während des Langzeitbetriebs von Redis wird das AOF-Protokoll immer länger. Wenn die Instanz abstürzt und neu gestartet wird, ist die Wiedergabe des gesamten AOF-Protokolls sehr zeitaufwändig, was dazu führt, dass Redis für längere Zeit keine externen Dienste bereitstellen kann. Daher muss das AOF-Protokoll verkleinert werden.
Weitere technische Artikel zum Thema Redis finden Sie in der Spalte Einführung in das Redis-Datenbanknutzungs-Tutorial, um mehr zu erfahren!
Das obige ist der detaillierte Inhalt vonWas soll ich tun, wenn Redis nicht verfügbar ist?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!