Auf dieser Seite finden Sie eine Anleitung zur optimalen Verwendung von Memorystore for Redis Cluster. Außerdem werden potenzielle Probleme aufgeführt, die Sie vermeiden sollten.
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-lruEntfernungsrichtlinie. Mit Befehlen wie EXPIRE können Sie Entfernungen für Schlüssel festlegen.
Cluster mit normaler Schreiblast beobachten
Sehen Sie sich den /cluster/memory/maximum_utilization Messwert an. Wenn /cluster/memory/maximum_utilization bei 100% oder darunter liegt, funktioniert Ihr Redis-Cluster bei normaler Schreiblast gut.
Wenn sich die Arbeitsspeichernutzung jedoch 100% nähert und Sie mit einer Zunahme der Datennutzung rechnen, sollten Sie die Clustergröße erhöhen, um Platz für neue Daten zu schaffen.
Cluster mit hoher Schreiblast beobachten
Sehen Sie sich den /cluster/memory/maximum_utilization Messwert an. Je nach Schweregrad der hohen Schreiblast können bei den folgenden Schwellenwerten Leistungsprobleme auftreten:
Bei sehr hoher Schreiblast können Probleme auftreten, 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 Schreiblast tun. Die Skalierung in Zeiten hoher Schreiblast kann den Arbeitsspeicher Ihrer Instanz aufgrund des durch die Replikation oder die Slotmigration verursachten Speicheraufwands belasten.
Wenn in Ihrem Redis-Anwendungsfall Schlüssel entfernt werden, kann die Skalierung auf eine kleinere Clustergröße die Cache-Trefferquote 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 Platz für Ihre Daten bietet. Die neue Zielshardanzahl sollte mindestens das 1,5-fache des von den Daten verwendeten Arbeitsspeichers betragen.
Mit anderen Worten: Sie sollten genügend Shards für das 1, 5-fache der Datenmenge in Ihrem Cluster bereitstellen. Mit dem /cluster/memory/total_used_memory Messwert können Sie sehen, wie viele Daten in
Ihrer Instanz gespeichert sind.
Best Practices für die CPU-Nutzung
Wenn ein unerwarteter zonaler Ausfall auftritt, führt dies zu weniger CPU-Ressourcen für Ihren Cluster, da die Kapazität der Knoten in der nicht verfügbaren Zone verloren geht. Wir empfehlen die Verwendung von hochverfügbaren Clustern. Wenn Sie mehrere Replikate pro Shard verwenden (im Gegensatz zu einem Replikat pro Shard), stehen bei einem Ausfall zusätzliche CPU-Ressourcen zur Verfügung. Sie können bis zu fünf Replikate pro Shard haben.
Außerdem empfehlen wir, die CPU-Nutzung der Knoten so zu verwalten, dass die Knoten genügend CPU-Overhead haben, um zusätzlichen Traffic aufgrund von Kapazitätsverlusten bei einem unerwarteten zonalen Ausfall zu verarbeiten. Sie sollten die CPU-Nutzung für primäre Knoten und Replikate mit
dem Messwert „CPU-Sekunden des Hauptthreads“ /cluster/cpu/maximum_utilization beobachten.
Je nach Anzahl der Replikate, die Sie pro Knoten bereitstellen, empfehlen wir die folgenden Ziele für die CPU-Nutzung /cluster/cpu/maximum_utilization:
- Bei Instanzen mit einem Replikat pro Knoten sollten Sie einen Wert von
/cluster/cpu/maximum_utilizationvon 0,5 Sekunden für den primären Knoten und 0,5 Sekunden für das Replikat anstreben. - Bei Instanzen mit zwei oder mehr Replikaten pro Knoten sollten Sie einen Wert von
/cluster/cpu/maximum_utilizationvon 0,9 Sekunden für den primären Knoten und 0,5 Sekunden für jedes Replikat anstreben.
Wenn die Werte für den Messwert diese Empfehlungen überschreiten, empfehlen wir, die Anzahl der Shards in Ihrer Instanz zu erhöhen. Wenn Sie weniger als fünf Replikate für Ihre Instanz haben, können Sie auch die Anzahl der Replikate auf maximal fünf erhöhen.
Ressourcenintensive Redis-Befehle
Wir empfehlen dringend, keine ressourcenintensiven Redis-Befehle zu verwenden. Die Verwendung dieser Befehle kann zu den folgenden Leistungsproblemen führen:
- Hohe Latenz und Client-Time-outs
- Speicherdruck aufgrund von Befehlen, die die Arbeitsspeichernutzung erhöhen
- Datenverlust bei der Knotenreplikation und -synchronisierung, weil der Redis-Hauptthread blockiert ist
- Zu wenige Ressourcen für Systemdiagnosen, Beobachtbarkeit und Replikation
In der folgenden Tabelle sind Beispiele für ressourcenintensive Redis-Befehle aufgeführt und ressourceneffiziente Alternativen genannt.
| Kategorie | Ressourcenintensiver Befehl | Ressourceneffiziente Alternative |
|---|---|---|
| Für den gesamten Schlüsselbereich ausführen | KEYS |
SCAN |
| Für einen Schlüsselbereich mit variabler Länge ausführen | LRANGE |
Beschränken Sie die Größe des Bereichs, den Sie für eine Abfrage verwenden. |
ZRANGE |
Beschränken 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 Skript nicht unbegrenzt ausgeführt wird. |
EVALSHA |
Achten Sie darauf, dass Ihr Skript nicht unbegrenzt ausgeführt wird. | |
| Dateien und Links entfernen | DEL |
UNLINK |
| Veröffentlichen und abonnieren | PUBLISH |
SPUBLISH |
SUBSCRIBE |
SSUBSCRIBE |
Best Practices für Redis-Clients
Ihre Anwendung muss einen clusterfähigen 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 Cluster-Weiterleitungen verursacht wird.
Clientzuordnung
Clients 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 anfängliche Zuordnung von Slots zu Knoten erstellen.
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 bei der erneuten Shard-Aufteilung, 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 dauerhaft zu Time-outs führen.Wenn vom Server ein
READONLY-Fehler empfangen wird. Dies kann passieren, wenn ein primärer Knoten zu einem Replikat herabgestuft wird.Außerdem sollten Clients die Topologie regelmäßig aktualisieren, um für Änderungen gerüstet zu sein und Informationen zu Änderungen zu erhalten, die nicht zu Weiterleitungen oder Fehlern vom Server führen, z. B. wenn neue Replikatknoten hinzugefügt werden. Außerdem sollten alle veralteten Verbindungen im Rahmen der Topologieaktualisierung geschlossen werden, um die Notwendigkeit zu verringern, fehlgeschlagene Verbindungen während der Befehlsausführung zu verarbeiten.
Clienterkennung
Die Clienterkennung erfolgt in der Regel durch Ausführen eines CLUSTER SLOT--, CLUSTER NODE- oder CLUSTER SHARDS-Befehls 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-Clienterkennung 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-Topologieerkennung durchführen, nicht unbegrenzt wächst.
Diese Topologieaktualisierungen sind auf dem Redis-Server ressourcenintensiv, aber auch wichtig für die Verfügbarkeit der Anwendung. Daher ist es wichtig, dass jeder Client jeweils nur eine Erkennungsanfrage stellt (und das Ergebnis im Arbeitsspeicher speichert) und die Anzahl der Clients, die die Anfragen stellen, begrenzt wird, um den Server nicht zu überlasten.
Wenn die Clientanwendung beispielsweise gestartet wird oder die Verbindung zum Server verliert und eine Clustererkennung durchführen muss, wird häufig der Fehler gemacht, dass die Client anwendung mehrere Anfragen zur Wiederherstellung der Verbindung und zur Erkennung stellt, ohne einen exponentiellen Backoff bei Wiederholungen hinzuzufügen. Dadurch kann der Redis-Server für längere Zeit nicht mehr reagieren und die CPU-Auslastung sehr hoch sein.
Überlastung bei der Redis-Erkennung vermeiden
Um die Auswirkungen eines plötzlichen Anstiegs von Verbindungs- und Erkennungsanfragen zu minimieren, empfehlen wir Folgendes:
Implementieren Sie einen Clientverbindungspool mit einer begrenzten 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 Time-outs getrennt wird, versuchen Sie es mit exponentiellem Backoff mit Jitter noch einmal. So wird verhindert, dass mehrere Clients den Server gleichzeitig überlasten.
Verwenden Sie den Memorystore for Redis Cluster-Erkennungsendpunkt, um die Clustererkennung durchzuführen. Der Erkennungsendpunkt ist hochverfügbar und wird auf alle Knoten im Cluster verteilt. Außerdem versucht der Erkennungsendpunkt, 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
Um Ihre Instanz optimal mit RDB-Snapshots zu sichern oder Replikate hinzuzufügen, empfehlen wir die folgenden Best Practices:
Speicherverwaltung
RDB-Snapshots verwenden eine Prozessverzweigung und einen „Copy-on-Write“-Mechanismus, um einen Snapshot der Knotendaten zu erstellen. Je nach Muster der Schreibvorgänge in Knoten wächst der verwendete Arbeitsspeicher der Knoten, da die von den Schreibvorgängen betroffenen Seiten kopiert werden. Der Speicherbedarf kann bis zu doppelt so groß wie die Datenmenge im Knoten sein.
Damit die Knoten genügend Arbeitsspeicher haben, um den Snapshot zu erstellen, behalten Sie
maxmemory bei 80% der
Knotenauslastung oder legen Sie diesen Wert fest, damit 20% für den Overhead reserviert sind. Dieser Speicher-Overhead hilft Ihnen zusätzlich zur Beobachtung von Snapshots, Ihre Arbeitslast so zu verwalten, dass Snapshots erfolgreich erstellt werden. Außerdem sollten Sie beim Hinzufügen von Replikaten den Schreibtraffic so weit wie möglich reduzieren. Weitere Informationen finden Sie unter Cluster mit hoher Schreiblast beobachten.
Veraltete Snapshots
Wenn Sie Knoten aus einem veralteten Snapshot wiederherstellen, kann dies zu Leistungsproblemen für Ihre Anwendung führen, da eine erhebliche Anzahl veralteter Schlüssel oder andere Änderungen an Ihrer Datenbank, z. B. eine Schemaänderung, abgeglichen werden müssen. Wenn Sie Bedenken haben, dass die Wiederherstellung aus einem veralteten Snapshot Probleme verursacht, können Sie die RDB-Persistenzfunktion deaktivieren. Sobald Sie die Persistenz wieder aktivieren, wird im 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 in Zeiten mit geringem Instanz-Traffic ausführen lassen, wenn Sie mit weniger häufigen Snapshots zufrieden sind.
Wenn Ihre Instanz beispielsweise von 1:00 Uhr bis 4:00 Uhr 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 Speicherverwaltung.
Wann sollte ein Cluster mit einer einzelnen Zone verwendet werden?
Wenn Sie einen Cluster so konfigurieren, dass er keine Replikate verwendet, empfehlen wir die Verwendung eines Clusters mit einer einzelnen Zone. Das kann folgende Gründe haben:
Kosten und Leistung
Wenn es Ihnen in erster Linie darum geht, Kosten zu minimieren und eine maximale Leistung für Ihre Clients in derselben Region zu erzielen, empfehlen wir einen Cluster mit einer einzelnen Zone.
Auswirkungen von Ausfällen minimieren
Wenn Sie einen Cluster mit einer einzelnen Zone auswählen, ist es weniger wahrscheinlich, dass zonale Ausfälle Ihren Cluster beeinträchtigen. Wenn Sie alle Knoten in einer einzelnen Zone platzieren, sinkt die Wahrscheinlichkeit, dass ein zonaler Ausfall Ihren Server beeinträchtigt, von 100% auf 33%. Es besteht eine Wahrscheinlichkeit von 33 %, dass die Zone, in der sich Ihr Cluster befindet, ausfällt, im Gegensatz zu einer Wahrscheinlichkeit von 100 %, dass Knoten in der nicht verfügbaren Zone betroffen sind.
Schnelle Wiederherstellung
Wenn es bei einem Cluster mit einer einzelnen Zone zu einem zonalen Ausfall kommt, optimiert Memorystore for Redis Cluster die Wiederherstellung Ihrer Daten. Sie können schnell einen neuen Cluster in einer funktionierenden Zone bereitstellen und Ihre Anwendung umleiten, um Unterbrechungen so gering wie möglich zu halten.
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 erhalten Sie bei Änderungen an der Topologie möglicherweise unknownPartition-Fehler.
Transport Layer Security (TLS) aktivieren
In diesem Abschnitt werden die Sicherheitsvorteile und Auswirkungen auf die Leistung der Verwendung von Transport Layer Security (TLS) sowie Empfehlungen für die Aktivierung erläutert.
Sicherheitsvorteile
Durch die Verwendung von TLS profitieren Sie von den folgenden Sicherheitsvorteilen:
- Authentifizierung über Identity and Access Management (IAM): TLS verwendet diese Art der Authentifizierung, um vor Server-Spoofing-Angriffen wie Man-in-the-Middle-Angriffen zu schützen.
- Verschlüsselung während der Übertragung: Google CloudDie integrierte Verschlüsselung von schützt den Traffic im Google-Netzwerk auf Infrastrukturebene. Dazu müssen Sie jedoch sowohl den Host- als auch den Netzwerk-Stack von Google vertrauen. Diese Verschlüsselung ist zwar transparent und standardmäßig aktiviert, aber nicht Ende-zu-Ende. TLS hingegen verwendet die Verschlüsselung während der Übertragung auf der Anwendungsebene. Diese Ende-zu-Ende-Verschlüsselung bietet Ihnen mehr Kontrolle über Ihre Verschlüsselungsschlüssel und -prozesse.
- Schutz von Authentifizierungstokens: Wenn Sie die IAM Authentifizierung verwenden, minimiert die Aktivierung von TLS das Risiko, dass Ihre Authentifizierungstokens offengelegt und missbraucht werden.
Auswirkungen auf die Leistung
TLS wirkt sich auf folgende Weise auf die Leistung aus:
Verbindungen herstellen: Ein Client und ein Server, die eine TLS-Sitzung eingerichtet haben, können die Sitzung fortsetzen, ohne den ressourcenintensiven Prozess der Verbindungsherstellung zwischen Client und Server zu wiederholen. Durch die Aktivierung der TLS-Wiederaufnahme wird der Aufwand für die Verbindungsherstellung zwischen Client und Server reduziert.
Wenn Sie die TLS-Wiederaufnahme nicht einrichten, ist die Verbindungsherstellung ressourcenintensiv. Sowohl bei neuen als auch bei bestehenden Verbindungen können viele Verbindungen zwischen Client und Server zu Verbindungs-Time-outs führen. Dies kann einen Schneeballeffekt verursachen, da Memorystore for Redis Cluster versucht, Time-out-Verbindungen wiederherzustellen, wodurch die Ressourcen erhöht werden, die für die Verbindungsherstellung verwendet werden.
Daten verschlüsseln und entschlüsseln: Die Datenverschlüsselung und ‑entschlüsselung umfasst CPU-intensive Vorgänge, die sich sowohl auf den Client als auch auf den Server auswirken. Dies kann die Kapazität Ihres Clusters verringern und die Latenz des Clusters erhöhen.
Empfehlungen
Wenn Sie überlegen, ob Sie TLS aktivieren möchten, empfehlen wir, Ihre Sicherheitsrichtlinien zu prüfen und dabei die Vor- und Nachteile von TLS zu berücksichtigen. Wenn Sie TLS aktivieren, sollten Sie Folgendes beachten:
- Die Aktivierung der TLS-Wiederaufnahme reduziert den Aufwand für die Verbindungsherstellung. Eine Verbindung zwischen Client und Server ist nur für die erste Verbindung erforderlich. Eine plötzliche Erweiterung der Clustergröße des Clients kann jedoch zu einer kurzen Unterbrechung führen, die durch den ersten vollständigen Handshake jedes neuen Clienthosts verursacht wird.
- Obwohl einige Clientbibliotheken möglicherweise keine integrierten Steuerelemente zum Aktivieren von TLS bieten, können Sie benutzerdefinierten Code verwenden, um diese Funktion in Ihre Cluster zu integrieren.