Eine Zusammenfassung von mehr als 20 wichtigen Redis-Interviewfragen. Kommen Sie und sammeln Sie sie! !

In diesem Artikel werden einige Redis-Interviewfragen mit Ihnen geteilt, damit Sie nach Lücken suchen und Ihr Wissen verbessern können. Es hat einen gewissen Referenzwert. Freunde in Not können sich darauf beziehen. Ich hoffe, es wird für alle hilfreich sein.

Anwendungsszenarien

• Cache

• Gemeinsame Sitzung

• Nachrichtenwarteschlangensystem

• Verteilte Sperre

Verwandte Empfehlung: Redis-Video-Tutorial

einzelnes Warum ist Threaded Redis schnell

• Reiner Speicherbetrieb

• Einzelthread-Betrieb, der häufige Kontextwechsel vermeidet

• Angemessene und effiziente Datenstruktur

• Verwendung eines nicht blockierenden E/A-Multiplexmechanismus (eine Datei). Der Deskriptor überwacht mehrere Dateideskriptoren gleichzeitig auf Dateneingang.) sind vom String-Typ, und mehrere andere Datenstrukturen basieren auf dem String-Typ. Der häufig verwendete Befehl zum Festlegen des Schlüsselwerts ist String. Wird häufig beim Caching, Zählen, bei gemeinsam genutzten Sitzungen, bei der Ratenbegrenzung usw. verwendet.

Hash: In Redis bezieht sich der Hash-Typ auf den Schlüsselwert selbst, bei dem es sich um eine Schlüssel-Wert-Paar-Struktur handelt. Hash kann zum Speichern von Benutzerinformationen verwendet werden, beispielsweise zur Implementierung eines Warenkorbs.

Liste (doppelt verknüpfte Liste): Der Listentyp (Listentyp) wird zum Speichern mehrerer geordneter Zeichenfolgen verwendet. Kann eine einfache Nachrichtenwarteschlangenfunktion ausführen.
Set: Der Set-Typ wird auch zum Speichern mehrerer Zeichenfolgenelemente verwendet, aber im Gegensatz zum Listentyp sind doppelte Elemente im Set nicht zulässig und die Elemente im Set sind ungeordnet. Elemente können nicht per Indexindex abgerufen werden. Mithilfe der Schnitt-, Vereinigungs-, Differenz- und anderen Operationen von Set können Sie allgemeine Präferenzen, alle Präferenzen, Ihre eigenen einzigartigen Präferenzen und andere Funktionen berechnen.
Sorted Set (Sprunglistenimplementierung): Sorted Set verfügt über einen zusätzlichen Gewichtsparameter Score, und die Elemente im Set können nach Score angeordnet werden. Es kann als Ranking-Anwendung zur Durchführung von TOP N-Operationen verwendet werden.
• Die Datenablaufstrategie von Redis

Die Datenablaufstrategie in Redis übernimmt die Strategie
• reguläres Löschen + verzögertes Löschen

Regelmäßige Löschstrategie: Redis ermöglicht einem Timer, alle Schlüssel regelmäßig zu überwachen, um festzustellen, ob der Schlüssel vorhanden ist abgelaufen. Löschen Sie es, wenn es abläuft. Diese Strategie kann sicherstellen, dass abgelaufene Schlüssel irgendwann gelöscht werden, weist jedoch auch schwerwiegende Mängel auf: Sie durchläuft jedes Mal alle Daten im Speicher, was viele CPU-Ressourcen verbraucht, wenn der Schlüssel abgelaufen ist, der Timer jedoch noch läuft Der Schlüssel kann während dieser Zeit weiterhin verwendet werden.

Strategie zum verzögerten Löschen: Wenn Sie den Schlüssel erhalten, stellen Sie zunächst fest, ob der Schlüssel abgelaufen ist, und löschen Sie ihn, wenn er abläuft. Diese Methode hat einen Nachteil: Wenn der Schlüssel nicht verwendet wird, bleibt er immer im Speicher. Tatsächlich ist er abgelaufen, was viel Platz verschwendet.

