Heim > Datenbank > Redis > Hauptteil

Redis-Hochfrequenz-Interviewfragen (mit Antwortanalyse)

青灯夜游
Freigeben: 2021-04-27 09:14:48
nach vorne
3739 Leute haben es durchsucht

In diesem Artikel werden einige Fragen zu Redis-Hochfrequenzinterviews mit Ihnen geteilt. Es hat einen gewissen Referenzwert. Freunde in Not können sich darauf beziehen. Ich hoffe, es wird für alle hilfreich sein.

Redis-Hochfrequenz-Interviewfragen (mit Antwortanalyse)

Was ist Redis?


Redis (Remote Dictionary Server) ist eine Open-Source-(BSD-lizenzierte) leistungsstarke, nicht-relationale (NoSQL) Schlüsselwertdatenbank, die in der Sprache C geschrieben ist.

Redis kann Zuordnungen zwischen Schlüsseln und fünf verschiedenen Arten von Werten speichern. Der Schlüsseltyp kann nur eine Zeichenfolge sein und der Wert unterstützt fünf Datentypen: Zeichenfolge, Liste, Menge, Hash-Tabelle und geordnete Menge.

Anders als bei herkömmlichen Datenbanken werden Redis-Daten im Speicher gespeichert, sodass die Lese- und Schreibgeschwindigkeit sehr hoch ist. Daher wird Redis häufig in Cache-Richtung verwendet und kann mehr als 100.000 Lese- und Schreibvorgänge pro Sekunde verarbeiten höchste bekannte Leistung. Darüber hinaus wird Redis häufig für verteilte Sperren verwendet. Darüber hinaus unterstützt Redis Transaktionen, Persistenz, LUA-Skripte, LRU-gesteuerte Ereignisse und verschiedene Clusterlösungen.

Was sind die Vorteile und Nachteile von Redis?

Unterstützt Datenpersistenz und unterstützt zwei Persistenzmethoden: AOF und RDB.

Unterstützt Transaktionen von Redis. Gleichzeitig unterstützt Redis auch die atomare Ausführung nach der Zusammenführung mehrerer Vorgänge. Umfangreiche Datenstrukturen unterstützen neben der Unterstützung von Zeichenfolgentypwerten auch Hash-, Set-, Zset-, Listen- und andere Datenstrukturen.

Unterstützt die Master-Slave-Replikation, der Host synchronisiert die Daten automatisch mit dem Slave und es kann eine Lese- und Schreibtrennung durchgeführt werden.

Nachteile

Die Datenbankkapazität ist durch den physischen Speicher begrenzt und kann nicht zum Hochleistungslesen und -schreiben großer Datenmengen verwendet werden. Daher sind die für Redis geeigneten Szenarien hauptsächlich auf Hochleistungsoperationen und Berechnungen kleinerer Mengen beschränkt von Daten.

Redis verfügt nicht über automatische Fehlertoleranz- und Wiederherstellungsfunktionen. Die Ausfallzeit der Host- und Slave-Maschinen führt dazu, dass einige Front-End-Lese- und Schreibanforderungen fehlschlagen. Sie müssen warten, bis die Maschine neu gestartet wird, oder die Front-End-Maschine manuell umschalten. End-IP zur Wiederherstellung.

Der Host ist ausgefallen. Einige Daten konnten vor der Ausfallzeit nicht rechtzeitig mit dem Slave synchronisiert werden. Nach dem Wechsel der IP kommt es zu Dateninkonsistenzen, die die Verfügbarkeit des Systems verringern. Redis ist schwierig, die Online-Erweiterung zu unterstützen. Wenn die Clusterkapazität die Obergrenze erreicht, wird die Online-Erweiterung sehr kompliziert. Um dieses Problem zu vermeiden, muss das Betriebs- und Wartungspersonal sicherstellen, dass genügend Platz vorhanden ist, wenn das System online geht, was zu einer großen Ressourcenverschwendung führt.


Warum sollten wir Cache verwenden

, warum sollten wir Redis verwenden

Wir betrachten dieses Problem hauptsächlich unter den beiden Punkten „hohe Leistung“ und „hohe Parallelität“.

Hohe Leistung:

Angenommen, der Benutzer greift zum ersten Mal auf einige Daten in der Datenbank zu. Dieser Vorgang ist langsamer, da er von der Festplatte gelesen wird. Speichern Sie die Daten, auf die der Benutzer zugreift, im Cache, sodass die Daten beim nächsten Zugriff direkt aus dem Cache abgerufen werden können. Beim Betrieb des Caches wird der Speicher direkt betrieben, sodass die Geschwindigkeit recht hoch ist. Wenn sich die entsprechenden Daten in der Datenbank ändern, ändern Sie einfach synchron die entsprechenden Daten im Cache!


Hohe Parallelität:

Die Anforderungen, denen der Cache direkt standhalten kann, sind weitaus größer als die Anforderungen, die direkt auf die Datenbank zugreifen. Daher können wir erwägen, einige Daten in der Datenbank in den Cache zu übertragen, sodass einige davon Die Anforderungen des Benutzers werden direkt zum Cache weitergeleitet, ohne die Datenbank zu durchsuchen.

Redis-Hochfrequenz-Interviewfragen (mit Antwortanalyse)

Warum Redis anstelle von Map/Guava zum Caching verwenden?

Der Cache ist in lokalen Cache und verteilten Cache unterteilt. Am Beispiel von Java wird lokales Caching mithilfe der integrierten Karte oder Guave implementiert. Das Hauptmerkmal ist, dass es leichtgewichtig und schnell ist. Der Lebenszyklus endet mit der Zerstörung der JVM, und zwar bei mehreren Instanzen Instanz Jeder Cache muss gespeichert werden, und der Cache ist nicht konsistent.

Redis-Hochfrequenz-Interviewfragen (mit Antwortanalyse)

Die Verwendung von Redis oder Memcached wird als verteilter Cache bezeichnet. Bei mehreren Instanzen teilt sich jede Instanz einen Datencache und der Cache ist konsistent. Der Nachteil besteht darin, dass der Redis- oder Memcached-Dienst hochverfügbar gehalten werden muss und die gesamte Programmarchitektur relativ komplex ist.

Warum ist Redis so schnell? 1. Die meisten Anfragen basieren vollständig auf dem Speicher und sind reine Speicheroperationen, sehr schnell. Die Daten werden im Speicher gespeichert, ähnlich wie bei HashMap. Der Vorteil von HashMap besteht darin, dass die Datenstruktur einfach ist und die Datenoperation einfach ist Die Datenstruktur in Redis ist speziell für das Design konzipiert.


3. Es besteht keine Notwendigkeit, unnötige Kontextwechsel und Konkurrenzbedingungen zu vermeiden Berücksichtigen Sie verschiedene Sperrprobleme und es gibt keinen Sperrvorgang, der durch einen möglichen Deadlock verursacht wird

4. Verwenden Sie ein Mehrkanal-I/O-Wiederverwendungsmodell, nicht blockierendes IO.

5. Die zugrunde liegenden Implementierungsmethoden und die Anwendungsprotokolle für die Kommunikation mit dem Client sind unterschiedlich Mechanismus, da das allgemeine System Systemfunktionen aufruft, wird es eine gewisse Zeit zum Verschieben und Anfordern verschwenden.

Welche Datentypen hat Redis? Zset, Hash, erfüllt die meisten Nutzungsanforderungen. Typ: Typ. Gespeicherter Wert. Betrieb. Anwendungsszenario


STRING


String, Integer Oder Gleitkommazahlen Führen Sie Operationen für die gesamte Zeichenfolge oder einen Teil der Zeichenfolge aus. Führen Sie Inkrementierungs- oder Dekrementierungsoperationen für Ganzzahlen und Gleitkommazahlen durch. Führen Sie ein einfaches Zwischenspeichern von Schlüssel-Wert-Paaren durch oder Elemente von beiden Enden entfernen; Ungeordnet ZSETElemente hinzufügen, abrufen, löschen;

Redis-Anwendungsszenarien


Zusammenfassung 1

1. Counter

kann Inkrementierungs- und Dekrementierungsoperationen für String ausführen, um die Zählerfunktion zu realisieren. Redis, eine In-Memory-Datenbank, verfügt über eine sehr hohe Lese- und Schreibleistung und eignet sich sehr gut zum Speichern der Anzahl häufiger Lese- und Schreibvorgänge.

2. Cache

Legen Sie heiße Daten in den Speicher, legen Sie die maximale Speichernutzung und Eliminierungsstrategie fest, um die Cache-Trefferquote sicherzustellen.

3. Sitzungscache

Mit Redis können Sie Sitzungsinformationen mehrerer Anwendungsserver einheitlich speichern. Wenn der Anwendungsserver die Sitzungsinformationen des Benutzers nicht mehr speichert, hat er keinen Status mehr. Ein Benutzer kann einen beliebigen Anwendungsserver anfordern, wodurch eine hohe Verfügbarkeit und Skalierbarkeit einfacher erreicht wird.

4. Full Page Cache (FPC)

Zusätzlich zu den grundlegenden Sitzungstoken bietet Redis auch eine sehr einfache FPC-Plattform. Am Beispiel von Magento stellt Magento ein Plugin zur Verfügung, um Redis als Full-Page-Cache-Backend zu nutzen. Darüber hinaus verfügt Pantheon für WordPress-Benutzer über ein sehr gutes Plug-in wp-redis, das Ihnen dabei helfen kann, die von Ihnen durchsuchten Seiten so schnell wie möglich zu laden.

5. Nachschlagetabelle

DNS-Einträge eignen sich beispielsweise sehr gut für die Speicherung mit Redis. Die Nachschlagetabelle ähnelt dem Cache und nutzt außerdem die schnelle Nachschlagefunktion von Redis. Der Inhalt der Nachschlagetabelle kann jedoch nicht ungültig gemacht werden, während der Inhalt des Caches nicht ungültig gemacht werden kann, da der Cache nicht als zuverlässige Datenquelle dient.

6. Nachrichtenwarteschlange (Publish/Subscribe-Funktion)

List ist eine bidirektionale verknüpfte Liste, die Nachrichten über lpush und rpop schreiben und lesen kann. Am besten verwenden Sie jedoch Messaging-Middleware wie Kafka und RabbitMQ.

7. Verteilte Sperrenimplementierung

