Freigeben über

Entwicklung mit Azure Managed Redis (Vorschau)

  • Artikel

Verbindungsresilienz und Serverauslastung

Berücksichtigen Sie beim Entwickeln von Clientanwendungen die relevanten bewährten Methoden für die Verbindungsresilienz und die Verwaltung der Serverlast.

Berücksichtigen Sie mehr Schlüssel und kleinere Werte

Azure Managed Redis (Vorschau) funktioniert am besten mit kleineren Werten. Unterteilen Sie größere Datenblöcke in kleinere Blöcke, um die Daten auf mehrere Schlüssel zu verteilen. Weitere Informationen zur idealen Wertgröße finden Sie in diesem Artikel.

Große Anforderungen oder große Antworten

Eine große Anforderung oder eine große Antwort kann Timeouts verursachen. Nehmen Sie beispielsweise an, dass auf Ihrem Client ein Timeoutwert von einer Sekunde konfiguriert ist. Ihre Anwendung fordert (unter Verwendung derselben physischen Verbindung) zwei Schlüssel gleichzeitig an (z.B. „A“ und „B“). Die meisten Clients unterstützen das Pipelining für Anforderungen, wobei bei Anforderungen „A“ und „B“ nacheinander gesendet werden, ohne dass auf ihre Antworten gewartet wird. Der Server sendet die Antworten in der gleichen Reihenfolge zurück. Wenn die Antwort „A“ groß ist, kann sie den Großteil der Timeoutzeit für spätere Anforderungen verbrauchen.

Im folgenden Beispiel werden die Anforderungen „A“ und „B“ schnell an den Server gesendet. Der Server beginnt schnell mit dem Senden der Antworten „A“ und „B“. Aufgrund der Datenübertragungszeiten muss Antwort „B“ hinter Antwort „A“ warten und hat ein Timeout, obwohl der Server schnell geantwortet hat.

|-------- 1 Second Timeout (A)----------|
|-Request A-|
     |-------- 1 Second Timeout (B) ----------|
     |-Request B-|
            |- Read Response A --------|
                                       |- Read Response B-| (**TIMEOUT**)

Dieses Anforderungs-/Antwortszenario ist schwer zu messen. Sie könnten Ihren Clientcode für die Nachverfolgung von großen Anforderungen und Antworten instrumentieren.

Lösungen für große Antworten variieren, umfass aber unter anderem:

  • Optimieren Sie Ihre Anwendung für eine große Anzahl von kleinen Werten, statt für wenige große Werte.
  • Erhöhen Sie die Größe Ihrer VM, um höhere Bandbreitenkapazitäten zu erhalten.
    • Mehr Bandbreite auf ihrer Client- oder Server-VM kann die Datenübertragungszeiten für größere Antworten verringern.
    • Vergleichen Sie Ihre aktuelle Netzwerknutzung auf beiden Computern mit den Limits Ihrer aktuellen VM-Größe. Mehr Bandbreite nur auf dem Server oder nur auf dem Client ist möglicherweise nicht ausreichend.
  • Erhöhen Sie die Anzahl von Verbindungsobjekten, die Ihre Anwendung verwendet.
    • Verwenden Sie einen Roundrobinansatz, um Anforderungen über verschiedene Verbindungsobjekte auszuführen.

Verwenden Sie die Pipeline-Funktionen

Versuchen Sie, einen Redis-Client auszuwählen, der Redis-Pipelining unterstützt. Pipelining hilft Ihnen dabei, das Netzwerk effizient zu nutzen und den bestmöglichen Durchsatz zu erzielen.

Vermeiden aufwändiger Vorgänge

Einige der Redis-Vorgänge, wie z.B. der Befehl KEYS, sind speicherintensiv und sollte vermieden werden. Einige Hinweise zu zeitintensiven Befehlen finden Sie unter Zeitintensive Befehle.

Wählen Sie eine passende Ebene aus

Azure Managed Redis bietet arbeitsspeicheroptimierte, ausgewogene, für Compute optimierte und für Flash optimierte Ebenen. Weitere Informationen zum Auswählen einer Ebene finden Sie hier. Wir empfehlen Leistungstests durchzuführen, um die richtige Ebene zu wählen und die Verbindungseinstellungen zu überprüfen. Weitere Informationen finden Sie unter Leistungstests.

Auswählen eines geeigneten Verfügbarkeitsmodus