Diese beiden Strategien ergänzen sich natürlich. Nach der Kombination hat die geplante Löschstrategie einige Änderungen erfahren. Sie scannt nicht mehr jedes Mal alle Schlüssel, sondern wählt zufällig einen Teil der Schlüssel zur Überprüfung aus, was das Risiko verringert Der Verbrauch von CPU-Ressourcen und die Lazy-Deletion-Strategie ergänzen die ungeprüften Schlüssel und erfüllen grundsätzlich alle Anforderungen. Aber manchmal ist es so ein Zufall, dass sie weder vom Timer extrahiert noch verwendet werden. Wie verschwinden diese Daten aus dem Speicher? Es spielt keine Rolle, es gibt auch einen Speichereliminierungsmechanismus. Wenn der Speicher nicht ausreicht, kommt der Speichereliminierungsmechanismus ins Spiel. Die Eliminierungsstrategie ist unterteilt in: Wenn der Speicher nicht ausreicht, um die neu geschriebenen Daten aufzunehmen, meldet der neue Schreibvorgang einen Fehler. (Redis-Standardrichtlinie) Wenn der Speicher nicht ausreicht, um neu geschriebene Daten aufzunehmen, entfernen Sie im Schlüsselbereich den zuletzt verwendeten Schlüssel. (LRU empfohlen) Wenn der Speicher nicht ausreicht, um neu geschriebene Daten aufzunehmen, wird ein Schlüssel nach dem Zufallsprinzip aus dem Schlüsselraum entfernt. Wenn der Speicher nicht ausreicht, um neu geschriebene Daten aufzunehmen, wird im Schlüsselraum mit festgelegter Ablaufzeit der am längsten verwendete Schlüssel entfernt. Diese Situation kommt im Allgemeinen vor, wenn Redis sowohl als Cache als auch als persistenter Speicher verwendet wird. Wenn der Speicher nicht ausreicht, um neu geschriebene Daten aufzunehmen, wird ein Schlüssel nach dem Zufallsprinzip mit einer festgelegten Ablaufzeit aus dem Schlüsselraum entfernt. Wenn der Speicher nicht ausreicht, um neu geschriebene Daten aufzunehmen, wird im Schlüsselraum mit festgelegter Ablaufzeit zuerst der Schlüssel mit einer früheren Ablaufzeit entfernt.

Redis set und setnx

setnx in Redis unterstützt das Festlegen der Ablaufzeit nicht. Wenn Sie bei verteilten Sperren einen Deadlock vermeiden möchten, der durch eine bestimmte Client-Unterbrechung verursacht wird, müssen Sie die Ablaufzeit der Sperre festlegen. Bei hoher Parallelität können setnx und Expire keine atomaren Operationen implementieren. Wenn Sie es verwenden möchten, müssen Sie es explizit im Programmcode sperren. Die Verwendung von SET anstelle von SETNX ist gleichbedeutend damit, dass SETNX+EXPIRE Atomizität erreicht. Es besteht kein Grund zur Sorge, dass SETNX erfolgreich ist und EXPIRE fehlschlägt.

Redis' spezifische LRU-Implementierung:

Die herkömmliche LRU verwendet einen Stapel und verschiebt jedes Mal die zuletzt verwendeten Daten an die Spitze des Stapels. Die Verwendung des Stapels führt jedoch dazu, dass eine große Menge nicht heißer Daten anfällt Besetzt den Kopf beim Ausführen von select * data und muss daher verbessert werden. Jedes Mal, wenn Redis einen Wert per Schlüssel erhält, aktualisiert es das LRU-Feld im Wert auf den aktuellen Zeitstempel der zweiten Ebene. Der anfängliche Implementierungsalgorithmus von Redis ist sehr einfach. Fünf Schlüssel werden zufällig aus dem Diktat entnommen und der Schlüssel mit dem kleinsten LRU-Feldwert wird eliminiert. In 3.0 wurde eine weitere Version des Algorithmus verbessert. Zunächst wird der erste zufällig ausgewählte Schlüssel in einen Pool gelegt (die Größe des Pools beträgt 16). Die Schlüssel im Pool sind in der Reihenfolge ihrer LRU-Größe angeordnet. Als nächstes muss jeder zufällig ausgewählte Keylru-Wert kleiner als der kleinste LRU im Pool sein, bevor er weiter hinzugefügt wird, bis der Pool voll ist. Nachdem er voll ist, muss jedes Mal, wenn ein neuer Schlüssel eingesteckt werden muss, der Schlüssel mit der größten LRU im Pool herausgenommen werden. Wählen Sie beim Eliminieren direkt einen minimalen LRU-Wert aus dem Pool aus und eliminieren Sie ihn.

Wie Redis Hotspot-Schlüssel entdeckt

• Erfahrung nutzen, um Vorhersagen zu treffen: Wenn Sie beispielsweise den Beginn einer Aktivität im Voraus kennen, dann verwenden Sie diesen Schlüssel als Hotspot-Schlüssel.