In einem verteilten Szenario können Sperren in einer eigenständigen Umgebung nicht zum Synchronisieren von Prozessen auf mehreren Knoten verwendet werden. Sie können den mit Redis gelieferten SETNX-Befehl verwenden, um verteilte Sperren zu implementieren. Darüber hinaus können Sie auch die offiziell bereitgestellte RedLock-Implementierung für verteilte Sperren verwenden.

8. Andere

Set kann Operationen wie Schnittmenge und Vereinigung implementieren und so Funktionen wie gemeinsame Freunde realisieren. ZSet kann geordnete Operationen implementieren, um Funktionen wie Rankings zu erreichen.

Zusammenfassung 2

Im Vergleich zu anderen Caches hat Redis einen sehr großen Vorteil, nämlich die Unterstützung mehrerer Datentypen.

Datentypbeschreibungszeichenfolge Zeichenfolge, das einfachste K-V-Speicher-Hashhash-Format, Wert ist Feld und Wert, geeignet für Szenarien wie ID-Detail. Liste ist eine einfache Liste, eine sequentielle Liste, unterstützt das Einfügen von Daten am Anfang oder am Ende des Satzes, eine ungeordnete Liste, schnelle Suchgeschwindigkeit, geeignet für die Verarbeitung von Schnittmengen, Vereinigungen und Differenzsätzen, sortierter Satz, geordneter Satz

Tatsächlich durch Eigenschaften der oben genannten Datentypen. Grundsätzlich können Sie sich geeignete Anwendungsszenarien vorstellen.

string——Geeignet für den einfachsten k-v-Speicher, ähnlich der zwischengespeicherten Speicherstruktur, SMS-Bestätigungscode, Konfigurationsinformationen usw., verwenden Sie diesen Typ zum Speichern.

Hash – Im Allgemeinen ist der Schlüssel eine ID oder eine eindeutige Kennung, und der Wert entspricht den Details. Zum Beispiel Produktdetails, persönliche Daten, Nachrichtendetails usw.

Liste – Da die Liste geordnet ist, eignet sie sich besser zum Speichern einiger geordneter und relativ fester Daten. Wie Provinz- und Stadttabellen, Wörterbuchtabellen usw. Da die Liste geordnet ist, kann sie nach der Schreibzeit sortiert werden, z. B. nach den neuesten Nachrichten, der Nachrichtenwarteschlange usw.

Set – Es kann einfach als ID-Listen-Modell verstanden werden, z. B. welche Freunde eine Person auf Weibo hat. Das Beste an Set ist, dass es Schnitt-, Vereinigungs- und Differenzoperationen für zwei Sets bereitstellen kann. Zum Beispiel: Finden Sie gemeinsame Freunde zwischen zwei Personen usw.

Sorted Set – ist eine erweiterte Version von Set, die einen Score-Parameter hinzufügt, der automatisch nach dem Score-Wert sortiert. Es eignet sich besser für Daten wie die Top 10, die nicht nach der Einfügezeit sortiert sind.

Wie oben erwähnt, ist Redis zwar keine so komplexe Datenstruktur wie eine relationale Datenbank, kann aber auch für viele Szenarien geeignet sein, einschließlich mehr als nur allgemeiner Cache-Datenstrukturen. Das Verständnis der für jede Datenstruktur geeigneten Geschäftsszenarien trägt nicht nur dazu bei, die Entwicklungseffizienz zu verbessern, sondern auch die Leistung von Redis effektiv zu nutzen.

Was ist Redis-Persistenz?


Persistenz besteht darin, die Speicherdaten auf die Festplatte zu schreiben, um zu verhindern, dass die Speicherdaten verloren gehen, wenn der Dienst ausfällt.

Was ist der Persistenzmechanismus von Redis? Was sind die Vor- und Nachteile jedes einzelnen?


Redis bietet zwei Persistenzmechanismen: RDB (Standard) und AOF-Mechanismus.

RDB: Dies ist die Abkürzung für Redis DataBase.

RDB ist die Standardpersistenzmethode von Redis. Die Speicherdaten werden in Form eines Snapshots für einen bestimmten Zeitraum auf der Festplatte gespeichert und die entsprechende generierte Datendatei heißt dump.rdb. Der Snapshot-Zeitraum wird über den Speicherparameter in der Konfigurationsdatei definiert.

Redis-Hochfrequenz-Interviewfragen (mit Antwortanalyse)

Vorteile:

1 Es gibt nur eine Datei dump.rdb, was für die Persistenz praktisch ist.

2. Gute Katastrophentoleranz, eine Datei kann auf einer sicheren Festplatte gespeichert werden.

3. Um die Leistung zu maximieren, verzweigen Sie den untergeordneten Prozess, um den Schreibvorgang abzuschließen, und lassen Sie den Hauptprozess weiterhin Befehle verarbeiten, sodass die E/A maximiert wird. Verwenden Sie einen separaten Unterprozess für die Persistenz, und der Hauptprozess führt keine E/A-Vorgänge aus, um die hohe Leistung von Redis sicherzustellen.

4. Wenn der Datensatz groß ist, ist die Starteffizienz höher als bei AOF.

Nachteile:

1. Geringe Datensicherheit. RDB wird in bestimmten Abständen beibehalten, wenn Redis zwischen der Persistenz fehlschlägt. Daher ist diese Methode besser geeignet, wenn die Datenanforderungen nicht streng sind als Aof-Dokument gespeichert.

AOF: Persistenz

Die AOF-Persistenz (d. h. Append Only File Persistence) zeichnet jeden von Redis ausgeführten Schreibbefehl in einer separaten Protokolldatei auf, die erneut im Protokoll gespeichert wird.


Wenn beide Methoden gleichzeitig aktiviert sind, räumt Redis bei der Datenwiederherstellung der AOF-Wiederherstellung Vorrang ein.

Redis-Hochfrequenz-Interviewfragen (mit Antwortanalyse)

Vorteile:

1. Datensicherheit, AOF-Persistenz kann mit dem appendfsync-Attribut konfiguriert werden, wobei jede Befehlsoperation immer in der AOF-Datei aufgezeichnet wird.


2. Schreiben Sie Dateien im Anhängemodus. Selbst wenn der Server mittendrin ausfällt, können Sie das Datenkonsistenzproblem mit dem Redis-Check-Aof-Tool lösen.

3. Rewrite-Modus des AOF-Mechanismus. Bevor die AOF-Datei neu geschrieben wird (Befehle werden zusammengeführt und neu geschrieben, wenn die Datei zu groß ist), können Sie einige der Befehle löschen (z. B. „flushall“).

Nachteile:

1 RDB-Dateien und die Wiederherstellungsgeschwindigkeit ist langsam.

2. Wenn der Datensatz groß ist, ist die Starteffizienz geringer als bei RDB.

Was sind die Vor- und Nachteile?

    AOF-Dateien werden häufiger aktualisiert als RDB. Die Verwendung von AOF zum Wiederherstellen von Daten hat Vorrang beide sind konfiguriert, Priorität wird eingeräumt. Loading AOF
  • Wie wähle ich die geeignete Persistenzmethode aus?

  • Generell gilt: Wer eine mit PostgreSQL vergleichbare Datensicherheit erreichen möchte, sollte beide Persistenzfunktionen gleichzeitig nutzen. In diesem Fall wird beim Neustart von Redis zuerst die AOF-Datei geladen, um die Originaldaten wiederherzustellen, da unter normalen Umständen der von der AOF-Datei gespeicherte Datensatz vollständiger ist als der von der RDB-Datei gespeicherte Datensatz.

  • Wenn Ihnen Ihre Daten am Herzen liegen, Sie sich aber einen Datenverlust innerhalb weniger Minuten leisten können, können Sie einfach RDB-Persistenz verwenden.
  • Viele Benutzer verwenden nur AOF-Persistenz, diese Methode wird jedoch nicht empfohlen, da die regelmäßige Generierung von RDB-Snapshots für die Datenbanksicherung sehr praktisch ist und RDB Datensätze schneller wiederherstellt als AOF. Darüber hinaus können durch die Verwendung von RDB auch Fehler in AOF-Programmen vermieden werden.

  • Wenn Sie möchten, dass Ihre Daten nur dann vorhanden sind, wenn der Server läuft, können Sie auch keine Persistenzmethode verwenden.

Wie erweitert man die persistenten Daten und den Cache von Redis?


Wenn Redis als Cache verwendet wird, verwenden Sie konsistentes Hashing, um eine dynamische Erweiterung und Kontraktion zu erreichen.

Wenn Redis als persistenter Speicher verwendet wird, muss eine feste Schlüssel-zu-Knoten-Zuordnungsbeziehung verwendet werden und die Anzahl der Knoten kann nach ihrer Festlegung nicht mehr geändert werden. Andernfalls (d. h. wenn sich Redis-Knoten dynamisch ändern müssen) muss ein System verwendet werden, das Daten zur Laufzeit neu ausgleichen kann, und derzeit ist dies nur für Redis-Cluster möglich.

Redis‘ Strategie zum Löschen abgelaufener Schlüssel

Wir alle wissen, dass Redis eine Schlüsselwertdatenbank ist, und wir können die Ablaufzeit der in Redis zwischengespeicherten Schlüssel festlegen. Die Ablaufrichtlinie von Redis bezieht sich darauf, wie Redis damit umgeht, wenn der zwischengespeicherte Schlüssel in Redis abläuft.


Normalerweise gibt es drei Arten von Ablaufstrategien:


Zeitgesteuerter Ablauf

: Für jeden Schlüssel mit einer Ablaufzeit muss ein Timer erstellt werden, der sofort nach Ablauf der Ablaufzeit gelöscht wird. Diese Strategie kann abgelaufene Daten sofort löschen und ist sehr speicherschonend; sie beansprucht jedoch eine große Menge an CPU-Ressourcen für die Verarbeitung abgelaufener Daten, was sich auf die Cache-Reaktionszeit und den Durchsatz auswirkt.

Verzögerter Ablauf: Nur wenn auf einen Schlüssel zugegriffen wird, wird beurteilt, ob der Schlüssel abgelaufen ist, und er wird gelöscht, wenn er abläuft. Diese Strategie kann CPU-Ressourcen maximal einsparen, ist jedoch sehr speicherunfreundlich. In extremen Fällen kann es vorkommen, dass auf eine große Anzahl abgelaufener Schlüssel nicht erneut zugegriffen werden kann, sodass sie nicht gelöscht werden und viel Speicher belegen.


