Erläuterung des Prinzips der Redis-Strategie zum Löschen abgelaufener Schlüssel

Dieser Artikel vermittelt Ihnen relevantes Wissen über Redis. Er stellt hauptsächlich das Prinzip der Redis-Strategie zum Löschen abgelaufener Schlüssel vor. Der Redis-Server verwendet tatsächlich zwei Strategien: verzögertes Löschen und regelmäßiges Löschen: Durch die Kombination dieser beiden Strategien wird der Server verwendet kann eine gute Balance zwischen rationeller Nutzung der CPU-Zeit und der Vermeidung von Speicherplatzverschwendung finden.

Empfohlenes Lernen: Redis-Video-Tutorial

Der Redis-Server verwendet tatsächlich zwei Strategien: verzögertes Löschen und reguläres Löschen: Durch die gemeinsame Verwendung dieser beiden Löschstrategien kann der Server die CPU-Zeit sinnvoll nutzen und ein Gleichgewicht zwischen beiden finden Vermeidung von verschwendetem Speicherplatz.

Verzögertes Löschen

Die Strategie des verzögerten Löschens ist am schonendsten für die CPU-Zeit: Das Programm überprüft den Schlüssel nur dann auf Ablauf, wenn er herausgenommen wird, wodurch sichergestellt werden kann, dass der Vorgang zum Löschen abgelaufener Schlüssel nur dann ausgeführt wird, wenn dies der Fall ist ausgeführt werden muss und das Löschziel auf die aktuell verarbeiteten Schlüssel beschränkt ist, verbraucht diese Strategie keine CPU-Zeit für das Löschen anderer irrelevanter abgelaufener Schlüssel.

Der Nachteil der Lazy-Deletion-Strategie besteht darin, dass sie am wenigsten speicherschonend ist: Wenn ein Schlüssel abgelaufen ist und der Schlüssel noch in der Datenbank verbleibt, wird der von ihm belegte Speicher gelöscht, solange der abgelaufene Schlüssel nicht gelöscht wird nicht freigegeben.

Wenn bei Verwendung der Lazy-Deletion-Strategie viele abgelaufene Schlüssel in der Datenbank vorhanden sind und auf diese abgelaufenen Schlüssel nicht zugegriffen werden kann, werden sie möglicherweise nie gelöscht (es sei denn, der Benutzer führt FLUSHDB manuell aus). Dies ist sogar der Fall kann als Speicherverlust angesehen werden – nutzlose Datenmüll beanspruchen viel Speicher, aber der Server gibt sie nicht selbst frei. Dies ist bei einem Redis-Server, dessen Betriebsstatus stark vom Speicher abhängt, sicherlich nicht der Fall gute Nachrichten.

Bei einigen zeitbezogenen Daten, wie z. B. Protokollen, ist der Zugriff darauf ab einem bestimmten Zeitpunkt stark eingeschränkt oder es wird sogar nicht mehr darauf zugegriffen, wenn solche abgelaufenen Daten in großen Mengen in der Datenbank gespeichert sind , Der Benutzer glaubt, dass der Server sie automatisch gelöscht hat, aber tatsächlich sind diese Schlüssel noch vorhanden und der von den Schlüsseln belegte Speicher wurde nicht freigegeben, sodass die Konsequenzen sehr schwerwiegend sein müssen.

Regelmäßiges Löschen

Aus der obigen Diskussion des verzögerten Löschens geht hervor, dass diese Löschmethode bei alleiniger Verwendung offensichtliche Mängel aufweist:

Verzögertes Löschen verschwendet zu viel Speicher und riskiert Speicherverluste. Die periodische Löschstrategie ist eine Integration und ein Kompromiss der ersten beiden Strategien:

Die periodische Löschstrategie führt das Löschen abgelaufener Schlüssel in regelmäßigen Abständen durch und reduziert die Auswirkungen von Löschvorgängen auf die CPU-Zeit, indem sie die Dauer und Häufigkeit von Löschvorgängen begrenzt . Beeinflussen. Darüber hinaus reduziert die regelmäßige Löschstrategie durch das regelmäßige Löschen abgelaufener Schlüssel effektiv die durch abgelaufene Schlüssel verursachte Speicherverschwendung. Die Schwierigkeit der periodischen Löschstrategie besteht darin, die Dauer und Häufigkeit des Löschvorgangs zu bestimmen:

Wenn der Löschvorgang zu häufig ausgeführt wird oder die Ausführungszeit zu lang ist, degeneriert die periodische Löschstrategie zu einer geplanten Löschstrategie. Dies verbraucht zu viel CPU-Zeit. Es wird viel Zeit für das Löschen abgelaufener Schlüssel aufgewendet.

Wenn der Löschvorgang zu selten ausgeführt wird oder die Ausführungszeit zu kurz ist, ist die reguläre Löschstrategie dieselbe wie die verzögerte Löschstrategie, was zu einer Speicherverschwendung führt. Wenn daher eine reguläre Löschstrategie angewendet wird, muss der Server die Ausführungsdauer und Häufigkeit des Löschvorgangs entsprechend der Situation angemessen festlegen.

Lazy-Deletion-Strategie

Die Lazy-Deletion-Strategie abgelaufener Schlüssel wird durch die Funktion db.c/expireIfNeeded implementiert. Alle Redis-Befehle, die in die Datenbank lesen und schreiben, rufen die ExpireIfNeeded-Funktion auf, um den Eingabeschlüssel vor der Ausführung zu überprüfen:

Wenn der Eingabeschlüssel abgelaufen ist, entfernt die Funktion „expireIfNeeded“ den Eingabeschlüssel aus der Datenbank.

Wenn der Eingabeschlüssel nicht abgelaufen ist, wird die Funktion „expireIfNeeded“ keine Aktion ausführen.

Die Funktion „expireIfNeeded“ ist wie ein Filter, der abgelaufene Eingabetasten herausfiltern kann, bevor der Befehl tatsächlich ausgeführt wird, und so verhindert, dass der Befehl abgelaufene Tasten berührt.

Da außerdem jeder Schlüssel, auf den zugegriffen wird, von der Funktion „expireIfNeeded“ aufgrund des Ablaufs gelöscht werden kann, muss die Implementierungsfunktion jedes Befehls in der Lage sein, sowohl das Vorhandensein des Schlüssels als auch das Fehlen des Schlüssels zu verarbeiten:

Wenn der Schlüssel vorhanden ist , der Befehl wird entsprechend der Existenz des Schlüssels ausgeführt.

Wenn der Schlüssel nicht existiert oder der Schlüssel aufgrund des Ablaufs von der Funktion „expireIfNeeded“ gelöscht wird, wird der Befehl ausgeführt, als ob der Schlüssel nicht vorhanden wäre.

Implementierung der periodischen Löschstrategie

Die periodische Löschstrategie abgelaufener Schlüssel wird durch die Funktion redis.c/activeExpireCycle implementiert. Immer wenn die Funktion redis.c/serverCron für den periodischen Betrieb des Redis-Servers ausgeführt wird, wird die Funktion activeExpireCycle aufgerufen Durchlaufen Sie innerhalb eines bestimmten Zeitraums jede Datenbank auf dem Server mehrmals, überprüfen Sie nach dem Zufallsprinzip die Ablaufzeit einiger Schlüssel aus dem Ablaufwörterbuch der Datenbank und löschen Sie die abgelaufenen Schlüssel.

Der gesamte Prozess kann wie folgt in Pseudocode beschrieben werden

Der Arbeitsmodus der Funktion activeExpireCycle kann wie folgt zusammengefasst werden:

Jedes Mal, wenn die Funktion ausgeführt wird, nimmt sie eine bestimmte Anzahl von heraus Zufällige Schlüssel aus einer bestimmten Anzahl von Datenbanken prüfen und löschen.

Die globale Variable current_db zeichnet den Fortschritt der aktuellen ActiveExpireCycle-Funktionsprüfung auf und verarbeitet den vorherigen Fortschritt weiter, wenn die nächste ActiveExpireCycle-Funktion aufgerufen wird. Wenn beispielsweise die aktuelle Funktion „activeExpireCycle“ beim Durchlaufen der Datenbank Nr. 10 zurückkehrt, wird bei der nächsten Ausführung der Funktion „activeExpireCycle“ ab Datenbank Nr. 11 nach abgelaufenen Schlüsseln gesucht und diese gelöscht.

Während die Funktion „activeExpireCycle“ weiterhin ausgeführt wird, werden alle Datenbanken auf dem Server überprüft. Zu diesem Zeitpunkt setzt die Funktion die Variable „current_db“ auf 0 zurück und startet dann erneut eine neue Runde der Überprüfungsarbeit.

Wenn der Server im Replikationsmodus läuft, wird das Löschen abgelaufener Schlüssel vom Slave-Server vom Master-Server gesteuert:

Nach dem Löschen eines abgelaufenen Schlüssels sendet der Master-Server explizit einen DEL-Befehl an alle Slave-Server um zu informieren: Löschen Sie diesen abgelaufenen Schlüssel vom Server.

Wenn der Slave-Server den vom Client gesendeten Lesebefehl ausführt, löscht er den abgelaufenen Schlüssel nicht, sondern verarbeitet ihn wie einen nicht abgelaufenen Schlüssel erst gelöscht, nachdem der DEL-Befehl vom Server gesendet wurde.

Durch die Steuerung des Master-Servers, um abgelaufene Schlüssel einheitlich von den Slave-Servern zu löschen, kann die Konsistenz der Master-Slave-Server-Daten sichergestellt werden. Aus diesem Grund kann sichergestellt werden, dass in der Datenbank des Master-Servers noch ein abgelaufener Schlüssel vorhanden ist. Der abgelaufene Schlüssel ist Das Replikat auf dem Slave-Server bleibt ebenfalls bestehen. Beispielsweise gibt es ein Paar Master-Slave-Server, und ihre Datenbanken speichern alle die gleichen drei Schlüssel „message“, „xxx“ und „yyy“, wobei „message“ der abgelaufene Schlüssel ist, wie in der Abbildung dargestellt.

Wenn ein Client zu diesem Zeitpunkt die Befehls-GET-Nachricht an den Slave-Server sendet, stellt der Slave-Server fest, dass der Nachrichtenschlüssel abgelaufen ist, aber der Slave-Server löscht den Nachrichtenschlüssel nicht, sondern gibt ihn weiterhin zurück Wert des Nachrichtenschlüssels an den Client senden, als ob der Nachrichtenschlüssel nicht abgelaufen wäre

Angenommen, ein Client sendet danach den Befehl GET-Nachricht an den Hauptserver, dann findet der Hauptserver diesen Schlüssel Die Nachricht ist abgelaufen: Der Hauptserver löscht den Nachrichtenschlüssel und sendet ihn an den Client. Der Client gibt eine leere Antwort zurück und sendet einen DEL-Nachrichtenbefehl an den Slave-Server. Nach dem Empfang des DEL-Nachrichtenbefehls vom Master-Server wird der Slave-Server dies tun Löschen Sie außerdem den Nachrichtenschlüssel aus der Datenbank. Danach speichern sowohl der Master- als auch der Slave-Server keine abgelaufenen Schlüsselnachrichten mehr

Lernempfehlung:

Redis-Video-Tutorial

Das obige ist der detaillierte Inhalt vonErläuterung des Prinzips der Redis-Strategie zum Löschen abgelaufener Schlüssel. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!