Objekte, die mit Redis-Instanzen interagieren, und Vorgänge, die während der Interaktion auftreten:
Client: Netzwerk-E/A, Hinzufügen von Schlüssel-Wert-Paaren, Lösch-, Änderungs- und Abfragevorgänge, Datenbankvorgänge;
Disk: RDB-Snapshots generieren, AOF-Protokolle aufzeichnen und AOF-Protokolle neu schreiben;
Master-Slave-Knoten: Die Master-Bibliothek generiert und überträgt RDB-Dateien, die Slave-Bibliothek empfängt RDB-Dateien, löscht die Datenbank und lädt RDB-Dateien ;
Cluster-Instanzen aufteilen: Hash-Slot-Informationen an andere Instanzen übertragen und Daten migrieren.
Blockierungspunkte bei der Interaktion mit Clients:
Netzwerk-IO ist manchmal langsam, aber Redis verwendet IO-Mehrkanal-Wiederverwendungsmechanismen, die den Hauptmechanismus verhindern Dadurch wird verhindert, dass der Thread immer auf das Eintreffen von Netzwerkverbindungen oder -anforderungen wartet, sodass Netzwerk-E/A kein Faktor ist, der dazu führt, dass Redis blockiert. Die Hauptaufgabe des Redis-Hauptthreads besteht darin, die Operationen zum Hinzufügen, Löschen, Ändern und Abfragen von Schlüssel-Wert-Paaren durchzuführen, die mit dem Client interagieren. Hochkomplexe Vorgänge zum Hinzufügen, Löschen, Ändern und Abfragen werden Redis definitiv blockieren.
Der Standard zur Beurteilung der Komplexität einer Operation: Sehen Sie, ob die
Komplexität der Operation O(N)ist. Der erste Blockierungspunkt von Redis: vollständige Sammlungsabfrage und Aggregationsvorgang:
Die Komplexität von Vorgängen mit Sammlungen in Redis beträgt normalerweise O (N), daher müssen Sie bei der Verwendung darauf achten.
Zum Beispiel Mengenelemente,vollständige Abfrage, Operationen HGETALL, SMEMBERS und Aggregationsstatistiken, Operationen von Mengen wie Schnittmenge, Vereinigung und Differenz.
Der zweite Blockierungspunkt von Redis: Bigkey-LöschvorgangDer Löschvorgang der Sammlung selbst birgt auch potenzielle Blockierungsrisiken. Der Kern des Löschvorgangs besteht darin, den vom Schlüssel-Wert-Paar belegten Speicherplatz freizugeben. Das Freigeben von Speicher ist nur der erste Schritt, um den Speicherplatz effizienter zu verwalten. Wenn eine Anwendung Speicher freigibt, muss das Betriebssystem den freigegebenen Speicherblock in eine verknüpfte Liste freier Speicherblöcke für die anschließende Verwaltung und Neuzuweisung einfügen.
Drei Schlussfolgerungen werden gezogen:
Wenn die Anzahl der Elemente von 100.000 auf 1 Million steigt, nimmt das Löschen von 4 Hauptsammlungstypen zu. Die Zeit nimmt zu hat sich vom 5-fachen auf fast das 20-fache erhöht.
Je größer die Menge der Elemente, desto länger dauert das Löschen.das Erstellen und Übertragen von RDB-Dateien durch untergeordnete Prozesse abgeschlossen
und der Hauptthread wird nicht blockiert.Aber nach dem Empfang der RDB-Datei muss die Slave-Bibliothek den Befehl FLUSHDB verwenden, um die aktuelle Datenbank zu löschen, was zufällig den dritten Blockierungspunkt erreicht.
Nach dem Löschen der aktuellen Datenbank muss die Slave-Bibliothek die RDB-Datei in den Speicher laden. Die Geschwindigkeit dieses Vorgangs hängt eng mit der Größe der RDB-Datei zusammen. Je größer die RDB-Datei, desto langsamer ist der Ladevorgang.
Bei der Bereitstellung eines Redis-Slicing-Clusters müssen die jeder Redis-Instanz zugewiesenen Hash-Slot-Informationen zwischen verschiedenen Instanzen übertragen werden, wenn Lastausgleich erforderlich ist oder Instanzen hinzugefügt oder gelöscht werden , werden Daten zwischen verschiedenen Instanzen migriert. Die Informationsmenge im Hash-Slot ist jedoch nicht groß und die Datenmigration erfolgt inkrementell. Bei diesen beiden Arten von Vorgängen besteht nur ein geringes Risiko, dass der Redis-Hauptthread blockiert wird.
Wenn die Redis-Cluster-Lösung verwendet und gleichzeitig bigkey migriert wird, wird der Hauptthread blockiert, da Redis-Cluster eine synchrone Migration verwendet.
Fünf Blockierungspunkte:
Vollständige Abfrage- und Aggregationsvorgänge festlegen;
Löschen der Datenbank;
AOF-Protokollsynchronisierung;
Aus der Bibliothek laden RDB-Datei.
2. Blockierungspunkte, die asynchron ausgeführt werden können
Anforderungen für die asynchrone Ausführung von Operationen:
Eine Operation, die asynchron ausgeführt werden kann, ist keine Operation auf dem kritischen Pfad des Redis-Hauptthreads (der Client sendet die Anfrage an Redis und wartet darauf, dass Redis das Datenergebnis zurückgibt).
Nachdem der Haupt-Thread Operation 1 empfangen hat, muss Operation 1 keine bestimmten Daten an den Client zurückgeben. Der Haupt-Thread kann sie zur Fertigstellung an den Hintergrund-Sub-Thread übergeben, und zwar nur muss ein „OK“-Ergebnis an den Client zurückgeben.Wenn der untergeordnete Thread Operation 1 ausführt, sendet der Client Operation 2 an die Redis-Instanz. Der Client muss das von Operation 2 zurückgegebene Datenergebnis verwenden. Wenn Operation 2 kein Ergebnis zurückgibt, befindet sich der Client immer im Wartezustand .
Operation 1 gilt nicht als Operation auf dem kritischen Pfad, da keine spezifischen Daten an den Client zurückgegeben werden müssen und daher vom Hintergrund-Subthread asynchron ausgeführt werden kann.Operation 2 muss das Ergebnis an den Client zurückgeben. Es handelt sich um eine Operation auf dem kritischen Pfad, daher muss der Hauptthread diese Operation sofort abschließen.
Der Redis-Lesevorgang ist ein typischer Vorgang für den kritischen Pfad, da der Client nach dem Senden des Lesevorgangs auf die Rückgabe der gelesenen Daten zur anschließenden Datenverarbeitung wartet. Der erste Blockierungspunkt von Redis, „Sammlung, vollständige Abfrage und Aggregationsvorgang“, umfasst beide Lesevorgänge, und asynchrone Vorgänge können nicht ausgeführt werden.
Löschvorgänge, die keine Rückgabe bestimmter Datenergebnisse an den Client erfordern, sind keine kritischen Pfadvorgänge. „Sowohl ‚Bigkey-Löschung‘ als auch ‚Datenbankfreigabe‘ beinhalten das Löschen von Daten, befinden sich jedoch nicht auf dem kritischen Pfad.“ Sie können Hintergrund-Subthreads verwenden, um Löschvorgänge asynchron durchzuführen.
„synchrones Schreiben des AOF-Protokolls“, um die Datenzuverlässigkeit sicherzustellen, muss die Redis-Instanz sicherstellen, dass die Vorgangsdatensätze im AOF-Protokoll auf die Festplatte geschrieben wurden. Obwohl dieser Vorgang ein Warten der Instanz erfordert, ist dies nicht der Fall Geben Sie bestimmte Datenergebnisse an die Instanz zurück. Daher kann ein untergeordneter Thread gestartet werden, um das AOF-Protokoll synchron zu schreiben.
Um Kunden Datenzugriffsdienste bereitzustellen, muss die vollständige RDB-Datei geladen werden. Diese Operation ist ebenfalls eine Operation auf dem kritischen Pfad und muss vom Hauptthread der Slave-Bibliothek ausgeführt werden.
Mit Ausnahme von „Sammlung vollständiger Abfrage- und Aggregationsvorgänge“ und „Laden von RDB-Dateien aus der Bibliothek“ liegen die an den anderen drei Blockierungspunkten beteiligten Vorgänge nicht auf dem kritischen Pfad. Sie können den asynchronen Sub-Thread-Mechanismus von Redis verwenden Erreichen Sie das Löschen und Löschen von Bigkeys. Die Datenbank und das AOF-Protokoll werden synchron geschrieben.
Nachdem der Redis-Hauptthread gestartet wurde, verwendet er die vom Betriebssystem bereitgestellte Funktion pthread_create, um drei Sub-Threads zu erstellen, die für die asynchrone Ausführung von
AOF-Protokollschreibvorgängen verantwortlich sind Löschen von Wertpaaren und Schließen von DateienDer Hauptthread interagiert mit den untergeordneten Threads über eine Aufgabenwarteschlange in Form einer verknüpften Liste. Wenn der Hauptthread den Vorgang zum Löschen des Schlüssel-Wert-Paares und zum Löschen der Datenbank empfängt, kapselt er den Vorgang in eine Aufgabe, stellt ihn in die Aufgabenwarteschlange und gibt dann eine Abschlussmeldung an den Client zurück, die den Löschvorgang anzeigt ist abgeschlossen.
Aber tatsächlich wurde der Löschvorgang zu diesem Zeitpunkt noch nicht ausgeführt. Nachdem der Hintergrund-Subthread die Aufgabe aus der Aufgabenwarteschlange gelesen hat, beginnt er, die Schlüssel-Wert-Paare tatsächlich zu löschen und den entsprechenden Speicherplatz freizugeben. Dieses asynchrone Löschen wird auch „Lazy Deletion“ (Lazy Free) genannt.
Wenn das AOF-Protokoll mit der Option everysec konfiguriert ist, kapselt der Hauptthread den AOF-Protokollschreibvorgang in eine Aufgabe und stellt sie in die Aufgabenwarteschlange. Eine Möglichkeit, es umzuschreiben, ist: Wenn der Hintergrund-Sub-Thread die Aufgabe liest, beginnt er selbst mit der Aufzeichnung im AOF-Protokoll, und der Haupt-Thread kann weiterlaufen, ohne auf das AOF-Protokoll angewiesen zu sein.
Asynchroner Sub-Thread-Ausführungsmechanismus in Redis:
Asynchrone Vorgänge zum Löschen von Schlüssel-Wert-Paaren und zum Löschen von Datenbanken sind Funktionen, die nach Redis 4.0 bereitgestellt werden. Redis bietet außerdem neue Befehle zum Ausführen dieser beiden Vorgänge:
Löschung von Schlüssel-Wert-Paaren: Der Sammlungstyp enthält eine große Anzahl von Elementen (z. B. wenn Millionen oder Dutzende Millionen Elemente gelöscht werden müssen), wird empfohlen, den Befehl UNLINK zu verwenden.
Datenbank löschen: Sie können die Option ASYNC nach den Befehlen FLUSHDB und FLUSHALL hinzufügen Lassen Sie den Hintergrund-Subthread die Datenbank asynchron löschen.
FLUSHDB ASYNC FLUSHALL AYSNC
Das obige ist der detaillierte Inhalt vonWas ist der asynchrone Mechanismus von Redis?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!