Periodischer Ablauf
: Zu einem bestimmten Zeitpunkt wird eine bestimmte Anzahl von Schlüsseln im Ablaufwörterbuch einer bestimmten Anzahl von Datenbanken gescannt und die abgelaufenen Schlüssel werden gelöscht. Diese Strategie ist ein Kompromiss zwischen den ersten beiden. Durch Anpassen des Zeitintervalls geplanter Scans und des begrenzten Zeitverbrauchs jedes Scans kann unter verschiedenen Umständen das optimale Gleichgewicht zwischen CPU- und Speicherressourcen erreicht werden.

(Das Expires-Wörterbuch speichert die Ablaufzeitdaten aller Schlüssel mit festgelegter Ablaufzeit, wobei „key“ ein Zeiger auf einen Schlüssel im Schlüsselraum und „value“ die Ablaufzeit ist, die durch den UNIX-Zeitstempel des Schlüssels mit Millisekundengenauigkeit dargestellt wird . Der Schlüsselraum bezieht sich auf alle im Redis-Cluster gespeicherten Schlüssel.

Redis verwendet sowohl verzögerte als auch periodische Ablaufstrategien.

Wie stelle ich die Ablaufzeit und die dauerhafte Gültigkeit des Redis-Schlüssels ein?

EXPIRE- und PERSIST-Befehle.

Wir wissen, dass Ablauf zum Festlegen der Ablaufzeit des Schlüssels verwendet wird. Wie gehe ich also mit abgelaufenen Daten um?


Zusätzlich zur Cache-Invalidierungsstrategie, die mit dem Cache-Server geliefert wird (Redis hat 6 Strategien zur Auswahl). Standardmäßig können wir auch eine angepasste Cache-Entfernung entsprechend den spezifischen Geschäftsanforderungen durchführen. Es gibt zwei gängige Strategien:

1 Bereinigen Sie abgelaufene Caches regelmäßig.

2 Der verwendete Cache ist abgelaufen. Wenn er abgelaufen ist, rufen Sie das zugrunde liegende System auf, um neue Daten abzurufen und den Cache zu aktualisieren.

Beide haben ihre eigenen Vor- und Nachteile. Der Nachteil des ersten besteht darin, dass es schwieriger ist, eine große Anzahl zwischengespeicherter Schlüssel zu verwalten. Der Nachteil des zweiten besteht darin, dass der Cache jedes Mal, wenn ein Benutzer ihn anfordert, gespeichert werden muss als ungültig beurteilt werden, und die Logik ist relativ kompliziert! Welche Lösung konkret zum Einsatz kommt, kann anhand der eigenen Anwendungsszenarien abgewogen werden.

Es gibt 20 Millionen Daten in MySQL, aber nur 200.000 Daten werden in Redis gespeichert. Wie kann sichergestellt werden, dass es sich bei den Daten in Redis um heiße Daten handelt?


Wenn die Größe des Redis-Speicherdatensatzes auf eine bestimmte Größe ansteigt, wird die Dateneliminierungsstrategie implementiert.

Was sind die Speichereliminierungsstrategien von Redis?


Die Speichereliminierungsstrategie von Redis bezieht sich auf den Umgang mit Daten, die neu geschrieben werden müssen und zusätzlichen Speicherplatz erfordern, wenn der für das Caching in Redis verwendete Speicher nicht ausreicht .

1. Selektive Entfernung des globalen Schlüsselraums

noeviction: Wenn der Speicher nicht ausreicht, um die neu geschriebenen Daten aufzunehmen, meldet der neue Schreibvorgang einen Fehler.

allkeys-lru: Wenn der Speicher nicht ausreicht, um neu geschriebene Daten aufzunehmen, entfernen Sie im Schlüsselbereich den zuletzt verwendeten Schlüssel. (Dies wird am häufigsten verwendet)

allkeys-random: Wenn der Speicher nicht ausreicht, um neu geschriebene Daten aufzunehmen, wird ein Schlüssel zufällig aus dem Schlüsselraum entfernt.

2. Selektives Entfernen von Schlüsselräumen mit festgelegter Ablaufzeit

volatile-lru: Wenn der Speicher nicht ausreicht, um neu geschriebene Daten aufzunehmen, wird im Schlüsselraum mit festgelegter Ablaufzeit der zuletzt verwendete Schlüssel entfernt .

flüchtig-zufällig: 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.

volatile-ttl: Wenn der Speicher nicht ausreicht, um neu geschriebene Daten aufzunehmen, werden im Schlüsselraum mit festgelegter Ablaufzeit zuerst Schlüssel mit einer früheren Ablaufzeit entfernt.

Zusammenfassung

Die Auswahl der Speichereliminierungsstrategie von Redis hat keinen Einfluss auf die Verarbeitung abgelaufener Schlüssel. Die Speichereliminierungsrichtlinie wird verwendet, um Daten zu verarbeiten, die zusätzlichen Speicherplatz benötigen, wenn der Speicher nicht ausreicht. Die Ablaufrichtlinie wird verwendet, um abgelaufene zwischengespeicherte Daten zu verarbeiten.

Welche physischen Ressourcen verbraucht Redis hauptsächlich?


Speicher.

Was passiert, wenn Redis nicht mehr über genügend Speicher verfügt?


Wenn die festgelegte Obergrenze erreicht ist, gibt der Redis-Schreibbefehl eine Fehlermeldung zurück (der Lesebefehl kann jedoch weiterhin normal zurückkehren). Sie können auch den Speicherbeseitigungsmechanismus konfigurieren und Redis die obere Speichergrenze erreichen, Der alte Inhalt wird gelöscht.

Wie führt Redis eine Speicheroptimierung durch?


Sie können Daten vom Sammlungstyp wie Hash, Liste, sortierter Satz, Satz usw. gut nutzen, da normalerweise viele kleine Schlüsselwerte kompakter zusammen gespeichert werden können. Verwenden Sie so viele Hashes wie möglich (d. h. die in einer Hash-Tabelle gespeicherte Anzahl ist gering) und beanspruchen sehr wenig Speicher. Daher sollten Sie Ihr Datenmodell so weit wie möglich in eine Hash-Tabelle abstrahieren. Wenn in Ihrem Websystem beispielsweise ein Benutzerobjekt vorhanden ist, legen Sie keinen separaten Schlüssel für den Namen, den Nachnamen, die E-Mail-Adresse und das Passwort des Benutzers fest. Speichern Sie stattdessen alle Informationen des Benutzers in einer Hash-Tabelle.

Redis-Thread-Modell


Redis hat einen Netzwerkereignisprozessor entwickelt, der auf dem Reactor-Muster basiert. Dieser Prozessor wird als Dateiereignishandler bezeichnet. Seine Struktur besteht aus 4 Teilen: mehreren Sockets, IO-Multiplexer, Dateiereignis-Dispatcher und Ereignisprozessor. Da der Verbrauch der Dateiereignis-Dispatcher-Warteschlange Single-Threaded ist, wird Redis als Single-Threaded-Modell bezeichnet.

1. Der Dateiereignisprozessor verwendet ein E/A-Multiplexprogramm, um mehrere Sockets gleichzeitig zu überwachen, und ordnet den Sockets basierend auf den aktuell von den Sockets ausgeführten Aufgaben unterschiedliche Ereignisprozessoren zu.

2. Wenn der überwachte Socket bereit ist, Vorgänge wie Verbindungsantwort (Akzeptieren), Lesen (Lesen), Schreiben (Schreiben), Schließen (Schließen) usw. auszuführen, wird das dem Vorgang entsprechende Dateiereignis generiert. , dann ruft der Datei-Ereignishandler den zuvor dem Socket zugeordneten Ereignishandler auf, um diese Ereignisse zu verarbeiten.

Obwohl der Datei-Event-Handler im Single-Thread-Modus ausgeführt wird, implementiert der Datei-Event-Handler durch die Verwendung eines E/A-Multiplexers zum Abhören mehrerer Sockets sowohl ein leistungsstarkes Netzwerkkommunikationsmodell als auch eine gute Verbindung andere Module im Redis-Server, die ebenfalls im Single-Thread-Modus ausgeführt werden, wodurch die Einfachheit des Single-Thread-Designs in Redis erhalten bleibt.

Was ist eine Transaktion?


Eine Transaktion ist eine einzelne isolierte Operation: Alle Befehle in der Transaktion werden serialisiert und der Reihe nach ausgeführt. Während der Ausführung der Transaktion wird diese nicht durch Befehlsanfragen anderer Clients unterbrochen.

Eine Transaktion ist eine atomare Operation: Entweder werden alle Befehle in der Transaktion ausgeführt, oder keiner von ihnen wird ausgeführt.

Das Konzept der Redis-Transaktion

Das Wesentliche einer Redis-Transaktion ist eine Sammlung von Befehlen wie MULTI, EXEC und WATCH. 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: Eine Redis-Transaktion ist eine einmalige, sequentielle und exklusive Ausführung einer Reihe von Befehlen in einer Warteschlange.

Drei Phasen von Redis-Transaktionen

1. Transaktionsstart MULTI

2. Transaktionsausführung EXEC

Während der Transaktionsausführung empfängt der Server EXEC, DISCARD und andere Anforderungen als WATCH MULTI wird in die Warteschlange gestellt.

Redis-Transaktionsbezogene Befehle in Ordnung. 1. redis unterstützt kein Rollback: „Redis führt kein Rollback durch, wenn eine Transaktion fehlschlägt, sondern führt die verbleibenden Befehle weiterhin aus“, sodass die Interna von Redis einfach und schnell bleiben können.

2.

Wenn bei einem Befehl in einer Transaktion ein Fehler auftritt, werden nicht alle Befehle ausgeführt.

3 Wenn bei einer Transaktion ein Fehler auftritt, wird der richtige Befehl ausgeführt.

Der WATCH-Befehl ist eine optimistische Sperre, die Check-and-Set-Verhalten (CAS) für Redis-Transaktionen bereitstellt. Ein oder mehrere Schlüssel können überwacht werden. Sobald einer der Schlüssel geändert (oder gelöscht) wird, werden nachfolgende Transaktionen nicht ausgeführt und die Überwachung wird bis zum EXEC-Befehl fortgesetzt. Der Befehl MULTI wird zum Starten einer Transaktion verwendet und gibt immer OK zurück. Nachdem MULTI ausgeführt wurde, kann der Client weiterhin beliebig viele Befehle an den Server senden. Diese Befehle werden nicht sofort ausgeführt, sondern in eine Warteschlange gestellt. Beim Aufruf des EXEC-Befehls werden alle Befehle in der Warteschlange ausgeführt .

EXEC: Befehle in allen Transaktionsblöcken ausführen. Gibt die Rückgabewerte aller Befehle innerhalb des Transaktionsblocks zurück, geordnet in der Reihenfolge der Befehlsausführung. Wenn der Vorgang unterbrochen wird, wird der leere Wert Null zurückgegeben. Durch Aufrufen von DISCARD kann der Client die Transaktionswarteschlange leeren und die Ausführung der Transaktion aufgeben, und der Client verlässt den Transaktionsstatus.

Der Befehl UNWATCH kann die Überwachung aller Tasten durch die Uhr abbrechen.

Überblick über das Transaktionsmanagement (ACID)

Atomizität (Atomizität) Atomizität bedeutet, dass eine Transaktion eine unteilbare Arbeitseinheit ist und alle Vorgänge in einer Transaktion stattfinden.

  • Konsistenz

    Die Integrität der Daten vor und nach der Transaktion muss konsistent sein.

  • Isolation

    Wenn mehrere Transaktionen gleichzeitig ausgeführt werden, sollte die Ausführung einer Transaktion keinen Einfluss auf die Ausführung anderer Transaktionen haben.

  • Dauerhaftigkeit

    Dauerhaftigkeit bedeutet, dass die Änderungen an den Daten in der Datenbank dauerhaft sind, sobald eine Transaktion festgeschrieben wurde, und dass sie keine Auswirkungen haben sollten, selbst wenn die Datenbank ausfällt.

  • Redis-Transaktionen weisen immer ACID-Konsistenz und -Isolation auf, andere Funktionen werden nicht unterstützt. Transaktionen sind auch dauerhaft, wenn der Server im AOF-Persistenzmodus ausgeführt wird und der Wert der Option appendfsync immer ist. Unterstützt die Redis-Transaktion die Isolation?

    Redis ist ein Einzelprozessprogramm und garantiert, dass die Transaktion beim Ausführen der Transaktion nicht unterbrochen wird und die Transaktion ausgeführt werden kann, bis alle Befehle in der Transaktionswarteschlange ausgeführt sind. Daher sind Redis-Transaktionen immer isoliert.

Garantiert die Redis-Transaktion Atomizität und unterstützt sie ein Rollback? In Redis wird ein einzelner Befehl atomar ausgeführt, aber die Transaktion garantiert keine Atomizität und es gibt kein Rollback. Wenn ein Befehl in der Transaktion nicht ausgeführt werden kann, werden die verbleibenden Befehle trotzdem ausgeführt.


Andere Implementierungen von Redis-Transaktionen

Basierend auf Lua-Skripten kann Redis sicherstellen, dass die Befehle im Skript einmal und nacheinander ausgeführt werden. Es bietet auch kein Rollback von Transaktionsoperationsfehlern nicht ordnungsgemäß ausgeführt wird, werden die verbleibenden Befehle weiterhin ausgeführt.


Basierend auf der Zwischenmarkierungsvariablen wird eine weitere Markierungsvariable verwendet, um festzustellen, ob die Transaktion abgeschlossen ist. Beim Lesen von Daten wird zunächst die Markierungsvariable gelesen, um festzustellen, ob die Transaktion abgeschlossen ist. Dafür muss jedoch zusätzlicher Code implementiert werden, was umständlicher ist.

Sentinel-Modus


Redis-Hochfrequenz-Interviewfragen (mit Antwortanalyse)

Einführung in Sentinel

Sentinel, der chinesische Name ist Sentinel. Sentinel ist eine sehr wichtige Komponente in der Redis-Clusterorganisation. Es hat hauptsächlich die folgenden Funktionen:

Clusterüberwachung: Verantwortlich für die Überwachung, ob die Redis-Master- und Slave-Prozesse normal funktionieren.

Nachrichtenbenachrichtigung: Wenn eine Redis-Instanz ausfällt, ist Sentinel dafür verantwortlich, Nachrichten als Alarmbenachrichtigungen an den Administrator zu senden.

Failover: Wenn der Master-Knoten hängt, wird er automatisch auf den Slave-Knoten übertragen.

Konfigurationscenter: Wenn ein Failover auftritt, benachrichtigen Sie den Client über die neue Master-Adresse.

Sentinel wird verwendet, um eine hohe Verfügbarkeit des Redis-Clusters zu erreichen. Er wird auch als Sentinel-Cluster verteilt und arbeitet zusammen.

1. Während des Failovers erfordert die Feststellung, ob ein Masterknoten ausgefallen ist, die Zustimmung der meisten Sentinels, was das Problem der verteilten Wahl beinhaltet.

2. Selbst wenn einige Sentinel-Knoten ausfallen, kann der Sentinel-Cluster weiterhin normal funktionieren, denn wenn ein Failover-System selbst, das ein wichtiger Teil des Hochverfügbarkeitsmechanismus ist, ein einzelner Punkt ist, wird es sehr frustrierend sein.

Kernkenntnisse von Sentinel

1. Um seine Robustheit sicherzustellen, sind mindestens 3 Instanzen erforderlich.

2. Die Master-Slave-Bereitstellungsarchitektur von Sentinel + Redis garantiert keinen Datenverlust, sondern nur die hohe Verfügbarkeit des Redis-Clusters.

3. Versuchen Sie für die komplexe Bereitstellungsarchitektur von Sentinel + Redis Master-Slave, ausreichende Tests und Übungen sowohl in der Testumgebung als auch in der Produktionsumgebung durchzuführen.

Offizielle Redis-Cluster-Lösung (serverseitige Routing-Abfrage)

Redis-Hochfrequenz-Interviewfragen (mit Antwortanalyse)

Können Sie das Funktionsprinzip des Redis-Cluster-Modus erklären? Wie wird im Cluster-Modus der Schlüssel von Redis angesprochen? Welche Algorithmen gibt es für die verteilte Adressierung? Kennen Sie den konsistenten Hash-Algorithmus?

Einführung

Redis Cluster ist eine serverseitige Sharding-Technologie, offiziell in Version 3.0 verfügbar. Redis Cluster verwendet kein konsistentes Hashing, sondern das Slot-Konzept, das insgesamt in 16384 Slots unterteilt ist. Senden Sie die Anfrage an einen beliebigen Knoten, und der Knoten, der die Anfrage empfängt, sendet die Abfrageanforderung zur Ausführung an den richtigen Knoten

Projektbeschreibung

1 Teilen Sie die Daten durch Hashing auf und speichern Sie sie gleichmäßig auf jedem Knoten Standardmäßig werden einem bestimmten Hash-Slot-Bereich (Hash-Wert) 16384 Slots zugewiesen.

2 Jedes Datenfragment wird auf mehreren Knoten gespeichert, die gegenseitig Master- und Slave-Knoten sind. Die Daten werden zuerst auf den Master-Knoten geschrieben und dann synchronisiert zum Slave-Knoten (unterstützt die Konfiguration der Blockierungssynchronisation)

4. Die Datenkonsistenz zwischen mehreren Knoten im selben Shard wird nicht aufrechterhalten. Beim Lesen von Daten wird der vom Client betriebene Schlüssel nicht zugewiesen gibt den Steuerungsbefehl zurück und zeigt auf den richtigen Knoten Die Portnummer ist beispielsweise 6379 und die andere ist die Portnummer plus 1 W, z. B. 16379. Die Portnummer

16379 wird für die Kommunikation zwischen Knoten verwendet, d. h. Cluster-Bus-Kommunikation, Cluster-Bus-Kommunikation, zur Fehlererkennung, Konfigurationsaktualisierungen und Failover-Autorisierung. Der Cluster-Bus verwendet ein weiteres Binärprotokoll, das

Gossip-Protokoll, für einen effizienten Datenaustausch zwischen Knoten, der weniger Netzwerkbandbreite und Verarbeitungszeit beansprucht.

Interner Kommunikationsmechanismus zwischen Knoten

Grundlegende Kommunikationsprinzipien

Es gibt zwei Möglichkeiten, Cluster-Metadaten zu verwalten: zentralisiert und Klatschprotokoll. Das Gossip-Protokoll wird für die Kommunikation zwischen Redis-Clusterknoten verwendet.

Verteilter Adressierungsalgorithmus

Hash-Algorithmus (Massen-Cache-Rekonstruktion)

Konsistenter Hash-Algorithmus (automatische Cache-Migration) + virtueller Knoten (automatischer Lastausgleich)

    Hash-Slot des Redis-Cluster-Algorithmus
  • Vorteile

  • 1. Keine zentrale Architektur, unterstützt dynamische Erweiterung, transparent für das Unternehmen
  • 2. Verfügt über Sentinel-Überwachung und automatische Failover-Funktionen

  • 3. Der Client muss sich nicht mit allen Clusterknoten verbinden, sondern nur eine Verbindung herstellen zu jedem verfügbaren Knoten im Cluster

4 Hohe Leistung, der Client ist direkt mit dem Redis-Dienst verbunden, wodurch der Verlust des Proxy-Agenten vermieden wird

Nachteile

1 ist ein manueller Eingriff erforderlich

2. Nur Datenbank Nr. 0 kann verwendet werden

3. Verteilte Logik und Speichermodulkopplung usw.

Basierend auf der Client-Zuordnung

Einführung

Redis Sharding ist eine Clustering-Methode mit mehreren Redis-Instanzen, die in der Branche häufig verwendet wurde, bevor Redis Cluster auf den Markt kam. Die Hauptidee besteht darin, einen Hash-Algorithmus zu verwenden, um den Schlüssel von Redis-Daten zu hashen. Durch die Hash-Funktion wird ein bestimmter Schlüssel einem bestimmten Redis-Knoten zugeordnet. Der Java-Redis-Client steuert Jedis und unterstützt die Redis-Sharding-Funktion, d Jede Redis-Instanz ist wie ein einzelner Server und lässt sich sehr einfach linear erweitern. Nachteile: 1. Da die Sharding-Verarbeitung auf dem Client erfolgt Die Erweiterung des Maßstabs wird Herausforderungen für Betrieb und Wartung mit sich bringen.

2. Clientseitiges Sharding unterstützt kein dynamisches Hinzufügen und Löschen von Knoten. Wenn sich die Topologie der Redis-Instanzgruppe des Servers ändert, muss jeder Client aktualisiert und angepasst werden. Verbindungen können nicht gemeinsam genutzt werden. Ressourcenverschwendung schränkt die Optimierung ein. Leiten Sie die Anfrage an den richtigen Knoten weiter. Das Geschäftsprogramm muss sich nicht um die Back-End-Redis-Instanz kümmern, und die Umstellungskosten sind gering verloren

Branchen-Open-Source-Lösungen

1. Twtters Open-Source-Twemproxy2, Wandoujias Open-Source-Codis


Redis-Master-Slave-Architektur

Ein Einzelmaschinen-Redis kann Zehntausende QPS übertragen auf Zehntausende. Für Caches werden sie im Allgemeinen verwendet, um eine hohe Lesegleichzeitigkeit zu unterstützen. Daher ist die Architektur eine Master-Slave-Architektur mit einem Master und mehreren Slaves. Der Master ist für das Schreiben und Kopieren von Daten auf andere Slave-Knoten verantwortlich, und die Slave-Knoten sind für das Lesen verantwortlich. Alle Leseanfragen gehen an die Slave-Knoten. Dadurch kann auch problemlos eine horizontale Erweiterung erreicht und eine hohe Leseparallelität unterstützt werden.


Redis-Hochfrequenz-Interviewfragen (mit Antwortanalyse)

Redis-Replikation –> Lese- und Schreibtrennung –> Horizontale Erweiterung unterstützt hohe Lese-Parallelität

1 Kopieren Sie Daten auf den Slave-Knoten, aber ab redis2.8 bestätigt der Slave-Knoten regelmäßig die Datenmenge, die er kopiert.

2 Ein Master-Knoten kann mit mehreren Slave-Knoten konfiguriert werden kann sich auch mit anderen Slave-Knoten verbinden.

4. Wenn der Slave-Knoten repliziert, blockiert er nicht die normale Arbeit des Master-Knotens Der alte Datensatz wird zum Bereitstellen von Diensten verwendet. Wenn der Kopiervorgang abgeschlossen ist, muss der neue Datensatz gelöscht werden 6. Der Slave-Knoten wird hauptsächlich zur horizontalen Erweiterung und Trennung von Lesen und Schreiben verwendet. Der erweiterte Slave-Knoten kann den Lesedurchsatz verbessern. Beachten Sie, dass bei Verwendung einer Master-Slave-Architektur empfohlen wird, die Persistenz des Master-Knotens zu aktivieren. Es wird nicht empfohlen, den Slave-Knoten als Daten-Hot-Backup des Master-Knotens zu verwenden Wenn Sie in diesem Fall die Persistenz des Masters deaktivieren, kann der Master-Knoten beschädigt werden. Wenn die Maschine abstürzt und neu startet, sind die Daten leer und die Daten des Slave-Knotens gehen möglicherweise verloren, sobald sie repliziert werden.

Darüber hinaus müssen auch verschiedene Backup-Pläne für den Master erstellt werden. Falls alle lokalen Dateien verloren gehen, wählen Sie eine RDB aus der Sicherung aus, um den Master wiederherzustellen. Dadurch wird sichergestellt, dass beim Start Daten vorhanden sind. Auch wenn der später erläuterte Hochverfügbarkeitsmechanismus übernommen wird, kann der Slave-Knoten automatisch den Master übernehmen Es ist jedoch auch möglich, dass der Master-Knoten automatisch neu gestartet wurde, bevor Sentinel den Master-Fehler erkennt, oder dass alle oben genannten Slave-Knotendaten gelöscht werden.

Das Kernprinzip der Redis-Master-Slave-Replikation

Wenn ein Slave-Knoten gestartet wird, sendet er einen PSYNC-Befehl an den Master-Knoten. Wenn dies das erste Mal ist, dass der Slave-Knoten eine Verbindung zum Master-Knoten herstellt, wird eine vollständige Neusynchronisierung und vollständige Kopie ausgelöst. Zu diesem Zeitpunkt startet der Master einen Hintergrundthread und beginnt mit der Generierung einer RDB-Snapshot-Datei. Gleichzeitig werden alle vom Client neu empfangenen Schreibbefehle im Speicher zwischengespeichert. Nachdem die RDB-Datei generiert wurde, sendet der Master die RDB zunächst auf die lokale Festplatte und lädt sie dann von der lokalen Festplatte in den Speicher. Anschließend sendet der Master den zwischengespeicherten Schreibbefehl Der Speicher des Slaves wird ebenfalls synchronisiert.

Wenn ein Netzwerkfehler zwischen dem Slave-Knoten und dem Master-Knoten auftritt und die Verbindung getrennt wird, wird die Verbindung automatisch wiederhergestellt. Nach dem Herstellen der Verbindung kopiert der Master-Knoten nur die fehlenden Daten auf den Slave.

Prozessprinzip


1. Wenn die MS-Beziehung zwischen der Slave-Bibliothek und der Hauptbibliothek hergestellt ist, wird der SYNC-Befehl an die Hauptdatenbank gesendet

2 Nach dem Empfang des SYNC-Befehls beginnt die Hauptbibliothek, Snapshots im Hintergrund zu speichern (RDB-Persistenzprozess) und empfängt die Schreibbefehle zwischengespeichert

3. Wenn der Snapshot abgeschlossen ist, sendet der Master-Redis die Snapshot-Datei und alle zwischengespeicherten Schreibbefehle an den Slave-Redis

4 Redis lädt die Snapshot-Datei und führt die empfangenen zwischengespeicherten Befehle aus Die gesamte Datenreplikation und -synchronisierung des Slave-Knotens erfolgt durch die Verarbeitung des Master-Knotens. Dies führt dazu, dass der Master-Knoten zu stark belastet wird. Verwenden Sie die Master-Slave-Struktur, um das Problem zu lösen Cluster?

Um den Cluster weiterhin verfügbar zu machen, wenn einige Knoten ausfallen oder die meisten Knoten nicht kommunizieren können, verwendet der Cluster ein Master-Slave-Replikationsmodell und jeder Knoten verfügt über N-1-Replikate. Redis in der Produktionsumgebung Wie ist das? es eingesetzt?

Redis-Cluster, 10 Maschinen, 5 Maschinen werden mit Redis-Master-Instanzen bereitgestellt, und die anderen 5 Maschinen werden mit Redis-Slave-Instanzen bereitgestellt, und 5 Knoten stellen externe Lese- und Schreibdienste bereit Die Schreibspitzen-QPS eines Knotens kann 50.000 pro Sekunde erreichen, und die maximale Lese- und Schreibanfrage/s für 5 Maschinen beträgt 250.000.

Wie ist die Konfiguration der Maschine? 32G Speicher + 8-Kern-CPU + 1T-Festplatte, aber der dem Redis-Prozess zugewiesene Speicher beträgt 10 g. In allgemeinen Online-Produktionsumgebungen sollte der Speicher von Redis 10 g nicht überschreiten. 5 Maschinen ermöglichen externes Lesen und Schreiben mit insgesamt 50 g Speicher.

Da jede Master-Instanz über eine Slave-Instanz verfügt, ist sie hochverfügbar. Wenn eine Master-Instanz ausfällt, erfolgt automatisch ein Failover und die Redis-Slave-Instanz wird automatisch zur Master-Instanz und stellt weiterhin Lese- und Schreibdienste bereit.

Welche Daten schreibst du in den Speicher? Wie groß ist jedes Datenelement? Produktdaten, jedes Datenelement ist 10 KB groß. 100 Daten sind 1 MB und 100.000 Daten sind 1 g. Im Speicher befinden sich 2 Millionen Produktdaten, und der belegte Speicher beträgt 20 g, was nur weniger als 50 % des gesamten Speichers ausmacht. Die aktuelle Spitzenzeit liegt bei etwa 3.500 Anfragen pro Sekunde.


Tatsächlich verfügen große Unternehmen über ein Infrastrukturteam, das für den Betrieb und die Wartung des Cache-Clusters verantwortlich ist.


Sprechen Sie über das Konzept des Redis-Hash-Slots?

Der Redis-Cluster verwendet kein konsistentes Hashing, sondern führt das Konzept der Hash-Slots ein. Jeder Schlüssel wird von CRC16 überprüft und Modulo 16384 wird verwendet, um zu bestimmen, welcher Slot verantwortlich ist für einen Teil des Hash-Slots.

Wird der Redis-Cluster Schreibvorgänge verlieren? Warum?

Redis garantiert keine starke Datenkonsistenz, was bedeutet, dass der Cluster in der Praxis unter bestimmten Bedingungen Schreibvorgänge verlieren kann.


Wie werden Redis-Cluster repliziert?

Asynchrone Replikation


Was ist die maximale Anzahl von Knoten in einem Redis-Cluster?

16384


Wie wähle ich eine Datenbank für den Redis-Cluster aus?

Der Redis-Cluster kann derzeit keine Datenbank auswählen und ist standardmäßig auf Datenbank 0 eingestellt.


Redis ist Single-Threaded. Wie kann die Auslastung der Multi-Core-CPU verbessert werden?


Sie können mehrere Redis-Instanzen auf demselben Server bereitstellen und diese als unterschiedliche Server verwenden. Irgendwann reicht ein Server ohnehin nicht aus. Wenn Sie also mehrere CPUs verwenden möchten, können Sie Sharding in Betracht ziehen.


Warum benötigen Sie eine Redis-Partitionierung?

Partitionierung ermöglicht es Redis, größeren Speicher zu verwalten, und Redis kann den Speicher aller Maschinen nutzen. Ohne Partitionen können Sie nur den Arbeitsspeicher einer Maschine nutzen. Durch die Partitionierung lässt sich die Rechenleistung von Redis durch einfaches Hinzufügen von Computern verdoppeln, und auch die Netzwerkbandbreite von Redis erhöht sich durch das Hinzufügen von Computern und Netzwerkkarten exponentiell.


Wissen Sie, welche Redis-Partitionsimplementierungslösungen verfügbar sind?

1. Clientseitige Partitionierung bedeutet, dass der Client bereits entschieden hat, in welchem ​​Redis-Knoten die Daten gespeichert oder von diesem gelesen werden. Die meisten Clients implementieren bereits eine clientseitige Partitionierung.


2. Agent-Partitionierung bedeutet, dass der Client die Anfrage an den Agenten sendet und der Agent dann entscheidet, auf welchen Knoten er Daten schreibt oder liest. Der Agent entscheidet anhand der Partitionsregeln, welche Redis-Instanzen angefordert werden sollen, und gibt sie dann basierend auf den Redis-Antwortergebnissen an den Client zurück. Eine Proxy-Implementierung für Redis und Memcached ist Twemproxy.


3. Abfragerouting bedeutet, dass der Client zufällig eine beliebige Redis-Instanz anfordert und Redis die Anfrage dann an den richtigen Redis-Knoten weiterleitet. Redis Cluster implementiert eine Hybridform des Abfrageroutings, aber anstatt Anforderungen direkt von einem Redis-Knoten an einen anderen Redis-Knoten weiterzuleiten, leitet es mit Hilfe des Clients direkt an den richtigen Redis-Knoten weiter.

Was sind die Nachteile der Redis-Partitionierung?


1. Operationen mit mehreren Schlüsseln werden normalerweise nicht unterstützt. Beispielsweise können Sie zwei Sammlungen nicht überschneiden, da sie möglicherweise in verschiedenen Redis-Instanzen gespeichert sind (eigentlich gibt es für diese Situation eine Möglichkeit, aber der Schnittbefehl kann nicht direkt verwendet werden).

2. Wenn Sie mehrere Schlüssel gleichzeitig bedienen, können Sie keine Redis-Transaktionen verwenden.

3. Die Partitionierungsgranularität ist der Schlüssel, daher ist es nicht möglich, einen Datensatz wie einen sehr großen sortierten Satz zu fragmentieren.

4. Bei der Verwendung von Partitionen ist die Datenverarbeitung sehr kompliziert. Für die Sicherung müssen Sie gleichzeitig RDB/AOF-Dateien von verschiedenen Redis-Instanzen und Hosts sammeln.

5. Die dynamische Expansion oder Kontraktion während der Partitionierung kann sehr kompliziert sein. Der Redis-Cluster fügt zur Laufzeit Redis-Knoten hinzu oder löscht sie, wodurch eine für Benutzer weitgehend transparente Datenverteilung erreicht werden kann. Einige andere Client-Partitionierungs- oder Proxy-Partitionierungsmethoden unterstützen diese Funktion jedoch nicht. Allerdings gibt es eine Pre-Sharding-Technologie, die dieses Problem ebenfalls besser lösen kann.

Redis implementiert verteilte Sperren


Redis ist ein Einzelprozess-Single-Thread-Modus. Es verwendet den Warteschlangenmodus, um den gleichzeitigen Zugriff in seriellen Zugriff umzuwandeln, und es kann keine Konkurrenz zwischen den Verbindungen mehrerer Clients zu Redis geben Wird im Redis-Befehl zur Implementierung einer verteilten Sperre verwendet.

Wenn und nur wenn der Schlüssel nicht vorhanden ist, setzen Sie den Wert des Schlüssels auf „Wert“. Wenn der angegebene Schlüssel bereits existiert, ergreift SETNX keine Aktion

SETNX ist die Abkürzung für „SET if Not eXists“ (wenn er nicht existiert, dann SET).

Rückgabewert: Erfolgreich gesetzt, Rückgabe 1. Das Setup schlägt fehl und gibt 0 zurück.

Der Prozess und die Dinge bei der Verwendung von SETNX zum Abschließen der Synchronisationssperre sind wie folgt:

Verwenden Sie den SETNX-Befehl, um die Sperre zu erhalten. Wenn 0 zurückgegeben wird (der Schlüssel ist bereits vorhanden, ist die Sperre bereits vorhanden), andernfalls schlägt die Erfassung fehl Der Erwerb ist erfolgreich.

Um Programmausnahmen nach dem Erwerb der Sperre zu verhindern, die dazu führen, dass andere Threads/Prozesse beim Aufrufen des SETNX-Befehls immer 0 zurückgeben und in einen Deadlock-Zustand gelangen, müssen Sie eine „angemessene“ Ablaufzeit dafür festlegen Schlüssel

Entfernen Sie die Sperre und löschen Sie die Sperrdaten mit dem Befehl DEL

So lösen Sie das Problem des gleichzeitigen Wettbewerbs um Schlüssel in Redis.


Das sogenannte Problem des gleichzeitigen Wettbewerbs um Schlüssel in Redis besteht darin, dass mehrere Systeme vorhanden sind Betreiben Sie gleichzeitig eine Taste, aber die endgültige Ausführungsreihenfolge unterscheidet sich von der erwarteten Reihenfolge, was zu unterschiedlichen Ergebnissen führt!

Empfehlen Sie eine Lösung: verteilte Sperre (sowohl Zookeeper als auch Redis können verteilte Sperren implementieren). (Wenn es in Redis keine gleichzeitige Konkurrenz für Key gibt, verwenden Sie keine verteilten Sperren, da dies die Leistung beeinträchtigt.)

Verteilte Sperren basierend auf den vorübergehend geordneten Knoten des Zookeepers. Die allgemeine Idee ist: Wenn jeder Client eine bestimmte Methode sperrt, wird im Verzeichnis des angegebenen Knotens, der der Methode auf zookeeper entspricht, ein eindeutiger, sofort geordneter Knoten generiert. Die Bestimmung, ob eine Sperre erworben werden soll, ist sehr einfach. Sie müssen lediglich die kleinste Sequenznummer unter den geordneten Knoten ermitteln. Wenn die Sperre aufgehoben wird, löschen Sie einfach den Übergangsknoten. Gleichzeitig können Deadlock-Probleme vermieden werden, die durch Sperren verursacht werden, die aufgrund von Dienstausfallzeiten nicht freigegeben werden können. Löschen Sie nach Abschluss des Geschäftsprozesses den entsprechenden untergeordneten Knoten, um die Sperre aufzuheben.

In der Praxis steht natürlich die Zuverlässigkeit an erster Stelle. Daher wird zunächst Zookeeper empfohlen.

Sollte verteiltes Redis in der frühen Phase oder in der späteren Phase erfolgen, wenn der Umfang erhöht wird? Warum?


Da Redis so leichtgewichtig ist (eine einzelne Instanz benötigt nur 1 MB Speicher), besteht der beste Weg, zukünftige Erweiterungen zu verhindern, darin, weitere Instanzen von Anfang an zu starten. Selbst wenn Sie nur einen Server haben, können Sie Redis von Anfang an verteilt ausführen und dabei Partitionen verwenden, um mehrere Instanzen auf demselben Server zu starten.

Richten Sie zu Beginn ein paar weitere Redis-Instanzen ein, beispielsweise 32 oder 64 Instanzen. Dies mag für die meisten Benutzer mühsam sein, aber auf lange Sicht lohnt es sich.

In diesem Fall, wenn Ihre Daten weiter wachsen und Sie mehr Redis-Server benötigen, müssen Sie lediglich die Redis-Instanz von einem Dienst auf einen anderen Server migrieren (ohne das Problem der Neupartitionierung zu berücksichtigen). Sobald Sie einen weiteren Server hinzufügen, müssen Sie die Hälfte Ihrer Redis-Instanzen von der ersten Maschine auf die zweite Maschine migrieren.

Was ist RedLock


Die offizielle Redis-Website hat eine maßgebliche Methode zur Implementierung verteilter Sperren basierend auf Redlock namens Redlock vorgeschlagen. Diese Methode ist sicherer als die ursprüngliche Einzelknotenmethode. Es kann die folgenden Funktionen garantieren:

1. Sicherheitsfunktionen: sich gegenseitig ausschließender Zugriff, d. h. nur ein Client kann immer die Sperre erhalten.

2 Deadlock vermeiden: Am Ende können alle Clients die Sperre erhalten Es kommt zu keinem Deadlock, auch wenn der Client, der ursprünglich eine Ressource gesperrt hat, abstürzt oder eine Netzwerkpartition auftritt. Fehlertoleranz: Solange die meisten Redis-Knoten bestehen, können Dienste normal bereitgestellt werden

Cache-Lawine

Cache-Lawine bezieht sich auf den gleichzeitigen großflächigen Ausfall des Caches. Daher fallen nachfolgende Anfragen auf die Datenbank, was dazu führt, dass die Datenbank einer großen Anzahl von Anfragen in kurzer Zeit standhält von Zeit und Zusammenbruch.

Lösung

1. Stellen Sie die Ablaufzeit der zwischengespeicherten Daten zufällig ein, um zu verhindern, dass eine große Anzahl von Daten gleichzeitig abläuft.

2. Wenn der Umfang der Parallelität nicht besonders groß ist, ist Sperren und Warteschlangen die am häufigsten verwendete Lösung.

3. Fügen Sie zu allen zwischengespeicherten Daten ein entsprechendes Cache-Tag hinzu und notieren Sie, ob der Cache ungültig ist. Aktualisieren Sie den Datencache.

Cache-Penetration

Cache-Penetration bezieht sich auf Daten, die sich weder im Cache noch in der Datenbank befinden, wodurch alle Anforderungen auf die Datenbank fallen, wodurch die Datenbank in kurzer Zeit einer großen Anzahl von Anforderungen standhalten kann Zeit und Zusammenbruch.

Lösung

1. Fügen Sie die Überprüfung auf der Schnittstellenebene hinzu, z. B. die Überprüfung der Benutzerauthentifizierung, das direkte Abfangen der ID.

2 Zu diesem Zeitpunkt kann das Schlüssel-Wert-Paar auch als Schlüssel-Null geschrieben werden. Die Cache-Gültigkeitszeit kann kürzer eingestellt werden, z. B. 30 Sekunden (eine zu lange Einstellung führt dazu, dass sie im Normalfall unbrauchbar ist). Umstände). Dies kann verhindern, dass angreifende Benutzer wiederholt dieselbe ID für Brute-Force-Angriffe verwenden.

