Auf dieser Seite finden Sie eine Anleitung zur optimalen Verwendung von Memorystore for Redis Cluster. Diese Seite weist auch auf mögliche Probleme hin.
Best Practices für die Speicherverwaltung
In diesem Abschnitt werden Strategien zum Verwalten des Instanzspeichers beschrieben, damit Memorystore for Redis Cluster effizient für Ihre Anwendung funktioniert.
Konzepte zur Speicherverwaltung
Schreiblast: Das Volumen und die Geschwindigkeit, mit der Sie Schlüssel in Ihrem Redis-Cluster hinzufügen oder aktualisieren. Die Schreiblast kann je nach Redis-Anwendungsfall und Nutzungsmuster der Anwendung zwischen normal und sehr hoch liegen.
Entfernungsrichtlinie: Memorystore for Redis-Cluster verwendet die
volatile-lru-Entfernungsrichtlinie. Mit Befehlen wie EXPIRE können Sie Löschungen für Schlüssel festlegen.
Cluster mit normaler Schreiblast überwachen
Sehen Sie sich den Messwert /cluster/memory/maximum_utilization an. Wenn /cluster/memory/maximum_utilization bei 100% oder darunter liegt, funktioniert Ihr Redis-Cluster bei normaler Schreiblast gut.
Wenn Ihre Speichernutzung jedoch 100% erreicht und Sie mit einem Anstieg der Datennutzung rechnen, sollten Sie die Clustergröße erhöhen, um Platz für neue Daten zu schaffen.
Cluster mit hoher Schreiblast überwachen
Sehen Sie sich den Messwert /cluster/memory/maximum_utilization an. Je nach Schweregrad der hohen Schreiblast können in Ihrem Cluster bei den folgenden Grenzwerten Leistungsprobleme auftreten:
Bei sehr hohen Schreiblasten kann es zu Problemen kommen, wenn
/cluster/memory/maximum_utilization65% oder mehr erreicht.Bei mäßig hoher Schreiblast können Probleme auftreten, wenn
/cluster/memory/maximum_utilization85% oder mehr erreicht.
In diesen Fällen sollten Sie die Clustergröße erhöhen, um die Leistung zu verbessern.
Wenn Probleme auftreten oder Sie befürchten, dass Ihre Instanz eine hohe Schreiblast hat, wenden Sie sich an den Google Cloud Support.
Shards skalieren
Wenn Sie die Anzahl der Shards in einer Instanz skalieren, sollten Sie dies in Zeiten geringer Schreibvorgänge tun. Die Skalierung in Zeiten hoher Schreiblast kann den Arbeitsspeicher Ihrer Instanz aufgrund des durch die Replikation oder Slot-Migration verursachten Speicheraufwands belasten.
Wenn in Ihrem Redis-Anwendungsfall Schlüssel entfernt werden, kann das Skalieren auf eine kleinere Clustergröße das Cache-Trefferverhältnis verringern. In diesem Fall müssen Sie sich jedoch keine Sorgen um Datenverlust machen, da das Entfernen von Schlüsseln erwartet wird.
Bei Redis-Anwendungsfällen, in denen Sie keine Schlüssel verlieren möchten, sollten Sie nur auf einen kleineren Cluster herunterskalieren, der noch genügend Speicherplatz für Ihre Daten bietet. Die neue Anzahl der Ziel-Shards sollte mindestens das 1,5-Fache des von Daten verwendeten Arbeitsspeichers betragen. Mit anderen Worten: Sie sollten genügend Shards für das 1,5-fache der Daten bereitstellen, die sich derzeit in Ihrem Cluster befinden. Mit dem Messwert /cluster/memory/total_used_memory können Sie sehen, wie viele Daten in Ihrer Instanz gespeichert sind.
Best Practices für die CPU-Nutzung
Wenn ein unerwarteter Zonenausfall auftritt, führt dies zu weniger CPU-Ressourcen für Ihren Cluster, da die Kapazität von Knoten in der nicht verfügbaren Zone verloren geht. Wir empfehlen die Verwendung von Clustern mit Hochverfügbarkeit. Wenn Sie zwei Replikate pro Shard verwenden (im Gegensatz zu einem Replikat pro Shard), stehen während eines Ausfalls zusätzliche CPU-Ressourcen zur Verfügung. Außerdem empfehlen wir, die CPU-Nutzung von Knoten so zu verwalten, dass Knoten genügend CPU-Overhead haben, um zusätzlichen Traffic aufgrund von verloren gegangener Kapazität zu verarbeiten, falls es zu einem unerwarteten zonalen Ausfall kommt. Sie sollten die CPU-Nutzung für primäre Instanzen und Replikate mit dem Messwert /cluster/cpu/maximum_utilization überwachen.
Je nachdem, wie viele Replikate Sie pro Knoten bereitstellen, empfehlen wir die folgenden /cluster/cpu/maximum_utilization-CPU-Auslastungsziele:
- Bei Instanzen mit einem Replikat pro Knoten sollte ein
/cluster/cpu/maximum_utilization-Wert von 0,5 Sekunden für die primäre Instanz und 0,5 Sekunden für das Replikat angestrebt werden, wenn das Replikat als Lesereplikat festgelegt ist. - Bei Instanzen mit zwei Replikaten pro Knoten sollte der
/cluster/cpu/maximum_utilization-Wert für das primäre Replikat 0,8 Sekunden und für jedes Replikat 0,5 Sekunden betragen.
Wenn die Werte für den Messwert diese Empfehlungen überschreiten, empfehlen wir, die Anzahl der Shards oder Replikate in Ihrer Instanz zu erhöhen.
Ressourcenintensive Redis-Befehle
Wir empfehlen dringend, ressourcenintensive Redis-Befehle zu vermeiden. Die Verwendung dieser Befehle kann zu den folgenden Leistungsproblemen führen:
- Hohe Latenz und Client-Zeitüberschreitungen
- Arbeitsspeichermangel durch Befehle, die die Arbeitsspeichernutzung erhöhen
- Datenverlust während der Knotenreplikation und ‑synchronisierung, weil der Redis-Hauptthread blockiert ist
- Systemdiagnosen, Beobachtbarkeit und Replikation
In der folgenden Tabelle finden Sie Beispiele für ressourcenintensive Redis-Befehle und ressourcenschonende Alternativen.
| Kategorie | Ressourcenintensiver Befehl | Ressourcenschonende Alternative |
|---|---|---|
| Für den gesamten Schlüsselbereich ausführen | KEYS |
SCAN |
| Für einen Schlüsselsatz mit variabler Länge ausführen | LRANGE |
Begrenzen Sie die Größe des Bereichs, den Sie für eine Abfrage verwenden. |
ZRANGE |
Begrenzen Sie die Größe des Bereichs, den Sie für eine Abfrage verwenden. | |
HGETALL |
HSCAN |
|
SMEMBERS |
SSCAN |
|
| Ausführung eines Skripts blockieren | EVAL |
Achten Sie darauf, dass Ihr Script nicht unbegrenzt ausgeführt wird. |
EVALSHA |
Achten Sie darauf, dass Ihr Script nicht unbegrenzt ausgeführt wird. | |
| Dateien und Links entfernen | DELETE |
UNLINK |
| Veröffentlichen und abonnieren | PUBLISH |
SPUBLISH |
SUBSCRIBE |
SSUBSCRIBE |
Best Practices für Redis-Clients
Ihre Anwendung muss einen Cluster-kompatiblen Redis-Client verwenden, wenn sie eine Verbindung zu einer Memorystore for Redis Cluster-Instanz herstellt. Beispiele für clusterfähige Clients und Beispielkonfigurationen finden Sie unter Codebeispiele für Clientbibliotheken. Ihr Client muss eine Zuordnung von Hash-Slots zu den entsprechenden Knoten im Cluster verwalten, um Anfragen an die richtigen Knoten zu senden und den Leistungsaufwand zu vermeiden, der durch Clusterumleitungen entsteht.
Clientzuordnung
Kunden müssen in den folgenden Situationen eine vollständige Liste der Slots und der zugeordneten Knoten abrufen:
Wenn der Client initialisiert wird, muss er die Zuordnung von Slots zu Knoten festlegen.
Wenn vom Server eine
MOVED-Weiterleitung empfangen wird, z. B. bei einem Failover, wenn alle Slots, die vom ehemaligen primären Knoten bereitgestellt wurden, vom Replikat übernommen werden, oder beim Resharding, wenn Slots vom primären Quellknoten zum primären Zielknoten verschoben werden.Wenn vom Server ein
CLUSTERDOWN-Fehler empfangen wird oder Verbindungen zu einem bestimmten Server immer wieder Zeitüberschreitungen verursachen.Wenn vom Server ein
READONLY-Fehler empfangen wird. Das kann passieren, wenn eine primäre Instanz zu einem Replikat herabgestuft wird.Außerdem sollten Clients die Topologie regelmäßig aktualisieren, um für Änderungen gerüstet zu sein und Änderungen zu erkennen, die nicht zu Weiterleitungen oder Fehlern vom Server führen, z. B. wenn neue Replikatknoten hinzugefügt werden. Beachten Sie, dass alle alten Verbindungen im Rahmen der Topologieaktualisierung geschlossen werden sollten, um die Notwendigkeit zu verringern, fehlgeschlagene Verbindungen während der Befehlsausführung zu behandeln.
Clientermittlung
Die Client-Erkennung erfolgt in der Regel durch Ausführen des Befehls CLUSTER SLOT, CLUSTER NODE oder CLUSTER SHARDS auf dem Redis-Server. Wir empfehlen die Verwendung des Befehls CLUSTER SHARDS. CLUSTER SHARDS ersetzt den Befehl CLUSTER SLOTS (eingestellt) und bietet eine effizientere und erweiterbare Darstellung des Clusters.
Die Größe der Antwort für die Befehle zur Cluster-Client-Erkennung kann je nach Clustergröße und ‑topologie variieren. Größere Cluster mit mehr Knoten führen zu einer größeren Antwort. Daher ist es wichtig, dass die Anzahl der Clients, die die Cluster-Topologie ermitteln, nicht unbegrenzt wächst.
Diese Topologieaktualisierungen sind auf dem Redis-Server ressourcenintensiv, aber auch wichtig für die Anwendungsverfügbarkeit. Daher ist es wichtig, dass jeder Client zu einem bestimmten Zeitpunkt nur eine Discovery-Anfrage stellt (und das Ergebnis im Arbeitsspeicher zwischenspeichert) und die Anzahl der Clients, die die Anfragen stellen, begrenzt wird, um eine Überlastung des Servers zu vermeiden.
Wenn die Clientanwendung beispielsweise gestartet wird oder die Verbindung zum Server verliert und eine Clustererkennung durchführen muss, ist ein häufiger Fehler, dass die Clientanwendung mehrere Wiederverbindungs- und Erkennungsanfragen sendet, ohne beim Wiederholen exponentiellen Backoff hinzuzufügen. Dadurch kann der Redis-Server für längere Zeit nicht mehr reagieren und eine sehr hohe CPU-Auslastung verursachen.
Überlastung der Erkennung auf Redis vermeiden
Um die Auswirkungen eines plötzlichen Anstiegs von Verbindungs- und Erkennungsanfragen zu minimieren, empfehlen wir Folgendes:
Implementieren Sie einen Clientverbindungspool mit einer endlichen und kleinen Größe, um die Anzahl der gleichzeitigen eingehenden Verbindungen von der Clientanwendung zu begrenzen.
Wenn die Verbindung des Clients zum Server aufgrund eines Zeitlimits getrennt wird, versuchen Sie es noch einmal mit exponentiellem Backoff mit Jitter. So wird verhindert, dass mehrere Clients den Server gleichzeitig überlasten.
Verwenden Sie den Memorystore for Redis Cluster-Erkennungsendpunkt, um die Clustererkennung durchzuführen. Der Discovery-Endpunkt ist hochverfügbar und wird auf alle Knoten im Cluster verteilt. Außerdem versucht der Discovery-Endpunkt, die Clustererkennungsanfragen an Knoten mit der aktuellsten Topologieansicht weiterzuleiten.
Best Practices für die Persistenz
In diesem Abschnitt werden Best Practices für die Persistenz erläutert.
RDB-Persistenz und Hinzufügen von Replikaten
Wenn Sie Ihre Instanz mit RDB-Snapshots sichern oder Replikate hinzufügen möchten, sollten Sie die folgenden Best Practices beachten:
Speicherverwaltung
Bei RDB-Snapshots wird ein Prozess-Fork und ein Copy-on-Write-Mechanismus verwendet, um einen Snapshot der Knotendaten zu erstellen. Je nach Muster der Schreibvorgänge für Knoten wächst der verwendete Speicher der Knoten, da die von den Schreibvorgängen betroffenen Seiten kopiert werden. Der Speicherbedarf kann bis zu doppelt so groß sein wie die Daten im Knoten.
Damit Knoten genügend Arbeitsspeicher für die Erstellung des Snapshots haben, sollte maxmemory auf 80% der Knotenkapazität festgelegt werden. So sind 20% für den Mehraufwand reserviert. Dieser zusätzliche Arbeitsspeicher hilft Ihnen zusammen mit der Überwachung von Snapshots, Ihre Arbeitslast so zu verwalten, dass Snapshots erfolgreich erstellt werden. Wenn Sie Replikate hinzufügen, sollten Sie außerdem den Schreibtraffic so weit wie möglich reduzieren. Weitere Informationen finden Sie unter Cluster mit hoher Schreiblast überwachen.
Veraltete Snapshots
Das Wiederherstellen von Knoten aus einem alten Snapshot kann zu Leistungsproblemen bei Ihrer Anwendung führen, da versucht wird, eine große Anzahl alter Schlüssel oder andere Änderungen an Ihrer Datenbank, z. B. eine Schemaänderung, abzugleichen. Wenn Sie Bedenken haben, dass Sie einen alten Snapshot wiederherstellen, können Sie die RDB-Persistenzfunktion deaktivieren. Sobald Sie die Persistenz wieder aktivieren, wird beim nächsten geplanten Snapshot-Intervall ein Snapshot erstellt.
Auswirkungen von RDB-Snapshots auf die Leistung
Je nach Arbeitslastmuster können RDB-Snapshots die Leistung der Instanz beeinträchtigen und die Latenz für Ihre Anwendungen erhöhen. Sie können die Auswirkungen von RDB-Snapshots auf die Leistung minimieren, indem Sie sie für Zeiträume mit geringem Instanz-Traffic planen, wenn Sie mit weniger häufigen Snapshots zufrieden sind.
Wenn Ihre Instanz beispielsweise zwischen 1:00 und 4:00 Uhr nur wenig Traffic hat, können Sie die Startzeit auf 3:00 Uhr und das Intervall auf 24 Stunden festlegen.
Wenn Ihr System eine konstante Last hat und häufige Snapshots erforderlich sind, sollten Sie die Auswirkungen auf die Leistung sorgfältig prüfen und die Vorteile der Verwendung von RDB-Snapshots für die Arbeitslast abwägen.
Replikat hinzufügen
Zum Hinzufügen eines Replikats ist ein RDB-Snapshot erforderlich. Weitere Informationen zu RDB-Snapshots finden Sie unter Arbeitsspeicherverwaltung.
Instanz in einer einzelnen Zone auswählen, wenn Ihre Instanz keine Replikate verwendet
Wenn Sie eine Instanz ohne Replikate konfigurieren, empfehlen wir eine Architektur mit einer einzelnen Zone, um die Zuverlässigkeit zu verbessern. Das kann folgende Gründe haben:
Auswirkungen von Ausfällen minimieren
Zonale Ausfälle wirken sich weniger wahrscheinlich auf Ihre Instanz aus. Wenn Sie alle Knoten in einer einzigen Zone platzieren, sinkt die Wahrscheinlichkeit, dass ein Zonenausfall Ihren Server beeinträchtigt, von 100% auf 33%. Das liegt daran, dass die Wahrscheinlichkeit, dass die Zone, in der sich Ihre Instanz befindet, ausfällt, 33% beträgt. Die Wahrscheinlichkeit, dass Knoten in der nicht verfügbaren Zone betroffen sind, beträgt dagegen 100 %.
Schnelle Erholung
Sollte ein Zonenausfall auftreten, wird die Wiederherstellung optimiert. Sie können reagieren, indem Sie schnell eine neue Instanz in einer funktionierenden Zone bereitstellen und Ihre Anwendung umleiten, um den Betrieb möglichst wenig zu unterbrechen.
Best Practices für Lettuce
In diesem Abschnitt werden Best Practices für die Verwendung von Lettuce zum Herstellen einer Verbindung zu einer Memorystore for Redis Cluster-Instanz beschrieben.
Parameterwerte aktualisieren
Wenn Sie Lettuce verwenden, ändern Sie den Parameter validateClusterNodeMembership in false. Andernfalls können bei Änderungen an der Topologie unknownPartition-Fehler auftreten.