Einführung in den Redis-Cache-Invalidierungsmechanismus

Die Geschichte des Redis-Cache-Fehlers beginnt mit dem Befehl EXPIRE, mit dem Benutzer eine Zeitüberschreitung für einen Schlüssel festlegen können. Wenn diese Zeit überschritten wird, wird der dem Schlüssel entsprechende Wert gelöscht Der Redis-Quellcode betrachtet Probleme im Zusammenhang mit Redis-Cache-Fehlern aus der Sicht eines Redis-Designers.

Redis-Cache-Ungültigmachungsmechanismus

Der Redis-Cache-Ungültigmachungsmechanismus ist für den Umgang mit einem sehr häufigen Szenario bei Caching-Anwendungen konzipiert. Lassen Sie uns über ein Szenario sprechen:

Um den Druck auf die Back-End-Datenbank zu verringern, haben wir gerne den Redis-Dienst genutzt, um die Daten, die sich nicht sehr häufig ändern, aus der DB-Last zu laden und in die zu laden Daher können wir innerhalb einer bestimmten Zeit Daten direkt aus dem Cache abrufen, hoffen jedoch, dass wir nach einer bestimmten Zeit die aktuellen Daten wieder aus der Datenbank laden.

Es wurde eine Frage aufgeworfen: Wie kann dieses Problem gelöst werden? Nun, wir sind mit den verfügbaren Sprachtools sehr vertraut und glauben fest daran, dass wir schnell eine solche Logik schreiben können: Wir zeichnen auf, wann wir das letzte Mal Daten aus der Datenbank geladen haben, und stellen dann jedes Mal fest, ob die Zeit abgelaufen ist Wir antworten auf den Dienst. Möchten Sie von der Datenbank neu laden ...? Natürlich ist diese Methode auch möglich. Als wir jedoch das Redis-Befehlsdokument überprüften, stellten wir fest, dass wir etwas getan hatten, was wir nicht tun mussten. Redis selbst bietet diesen Mechanismus einfach an:

EXPIRE key 30

Der obige Befehl legt eine Ablaufzeit von 30 Sekunden für den Schlüssel fest. Nach dieser Zeit sollten wir nicht mehr auf diesen Wert zugreifen können. Bisher haben wir ungefähr verstanden, was der Cache-Ungültigmachungsmechanismus ist Lassen Sie uns in einigen Anwendungsszenarien weiter auf dieses Problem eingehen. Wie wird der Redis-Cache-Ungültigmachungsmechanismus implementiert?

Verzögerter Ungültigmachungsmechanismus

Der verzögerte Ungültigkeitsmechanismus bedeutet, dass Redis die Gültigkeitsdauer des vom Kunden angeforderten Schlüssels überprüft, wenn der Client die Betätigung eines bestimmten Schlüssels anfordert. Wenn die entsprechende Verarbeitung erst nach Ablauf des Schlüssels durchgeführt wird, wird der verzögerte Fehlermechanismus auch als passiver Fehlermechanismus bezeichnet. Werfen wir einen Blick auf den serverseitigen Ausführungsstapel für die Get-Anforderungsverarbeitung unter der t_string-Komponente:

getCommand 
     -> getGenericCommand 
            -> lookupKeyReadOrReply 
                   -> lookupKeyRead 
                         -> expireIfNeeded

Der entscheidende Punkt ist ExpireIfNeed. Bevor Redis den Schlüssel erhält, ermittelt es, ob der mit dem Schlüssel verknüpfte Wert vorhanden ist Ungültig. Fügen Sie es zuerst hier ein. Schauen wir uns an, wie der tatsächliche Ort zum Speichern von Werten in Redis aussieht:

typedef struct redisDb {
    dict *dict;                 /* The keyspace for this DB */
    dict *expires;              /* Timeout of keys with a timeout set */
    dict *blocking_keys;        /* Keys with clients waiting for data (BLPOP) */
    dict *ready_keys;           /* Blocked keys that received a PUSH */
    dict *watched_keys;         /* WATCHED keys for MULTI/EXEC CAS */
    int id;    long long avg_ttl;          /* Average TTL, just for stats */} redisDb;

Das Obige ist eine in Redis definierte Struktur Von Redis implementiert, d. Wenn wir den Set-Schlüssel „hahaha“ ausführen, werden die Daten in dict gespeichert.