3 Um alle möglichen Daten in eine ausreichend große Bitmap umzuwandeln, werden diese abgefangen Vermeidung von Abfragedruck auf das zugrunde liegende Speichersystem.

Zusätzlich

hat ein extremes Maß an Raumausnutzung erreicht, nämlich Bitmap und Bloom-Filter.

Bitmap: Das typische ist die Hash-Tabelle

Der Nachteil ist, dass Bitmap nur 1 Bit an Informationen für jedes Element aufzeichnen kann. Wenn Sie zusätzliche Funktionen ausführen möchten, können Sie dies leider nur erreichen, indem Sie mehr opfern Raum und Zeit.

Bloom-Filter (empfohlen)

führt k(k>1)k(k>1) unabhängige Hash-Funktionen ein, um sicherzustellen, dass die Elemente innerhalb eines bestimmten Raums und einer bestimmten Fehleinschätzungsrate vervollständigt werden. Der Prozess der Beurteilung.

Sein Vorteil besteht darin, dass die Speicherplatzeffizienz und die Abfragezeit weitaus höher sind als beim allgemeinen Algorithmus. Sein Nachteil besteht darin, dass er eine gewisse Fehlerkennungsrate und Schwierigkeiten beim Löschen aufweist.

Die Kernidee des Bloom-Filter-Algorithmus besteht darin, mehrere verschiedene Hash-Funktionen zu verwenden, um „Konflikte“ zu lösen.