• Serverseitige Erfassung: Fügen Sie vor dem Betrieb von Redis eine Codezeile für die Datenstatistik hinzu.

• Pakete zur Auswertung erfassen: Redis verwendet das TCP-Protokoll zur Kommunikation mit dem Client. Das Kommunikationsprotokoll verwendet RESP, sodass Sie Pakete auch zur Analyse abfangen können, indem Sie Ihr eigenes Programm zur Überwachung des Ports schreiben.

• Auf der Proxy-Ebene wird jede Redis-Anfrage gesammelt und gemeldet.

• Redis wird mit einer Befehlsabfrage geliefert: Die Version Redis 4.0.4 bietet redis-cli –hotkeys, um Hotkeys zu finden. (Wenn Sie den integrierten Befehl von Redis zum Abfragen verwenden möchten, beachten Sie bitte, dass Sie zuerst die Speicherräumungsrichtlinie auf allkeys-lfu oder volatile-lfu festlegen müssen, da sonst ein Fehler zurückgegeben wird. Geben Sie Redis ein und verwenden Sie den Konfigurationssatz maxmemory-policy allkeys-lfu. )

Redis‘ Hotspot-Schlüssellösung

• Serverseitiges Caching: Zwischenspeichern von Hotspot-Daten im Speicher des Servers (Verwenden Sie den Redis-eigenen Nachrichtenbenachrichtigungsmechanismus, um die Daten von Konsistenz von Redis und serverseitigen Hotspot-Schlüsseln: Wenn der Hotspot-Schlüssel aktualisiert wird, aktualisiert der Server ihn auch.

• Backup des Hotspot-Schlüssels: Die Zufallszahl wird zufällig an andere Redis-Knoten verteilt. Auf diese Weise treffen sie beim Zugriff auf den Hotspot-Schlüssel nicht alle auf einen Computer.

So lösen Sie das Redis-Cache-Lawinenproblem

• Verwenden Sie die Redis-Hochverfügbarkeitsarchitektur: Verwenden Sie den Redis-Cluster, um sicherzustellen, dass der Redis-Dienst nicht hängen bleibt. Die Cache-Zeit ist inkonsistent. Fügen Sie einen Cache hinzu Ablaufzeit Zufällige Werte, um kollektive Fehler zu vermeiden

• Aktuelle Begrenzungs-Downgrade-Strategie: Es gibt bestimmte Einreichungen. Wenn der personalisierte Empfehlungsdienst beispielsweise nicht verfügbar ist, ersetzen Sie ihn durch einen Hotspot-Datenempfehlungsdienst

• Anleitung Lösen Sie das Problem der Redis-Cache-Penetration.

Überprüfen Sie die Schnittstelle Zuerst filtern: Stellen Sie beim Abfragen zunächst fest, ob der Schlüssel im Bloom-Filter vorhanden ist, und führen Sie ihn dann weiter nach unten aus, wenn er nicht vorhanden ist. Der Bloom-Filter speichert den Wert in mehreren Hash-Bits. Wenn der Bloom-Filter angibt, dass ein bestimmtes Element vorhanden ist, kann es zu einer Fehleinschätzung kommen. Wenn der Bloom-Filter sagt, dass ein Element nicht vorhanden ist, darf es nicht vorhanden sein.

• Persistenzmechanismus von Redis

• Um die Effizienz sicherzustellen, speichert Redis Daten im Speicher zwischen, schreibt jedoch regelmäßig aktualisierte Daten auf die Festplatte oder schreibt Änderungsvorgänge in zusätzliche Datensatzdateien, um die Datenpersistenz sicherzustellen. Es gibt zwei Persistenzstrategien für Redis:

• RDB: Das Snapshot-Formular besteht darin, die Daten im Speicher direkt in einer Dump-Datei zu speichern, sie regelmäßig zu speichern und die Strategie zu speichern. Wenn Redis beibehalten werden muss, teilt Redis einen untergeordneten Prozess auf und der untergeordnete Prozess schreibt die Daten in eine temporäre RDB-Datei auf der Festplatte. Wenn der untergeordnete Prozess das Schreiben der temporären Datei abgeschlossen hat, ersetzen Sie die ursprüngliche RDB.

• AOF: Speichern Sie alle Befehle zum Ändern des Redis-Servers in einer Datei, einer Sammlung von Befehlen.

Verwenden Sie AOF für die Persistenz. Jeder Schreibbefehl wird über die Schreibfunktion an appendonly.aof angehängt. Die Standardrichtlinie von aof besteht darin, einmal pro Sekunde zu fsyncen, selbst wenn ein Fehler auftritt, gehen Daten bis zu einer Sekunde verloren. Der Nachteil besteht darin, dass für denselben Datensatz die Dateigröße von AOF normalerweise größer ist als die Größe von RDB-Dateien. Abhängig von der verwendeten fsync-Strategie ist AOF möglicherweise langsamer als RDB. Redis verwendet standardmäßig die Persistenzmethode von Snapshot RDB. Bei der Master-Slave-Synchronisierung wird die vollständige Synchronisierung (RDB) durchgeführt, wenn die Master-Slave-Verbindung gerade hergestellt ist. Nach Abschluss der vollständigen Synchronisierung wird die inkrementelle Synchronisierung (AOF) durchgeführt.

Redis-Transaktionen

• Das Wesentliche einer Redis-Transaktion ist eine Reihe von Befehlen. Transaktionen unterstützen die gleichzeitige Ausführung mehrerer Befehle und alle Befehle in einer Transaktion werden serialisiert. Während des Transaktionsausführungsprozesses werden die Befehle in der Warteschlange serialisiert und der Reihe nach ausgeführt, und von anderen Clients übermittelte Befehlsanforderungen werden nicht in die Befehlssequenz für die Transaktionsausführung eingefügt. Zusammenfassend lässt sich sagen: Eine Redis-Transaktion ist eine einmalige, sequentielle und exklusive Ausführung einer Reihe von Befehlen in einer Warteschlange.

• Redis-Transaktionen verfügen nicht über das Konzept der Isolationsstufe. Der Stapelvorgang wird vor dem Senden des EXEC-Befehls in den Warteschlangencache gestellt und daher nicht tatsächlich ausgeführt der Transaktion. Außerhalb der Transaktion ist die Abfrage nicht sichtbar.

• In Redis wird ein einzelner Befehl atomar ausgeführt, es ist jedoch nicht garantiert, dass Transaktionen atomar sind und es gibt kein Rollback. Wenn ein Befehl in der Transaktion nicht ausgeführt werden kann, werden die verbleibenden Befehle trotzdem ausgeführt.

Redis-Transaktionsbezogene Befehle

• watch key1 key2 ... : Überwachen Sie einen oder mehrere Schlüssel, bevor die Transaktion ausgeführt wird, wird die Transaktion unterbrochen (ähnlich wie Optimistische Sperre)

• multi: Markiert den Beginn eines Transaktionsblocks (in der Warteschlange)

• exec: Führen Sie die Befehle aller Transaktionsblöcke aus (sobald exec ausgeführt wird, werden die zuvor hinzugefügten Überwachungssperren aufgehoben)

• verwerfen: Transaktion abbrechen, alle Befehle im Transaktionsblock verwerfen.

• unwatch: Überwachung aller Schlüssel durch Watch abbrechen Speichern Sie alle Daten im Speicher, es bleibt nach einem Stromausfall hängen und die Daten dürfen die Speichergröße nicht überschreiten. Einige Daten in Redis werden auf der Festplatte gespeichert, was die Haltbarkeit der Daten gewährleistet.

In Bezug auf Datenunterstützungstypen: Memcache bietet einfache Unterstützung für Datentypen und unterstützt nur einfache Schlüsselwerte, während Redis fünf Datentypen unterstützt.

Die zugrunde liegenden Modelle sind unterschiedlich: Ihre zugrunde liegenden Implementierungsmethoden und Anwendungsprotokolle für die Kommunikation mit Kunden sind unterschiedlich. Redis hat direkt einen eigenen VM-Mechanismus erstellt, denn wenn das allgemeine System Systemfunktionen aufruft, verschwendet es eine gewisse Zeit für das Verschieben und Anfordern.
Wertgröße: Redis kann 1 GB erreichen, während Memcache nur 1 MB beträgt.
• Mehrere Cluster-Modi von Redis

Sentinel ist ein verteiltes System, basierend auf Bei der Master-Slave-Replikation können Sie mehrere Sentinel-Prozesse in einer Architektur ausführen. Diese Prozesse verwenden das Gerüchteprotokoll, um Informationen darüber zu erhalten, ob der Master offline ist, und verwenden das Abstimmungsprotokoll, um zu entscheiden, ob ein automatisches Failover durchgeführt werden soll und welcher Slave ausgewählt werden soll der neue Meister.

• Jeder Wachposten sendet regelmäßig Nachrichten an andere Wachposten, Master und Slaves, um zu bestätigen, ob die andere Partei am Leben ist. Wenn festgestellt wird, dass die andere Partei nicht innerhalb der angegebenen Zeit (konfigurierbar) geantwortet hat, wird dies vorübergehend berücksichtigt tot sein (der sogenannte „subjektive Glaube, dass die Maschine ausgefallen ist“).

Wenn die meisten Sentinels in der „Sentinel Group“ melden, dass ein bestimmter Master nicht antwortet, betrachtet das System den Master durch einen bestimmten Abstimmungsalgorithmus als „völlig tot“ (d. h. objektiv als echte Ausfallmaschine). Das System wählt aus den verbleibenden Slave-Knoten einen aus, der zum Master befördert werden soll, und ändert dann automatisch die relevanten Konfigurationen.

Rehash-Vorgang von Redis

Der Rehash-Vorgang von Redis wird nicht auf einmalige und zentrale Weise abgeschlossen, sondern in mehreren, progressiven Schritten. Redis verwaltet eine Indexzählervariable rehashidx, um den Fortschritt des Rehash anzuzeigen.

• Dieses progressive Rehash vermeidet die enorme Menge an Berechnungen und Speicheroperationen, die durch das zentralisierte Rehash verursacht werden. Es ist jedoch zu beachten, dass normale Zugriffsanforderungen beim Rehash von Redis möglicherweise zweimal auf die Hashtabelle zugreifen müssen (ht[0], ht[1]). Wenn der Schlüsselwert beispielsweise auf neue ht1 umgeleitet wird, müssen Sie zuerst auf ht0 zugreifen. Wenn er in ht0 nicht gefunden werden kann, gehen Sie zu ht1, um ihn zu finden.

  Bedingungen für die Erweiterung der Redis-Hash-Tabelle

  • Die Anzahl der in der Hash-Tabelle gespeicherten Schlüssel übersteigt die Größe der Hash-Tabelle.

  • Der Redis-Server führt derzeit den BGSAVE-Befehl (rdb.) nicht aus ) oder den BGREWRITEAOF-Befehl und der Auslastungsfaktor der Hash-Tabelle ist größer oder gleich 1.

  • Der Redis-Server führt derzeit den BGSAVE-Befehl (rdb) oder den BGREWRITEAOF-Befehl und den Auslastungsfaktor der Hash-Tabelle aus ist größer oder gleich 5. (Ladefaktor = gespeicherte Hash-Tabelle Anzahl der Knoten/Hash-Tabellengröße. Wenn der Ladefaktor der Hash-Tabelle kleiner als 0,1 ist, führen Sie einen Verkleinerungsvorgang für die Hash-Tabelle durch.)

  Lösung für den gleichzeitigen Redis-Wettbewerbsschlüssel

  • Verteilte Sperre + Zeit. Klicken Sie auf

  • Verwenden Sie die Nachrichtenwarteschlange

  Redis-Pipeline

  Für Single-Threaded-Blocking-Redis kann die Pipeline Batch-Vorgänge erfüllen und kontinuierlich senden Senden Sie mehrere Befehle an den Redis-Server und analysieren Sie sie dann einzeln. Antwortergebnisse. Durch Pipelining kann die Leistung der Stapelverarbeitung verbessert werden. Der Hauptgrund für die Verbesserung besteht darin, dass die „Interaktions-Roundtrip“-Zeit in der TCP-Verbindung verkürzt wird. Die unterste Ebene der Pipeline besteht darin, alle Vorgänge in Streams zu kapseln, und Redis definiert seine eigenen eingehenden und ausgehenden Ausgabestreams. Führen Sie Vorgänge in der sync()-Methode aus. Jede Anfrage wird in die Warteschlange gestellt und das Antwortpaket wird analysiert.

  Redis- und MySQL-Doppelschreibkonsistenzlösung

  Aktualisieren Sie zuerst die Datenbank und löschen Sie dann den Cache. Der Lesevorgang der Datenbank ist viel schneller als der Schreibvorgang, sodass fehlerhafte Daten nur schwer angezeigt werden. Sie können eine asynchrone Strategie zum verzögerten Löschen implementieren, um sicherzustellen, dass der Löschvorgang erst ausgeführt wird, wenn die Leseanforderung abgeschlossen ist.

  Weitere Kenntnisse zum Thema Programmierung finden Sie unter: Programmiervideos! !

Das obige ist der detaillierte Inhalt vonEine Zusammenfassung von mehr als 20 wichtigen Redis-Interviewfragen. Kommen Sie und sammeln Sie sie! !. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!