Azure Managed Redis bietet die Option, die Hochverfügbarkeitskonfiguration zu aktivieren oder zu deaktivieren. Wenn der Modus für Hochverfügbarkeit deaktiviert ist, werden die Daten Ihrer AMR-Instanz nicht repliziert, und somit wird Ihre Redis-Instanz während der Wartung nicht verfügbar sein. Alle Daten in der AMR-Instanz werden auch bei geplanter oder ungeplanter Wartung verloren gehen. Wir empfohlen, die Hochverfügbarkeit nur für Ihre Entwicklungs- oder Testworkloads zu deaktivieren. Die Leistung von Redis-Instanzen mit Hochverfügbarkeit könnte auch aufgrund der fehlenden Datenreplikation geringer sein, die für die Verteilung der Last zwischen primärem und Replikatdatenshard entscheidend ist.

Client in derselben Region wie die Redis-Instanz

Suchen Sie Ihre Cache-Instanz und Ihre Anwendung in der gleichen Region. Eine Verbindung mit einer Redis-Instanz in einer anderen Region herzustellen, kann die Latenz erheblich erhöhen und die Zuverlässigkeit reduzieren.

Sie können zwar eine Verbindung von außerhalb von Azure herstellen, es wird jedoch nicht empfohlen, insbesondere, wenn Sie Redis zum Beschleunigen der Anwendungs- oder Datenbankleistung verwenden. Wenn Sie Redis Server nur als einen Schlüssel-/Wertspeicher verwenden, ist Latenz möglicherweise kein Hauptaspekt.

Verwenden eines Hostnamens anstatt einer öffentlichen IP-Adresse

Die Ihrer AMR-Instanz zugewiesene öffentliche IP-Adresse kann sich durch einen Skalierungsvorgang oder eine Back-End-Verbesserung ändern. Wir empfehlen, sich auf den Hostnamen statt auf eine explizite öffentliche IP-Adresse zu verlassen.

Verwenden der TLS-Verschlüsselung

Azure Managed Redis erfordert standardmäßig mit TLS verschlüsselte Kommunikationen. Derzeit werden die TLS-Versionen 1.2 und 1.3 unterstützt. Wenn Ihre Clientbibliothek oder Ihr Tool TLS nicht unterstützt, ist das Aktivieren unverschlüsselter Verbindungen möglich.

Überwachen der Speicherauslastung, CPU-Nutzungsmetriken, Clientverbindungen und Netzwerkbandbreite

Wenn Sie eine Azure Managed Redis-Instanz in der Produktion verwenden, empfehlen wir das Festlegen von Warnungen für „Verwendeter Arbeitsspeicherprozentsatz“, „CPU“-Metriken und „Verbundene Clients“. Wenn diese Metriken konsistent über 75 % liegen, sollten Sie ihre Instanz auf einen größeren Arbeitsspeicher oder eine bessere Durchsatzebene skalieren. Siehe wann sie skaliert werden soll, um weitere Details zu erhalten.

Erwägen Sie, Datenpersistenz oder Datensicherung zu aktivieren

Redis ist standardmäßig für kurzlebige Daten ausgelegt, was bedeutet, dass Ihre Daten in seltenen Fällen aufgrund verschiedener Umstände wie Wartung oder Ausfälle verloren gehen können. Wenn Ihre Anwendung empfindlich auf Datenverlust reagiert, empfehlen wir, die Datenpersistenz oder regelmäßige Datensicherung mithilfe des Datenexportvorgangs zu aktivieren.

Das Feature Datenpersistenz ist so konzipiert, dass automatisch ein schneller Wiederherstellungspunkt für Daten bereitgestellt wird, wenn ein Cache ausfällt. Die schnelle Wiederherstellung wird durch Speichern der RDB- oder AOF-Datei auf einem verwalteten Datenträger ermöglicht, der in die Cache-Instanz eingebunden wird. Persistente Dateien auf dem Datenträger sind für Benutzer nicht zugänglich oder können von keiner anderen AMR-Instanz verwendet werden.

Viele Kunden möchten die Persistenz nutzen, um regelmäßige Sicherungen der Daten in ihrem Cache durchzuführen. Wir raten jedoch davon ab, Datenpersistenz auf diese Weise zu verwenden. Verwenden Sie stattdessen das Feature Importieren/Exportieren. Sie können Kopien von Daten im RDB-Format direkt in Ihr ausgewähltes Speicherkonto exportieren und den Datenexport mit der von Ihnen benötigten Frequenz auslösen. Diese exportierten Daten können dann in eine beliebige Redis-Instanz importiert werden. Der Export kann entweder über das Portal oder über die CLI, per PowerShell oder mithilfe von SDK-Tools ausgelöst werden.

Spezifische Anleitungen für die Clientbibliothek

Weitere Informationen finden Sie unter Azure Managed Redis-Clientbibliotheken

Zugehöriger Inhalt