Hash hat ein Konfliktproblem (Kollisionsproblem), und die Werte zweier URLs, die unter Verwendung desselben Hashs erhalten werden, können gleich sein. Um Konflikte zu reduzieren, können wir mehrere weitere Hashes einführen. Wenn wir anhand eines der Hashwerte schließen, dass ein Element nicht in der Menge ist, dann ist das Element definitiv nicht in der Menge. Nur wenn alle Hash-Funktionen uns mitteilen, dass das Element in der Menge vorhanden ist, können wir sicher sein, dass das Element in der Menge vorhanden ist. Dies ist die Grundidee von Bloom-Filter.

Bloom-Filter wird im Allgemeinen verwendet, um festzustellen, ob ein Element in einem großen Datensatz vorhanden ist.

Cache-Aufschlüsselung

Cache-Aufschlüsselung bezieht sich auf Daten, die sich nicht im Cache, sondern in der Datenbank befinden (normalerweise, wenn die Cache-Zeit zu diesem Zeitpunkt abläuft, da die Anzahl der gleichzeitigen Benutzer groß ist). wird nicht gleichzeitig in den Cache gelesen. Gleichzeitig wird die Datenbank zum Abrufen von Daten aufgerufen, was dazu führt, dass der Druck auf die Datenbank sofort zunimmt, was zu übermäßigem Druck führt. Im Gegensatz zur Cache-Lawine bezieht sich die Cache-Aufschlüsselung auf die gleichzeitige Abfrage derselben Daten. Cache-Lawine bedeutet, dass unterschiedliche Daten abgelaufen sind und viele Daten nicht gefunden werden können, sodass die Datenbank durchsucht wird.