expires wird zum Speichern von Schlüsseln verwendet, die der Ablaufzeit zugeordnet sind. Wenn wir beispielsweise den Ablaufschlüssel 1 basierend auf dem oben Gesagten ausführen, wird ein Datensatz hinzugefügt, der zu diesem Zeitpunkt abläuft.

Rückblickend sieht der Prozess von „expireIfNeeded“ ungefähr wie folgt aus:

Ermitteln Sie die Ablaufzeit des Schlüssels von „expires“. Wenn er nicht vorhanden ist, bedeutet dies, dass der entsprechende Schlüssel nicht vorhanden ist Es ist eine Ablaufzeit festgelegt und die Rückgabe erfolgt direkt.

Wenn es sich um eine Slave-Maschine handelt, wird sie direkt zurückgegeben, da Redis zur Gewährleistung der Datenkonsistenz und einer einfachen Implementierung die Initiative zur Cache-Ungültigmachung an die Master-Maschine übergibt und die Slave-Maschine nicht über diese verfügt Befugnis, den Schlüssel ungültig zu machen.

Wenn es derzeit die Master-Maschine ist und der Schlüssel abläuft, führt der Master zwei wichtige Dinge aus: 1) Schreiben Sie den Löschbefehl in die AOF-Datei. 2) Benachrichtigen Sie den Slave, dass der aktuelle Schlüssel ungültig ist und gelöscht werden kann.

Master löscht den Wert von key aus dem lokalen Wörterbuch.

Aktiver Ungültigkeitsmechanismus

Der aktive Ungültigkeitsmechanismus wird auch als aktiver Ungültigkeitsmechanismus bezeichnet, dh der Server überprüft regelmäßig den ungültigen Cache und führt entsprechende Vorgänge aus, wenn er fehlschlägt .

Wir alle wissen, dass Redis Single-Threaded und ereignisgesteuert ist. Es gibt einen EventLoop, der für die Verarbeitung von zwei Arten von Ereignissen verantwortlich ist:

Ein Typ sind IO-Ereignisse Art des Ereignisses Es ist vom zugrunde liegenden Multiplexer getrennt.

Der erste Typ sind geplante Ereignisse, die hauptsächlich für die geplante Ausführung einer bestimmten Aufgabe verwendet werden.

Es scheint, dass die EventLoop-Funktion von Redis in etwa der EventLoop-Funktion von Netty und JavaScript ähnelt. Einerseits verarbeitet sie Netzwerk-E/A-Ereignisse, andererseits kann sie auch einige davon kleine Aufgaben.

Warum sprechen wir über das Single-Threaded-Modell von Redis? Weil die aktive Fehlermechanismuslogik von Redis als geplante Aufgabe behandelt und vom Hauptthread ausgeführt wird:

if(aeCreateTimeEvent(server.el, 1, serverCron, NULL, NULL) == AE_ERR) {
        redisPanic("Can't create the serverCron time event.");        
       exit(1);
    }

serverCron ist dieses Timing Der Funktionszeiger der Aufgabe, adCreateTimeEvent registriert die serverCron-Aufgabe bei EventLoop und setzt die anfängliche Ausführungszeit auf 1 Millisekunde später. Als nächstes ist alles, was wir wissen wollen, in serverCron. serverCron kümmert sich nur um die Teile, die sich auf diesen Artikel beziehen, das heißt, wie die Cache-Invalidierung implementiert wird, je nachdem, was der Code tut:

aeProcessEvents
    ->processTimeEvents
        ->serverCron 
             -> databasesCron 
                   -> activeExpireCycle 
                           -> activeExpireCycleTryExpire

EventLoop Durch die Verarbeitung geplanter Aufgaben wird die Ausführung der ServerCron-Logik ausgelöst und schließlich die Logik der Schlüsselablaufverarbeitung ausgeführt. Es ist erwähnenswert, dass die ActiveExpireCycle-Logik nur vom Master ausgeführt werden kann.

Weitere Redis-Kenntnisse finden Sie in der Spalte Redis-Einführungs-Tutorial.

Das obige ist der detaillierte Inhalt vonEinführung in den Redis-Cache-Invalidierungsmechanismus. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!