Lösung

1. Stellen Sie die Hotspot-Daten so ein, dass sie nie ablaufen direkt in das Cache-System geladen. Auf diese Weise können Sie das Problem vermeiden, zuerst die Datenbank abzufragen und dann die Daten zwischenzuspeichern, wenn der Benutzer sie anfordert! Benutzer fragen direkt zwischengespeicherte Daten ab, die vorgewärmt wurden!

Lösung

1. Schreiben Sie direkt eine Cache-Aktualisierungsseite und führen Sie diese manuell durch. 2. Die Datenmenge ist nicht groß und kann automatisch geladen werden regelmäßig zwischenspeichern;

Cache-Downgrade

Wenn der Datenverkehr stark ansteigt, Dienstprobleme auftreten (z. B. langsame Reaktionszeit oder keine Antwort) oder nicht zum Kerngeschäft gehörende Dienste die Leistung von Kernprozessen beeinträchtigen, müssen Sie dennoch sicherstellen dass der Dienst auch bei Beeinträchtigung des Dienstes weiterhin verfügbar ist. Das System kann basierend auf einigen Schlüsseldaten automatisch ein Downgrade durchführen oder Switches konfigurieren, um ein manuelles Downgrade durchzuführen.

Das ultimative Ziel des Cache-Downgrades besteht darin, sicherzustellen, dass Kerndienste verfügbar sind, auch wenn sie verlustbehaftet sind. Und einige Dienste können nicht herabgestuft werden (z. B. Hinzufügen zum Warenkorb, Bezahlen).

Vor dem Herabstufen müssen Sie das System sortieren, um zu sehen, ob das System Soldaten verlieren und Kommandeure behalten kann. Dabei können Sie herausfinden, was bis zum Tod geschützt werden muss und was herabgestuft werden kann Einstellungsplan:

1. Allgemein: Einige Dienste treten aufgrund von Netzwerkschwankungen gelegentlich auf und werden automatisch heruntergestuft. 2. B. zwischen 95 und 100 % und kann automatisch oder manuell herabgestuft werden und einen Alarm senden. 3 Fehler: Beispielsweise liegt die Verfügbarkeitsrate unter 90 % oder der Datenbankverbindungspool ist aufgelöst. oder die Anzahl der Besuche steigt plötzlich auf den maximalen Schwellenwert, den das System ertragen kann. Dies kann je nach Situation automatisch oder manuell herabgestuft werden

4. Schwerwiegender Fehler: Wenn die Daten beispielsweise aus besonderen Gründen falsch sind, ist ein manuelles Notfall-Downgrade erforderlich.

Der Zweck des Dienst-Downgrades besteht darin, zu verhindern, dass ein Ausfall des Redis-Dienstes Lawinenprobleme in der Datenbank verursacht. Daher kann für unwichtige zwischengespeicherte Daten eine Service-Downgrade-Strategie angewendet werden. Ein gängiger Ansatz besteht beispielsweise darin, dass bei einem Problem mit Redis die Datenbank nicht abgefragt wird, sondern direkt der Standardwert an den Benutzer zurückgegeben wird. „Heiße Daten und kalte Daten“ hat aber auch einen Wert, der nicht groß ist. Bei häufig geänderten Daten sollten Sie je nach Situation die Verwendung eines Caches in Betracht ziehen.

Bei wichtigen Daten wie einem unserer IM-Produkte, einem Geburtstagsgrußmodul und einer Geburtstagsliste des Tages kann der Cache Hunderttausende Male gelesen werden. Ein weiteres Beispiel: In einem Navigationsprodukt speichern wir Navigationsinformationen zwischen und lesen sie möglicherweise in Zukunft millionenfach. Cache macht nur dann Sinn, wenn die Daten vor der Aktualisierung mindestens zweimal gelesen werden. Dies ist die grundlegendste Strategie, wenn der Cache ausfällt, bevor er wirksam wird. Was ist mit dem Szenario, in dem der Cache nicht vorhanden ist und die Änderungshäufigkeit sehr hoch ist, aber Caching in Betracht gezogen werden muss? haben! Diese Leseschnittstelle übt beispielsweise großen Druck auf die Datenbank aus, es handelt sich jedoch auch um heiße Daten. Zu diesem Zeitpunkt müssen Caching-Methoden in Betracht gezogen werden, um den Druck auf die Datenbank zu verringern, z. B. die Anzahl der Likes, Sammlungen usw Anteile eines unserer Assistentenprodukte sind sehr typische Hot-Daten, die sich jedoch ständig ändern. Zu diesem Zeitpunkt müssen die Daten synchron im Redis-Cache gespeichert werden, um den Druck auf die Datenbank zu verringern.

Cache-Hotspot-Schlüssel

Ein Schlüssel im Cache (z. B. ein Werbeartikel) läuft zu einem bestimmten Zeitpunkt ab und es gibt zu diesem Zeitpunkt eine große Anzahl gleichzeitiger Anfragen für diesen Schlüssel Anfragen finden Wenn der Cache abläuft, werden die Daten normalerweise aus der Back-End-Datenbank geladen und in den Cache zurückgesetzt. Zu diesem Zeitpunkt können große gleichzeitige Anforderungen die Back-End-Datenbank sofort überlasten.

Lösung

Sperren Sie die Cache-Abfrage, sperren Sie sie, überprüfen Sie die Datenbank im Cache und entsperren Sie sie. Warten Sie, ob sie eine Sperre finden, und geben Sie dann die Daten zurück Geben Sie nach dem Entsperren von Query die Datenbank ein

Gemeinsame Tools

Welche Java-Clients werden von Redis unterstützt? Welches wird offiziell empfohlen?

Redisson, Jedis, Salat usw., die offizielle Empfehlung ist die Verwendung von Redisson.

Welche Beziehung besteht zwischen Redis und Redisson?

Redisson ist ein erweiterter Redis-Client für verteilte Koordination, der Benutzern dabei helfen kann, einige Java-Objekte (Bloom-Filter, BitSet, Set, SetMultimap, ScoredSortedSet, SortedSet, Map, ConcurrentMap, List, ListMultimap), Queue, BlockingQueue einfach in einer verteilten Umgebung zu implementieren , Deque, BlockingDeque, Semaphore, Lock, ReadWriteLock, AtomicLong, CountDownLatch, Publish/Subscribe, HyperLogLog).

Was sind die Vor- und Nachteile von Jedis und Redisson?

Jedis ist ein in Java implementierter Client für Redis. Seine API implementiert eine verteilte und skalierbare Java-Datenstruktur, seine Funktionen sind einfacher und unterstützen keine Zeichenkettenoperationen Unterstützt keine Redis-Funktionen wie Sortierung, Transaktionen, Pipelines und Partitionen. Der Zweck von Redisson besteht darin, die Trennung der Benutzeranliegen von Redis zu fördern, sodass sich Benutzer mehr auf die Verarbeitung der Geschäftslogik konzentrieren können.

Andere Fragen

Der Unterschied zwischen Redis und Memcached

Beide sind nicht relationale Speicher-Schlüsselwertdatenbanken. Heutzutage verwenden Unternehmen im Allgemeinen Redis, um Caching zu implementieren, und Redis selbst wird immer leistungsfähiger . ! Die Hauptunterschiede zwischen Redis und Memcached sind wie folgt:

Einzelne oder mehrere Elemente kürzen und nur Elemente innerhalb eines Bereichs beibehalten Einige listenartige Datenstrukturen speichern, ähnlich wie Fanlisten, Artikelkommentarlisten und andere Daten
SET
Ein einzelnes Element hinzufügen, abrufen und entfernen;
Schnitt-, Vereinigungs- und Differenzoperationen berechnen; B. Schnittmenge, kann die Fan-Listen von zwei Personen zu einer Schnittmenge kombinieren ob ein Schlüssel vorhanden ist
Strukturierte Daten, z. B. ein Objekt
Nach Bewertungsbereich oder Mitglied Elementen abrufen;
Die Rangfolge eines Schlüssels berechnen
Deduplizierung, kann aber sortiert werden, z. B. um die Top-Benutzer zu erhalten
DatenspeichertypAbfrage [Operation ] Typ 1. Multithread-Dienstunterstützung1. Threaded, nicht blockierender IO-ModusAeEventLibEvent1. RDB 2. AOFNicht unterstütztCluster-Modus Nativ Unterstützt den Cluster-Modus, Sie können Master-Slave-Replikation und Lese-/Schreib-Trennung realisierenIn Redis werden nicht alle Daten immer im Speicher gespeichert, und einige Werte, die längere Zeit nicht verwendet wurden, können auf der Festplatte ausgetauscht werden. Memcached-Daten werden immer im Speicher gespeichert in Blöcke bestimmter Längen zum Speichern von Daten, um das Problem der Speicherfragmentierung vollständig zu lösen. Diese Methode führt jedoch zu einer geringen Speicherauslastung. Wenn die Blockgröße beispielsweise 128 Byte beträgt und nur 100 Byte Daten gespeichert werden, werden die restlichen 28 Byte verschwendet. Komplexe Datenstruktur, Persistenz, hohe Verfügbarkeitsanforderungen, großer SpeicherinhaltReiner Schlüsselwert, sehr große Datenmenge, sehr großes ParallelitätsgeschäftWenn Ihr System nicht unbedingt eine Konsistenz des Caches und der Datenbank erfordert, ist es am besten, diese Lösung nicht zu serialisieren In eine Speicherwarteschlange gestellt, um sicherzustellen, dass es nach der Serialisierung nicht zu Inkonsistenzen kommt, wird der Durchsatz des Systems erheblich reduziert und es werden um ein Vielfaches mehr Maschinen verwendet als unter normalen Umständen.
Vergleichsparameter
redis memcached
Speicher 2. Nicht relationale Datenbank 1 2. Schlüssel-Wert-Paar Form 3. Cache-Formular
1. Liste 3. Satz 4. Hash 5. Sortiersatz [allgemein bekannt als ZSet] 1. Texttyp 2. Binärtyp
1. Stapelbetrieb 2. Transaktionsunterstützung 3. Unterschiedliches CRUD für jeden Typ 1. Häufig verwendetes CRUD 2. Eine kleine Anzahl anderer Befehle 1. Veröffentlichungs-/Abonnementmodus 2. Master-Slave-Partition 3. Serialisierungsunterstützung 4. Skriptunterstützung [Lua-Skript]
Netzwerk-IO-Modell Single-Threaded-Mehrkanal-IO-Wiederverwendungsmodell

Event-Bibliothek

Persistenzunterstützung


Es gibt keinen nativen Cluster-Modus, Sie müssen sich darauf verlassen, dass der Client Daten in Shards im Cluster schreibt

Speicherverwaltungsmechanismus

Anwendbare Szenarien

(1) Alle Werte in Memcached sind einfache Zeichenfolgen. Als Ersatz unterstützt Redis umfangreichere Datentypen. (2) Redis ist viel schneller als Memcached. (3) Redis kann seine Daten beibehalten. So stellen Sie die Datenkonsistenz beim doppelten Schreiben sicher zwischen Cache und Datenbank?
Solange Sie den Cache verwenden, kann es zu doppelter Speicherung und doppeltem Schreiben von Cache und Datenbank kommen. Solange Sie doppeltes Schreiben verwenden, wird es definitiv Probleme mit der Datenkonsistenz geben.
Es gibt eine andere Möglichkeit, bei der vorübergehende Inkonsistenzen auftreten können, aber die Wahrscheinlichkeit des Auftretens ist sehr gering:

Aktualisieren Sie zuerst die Datenbank und löschen Sie dann den Cache

.

Problem -Szenario

Description

Solution

First den Cache schreiben und dann in die Datenbank schreiben, der Cache -Schreiben ist erfolgreich, die Datenbankschreibfehler fehl , aber das Schreiben in die Datenbank schlägt fehl oder wenn die Antwort verzögert wird, erfolgt beim nächsten Lesen des Caches ein Dirty Read (gleichzeitiges Lesen). Diese Methode zum Schreiben des Caches ist an sich falsch Zuerst in die Datenbank schreiben und den alten Cache ungültig machen. Wenn der Cache zu diesem Zeitpunkt nicht vorhanden ist, lesen Sie die Datenbank und schreiben Sie dann in den Cache. Schreiben Sie zuerst in die Datenbank und dann in den Cache erfolgreich, aber das Schreiben in den Cache schlägt fehl bezieht sich auf den Datenbankvorgang und den Schreibcache Der Cache kann nicht gleichzeitig geschrieben werden oder es ist eine asynchrone Aktualisierung erforderlich (Abhilfemaßnahmen). Bestimmen Sie, welche Daten für solche Szenarien geeignet sind. Bestimmen Sie eine angemessene Dateninkonsistenzzeit basierend auf Erfahrungswerten und aktualisieren Sie die Benutzerdaten im Zeitintervall

Redis häufige Leistungsprobleme und Lösungen?

1. Master sollte am besten keine Persistenzarbeiten durchführen, einschließlich Speicher-Snapshots und AOF-Protokolldateien, insbesondere keine Speicher-Snapshots für die Persistenz aktivieren.

2. Wenn die Daten kritisch sind, aktiviert ein Slave die AOF-Datensicherung und die Strategie besteht darin, einmal pro Sekunde zu synchronisieren.

3. Für die Geschwindigkeit der Master-Slave-Replikation und die Stabilität der Verbindung ist es am besten, wenn sich Slave und Master im selben LAN befinden.

4. Vermeiden Sie das Hinzufügen von Slave-Bibliotheken zur überlasteten Hauptbibliothek.

5. Der Master-Aufruf zum Neuschreiben der AOF-Datei führt zu einer hohen Auslastung des Dienstes hoch. Es kommt zu einer kurzen Dienstunterbrechung.

6. Um die Stabilität des Masters zu gewährleisten, verwenden Sie keine Diagrammstruktur für die Master-Slave-Replikation. Es ist stabiler, eine einseitig verknüpfte Listenstruktur zu verwenden, das heißt, die Master-Slave-Beziehung ist: Master<–. Slave1<–Slave2<–Slave3…. Diese Struktur ist auch praktisch, um das Single-Point-of-Failure-Problem zu lösen und den Master durch den Slave zu ersetzen. alles andere unverändert lassen.

Warum stellt Redis offiziell keine Windows-Version zur Verfügung?

Da die aktuelle Linux-Version recht stabil ist und eine große Anzahl von Benutzern hat, besteht keine Notwendigkeit, eine Windows-Version zu entwickeln, was zu Kompatibilitäts- und anderen Problemen führen würde.

Was ist die maximale Kapazität, die ein String-Typ-Wert speichern kann?

512M

Wie führt Redis große Datenmengen ein?

Ab Redis 2.6 unterstützt redis-cli einen neuen Modus namens Pipe-Modus für die Durchführung großer Datenmengen.

Angenommen, es gibt 100 Millionen Schlüssel in Redis und 100.000 davon beginnen mit einem festen, bekannten Präfix. Wie findet man sie alle?

Verwenden Sie den Befehl „keys“, um die Schlüsselliste des angegebenen Musters zu scannen.

Die andere Partei fragte dann: Wenn dieser Redis Dienste für Online-Unternehmen bereitstellt, welche Probleme gibt es bei der Verwendung des Tastenbefehls?

Zu diesem Zeitpunkt müssen Sie eine Schlüsselfunktion von Redis beantworten: das Single-Threading von Redis. Die Schlüsselanweisung führt dazu, dass der Thread für einen bestimmten Zeitraum blockiert wird und der Onlinedienst angehalten wird. Der Dienst kann erst wiederhergestellt werden, wenn die Anweisung ausgeführt wird. Zu diesem Zeitpunkt können Sie den Scan-Befehl verwenden, um die Schlüsselliste des angegebenen Modus zu extrahieren, es besteht jedoch eine gewisse Wahrscheinlichkeit einer Duplizierung. Führen Sie dies jedoch nur einmal auf dem Client aus, dies wird jedoch insgesamt der Fall sein länger sein als die direkte Verwendung. Der Tastenbefehl ist lang.

Haben Sie Redis jemals verwendet, um eine asynchrone Warteschlange zu erstellen?

Verwenden Sie den Listentyp, um Dateninformationen zu speichern. rpush erzeugt Nachrichten und lpop verbraucht Nachrichten. Wenn Sie keine Nachrichten haben, können Sie eine Zeit lang schlafen und dann prüfen, ob Informationen vorhanden sind Wenn Sie schlafen möchten, können Sie blpop verwenden. Wenn keine Informationen vorliegen, bleibt es blockiert, bis die Informationen eintreffen. Redis kann über das Pub/Sub-Topic-Abonnementmodell einen Produzenten und mehrere Konsumenten implementieren. Natürlich gibt es bestimmte Nachteile, wenn der Konsument offline geht.

Wie implementiert Redis die Verzögerungswarteschlange?

Verwenden Sie sortedset, verwenden Sie den Zeitstempel als Bewertung, den Nachrichteninhalt als Schlüssel, rufen Sie zadd auf, um Nachrichten zu erstellen, und der Verbraucher verwendet zrangbyscore, um Daten vor n Sekunden für die Abfrageverarbeitung abzurufen.

Wie funktioniert der Redis-Recyclingprozess?

1. Ein Client hat einen neuen Befehl ausgeführt und neue Daten hinzugefügt.

2. Redis überprüft die Speichernutzung, wenn sie größer als das Limit von maxmemory ist, wird sie gemäß der festgelegten Strategie recycelt.

3. Ein neuer Befehl wird ausgeführt usw.

4. Wir überschreiten also ständig die Grenze der Speichergrenze, indem wir ständig die Grenze erreichen und dann kontinuierlich unter die Grenze zurückkehren.

Wenn das Ergebnis eines Befehls dazu führt, dass viel Speicher beansprucht wird (z. B. das Speichern der Schnittmenge einer großen Menge in einem neuen Schlüssel), dauert es nicht lange, bis das Speicherlimit durch diese Speichernutzung überschritten wird .

Welcher Algorithmus wird für das Redis-Recycling verwendet?

LRU-Algorithmus

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

Der Schreibvorgang in die Datenbank ist erfolgreich, aber das Schreiben in den Cache schlägt fehl. Lesen Sie dann das nächste Mal (beim gleichzeitigen Lesen) den Cache, die Daten können nicht gelesen werden
Wenn der Cache verwendet wird, Wenn der Lesecache fehlschlägt, wird die Datenbank zuerst gelesen und dann in den Cache zurückgeschrieben. Die Implementierung erfordert eine asynchrone Cache-Aktualisierung.

Das obige ist der detaillierte Inhalt vonRedis-Hochfrequenz-Interviewfragen (mit Antwortanalyse). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Verwandte Etiketten:
Quelle:csdn.net
Erklärung dieser Website
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
Beliebte Tutorials
Mehr>
Neueste Downloads
Mehr>
Web-Effekte
Quellcode der Website
Website-Materialien
Frontend-Vorlage