Entwicklung

  • 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 Cache for Redis 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.

Schlüsselverteilung

Wenn Sie das Redis-Clustering verwenden möchten, lesen Sie zuerst Bewährte Methoden für Redis-Clustering mit Schlüsseln.

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

Verwenden Sie die Tarife Standard, Premium, Enterprise oder Enterprise Flash für Produktionssysteme. Verwenden Sie die Basic-Ebene nicht in der Produktion. Der Basic-Tarif ist ein System mit einem einzelnen Knoten, ohne Datenreplikation und ohne SLA. Verwenden Sie mindestens einen C1-Cache. C0-Caches sind nur für einfache Entwicklungs-/Testszenarien vorgesehen, weil:

  • sie sich einen CPU-Kern teilen
  • sie wenig Arbeitsspeicher verwenden
  • sie anfällig für Probleme vom Typ Noisy Neighbor (laute Nachbarn) sind

Wir empfehlen Leistungstests durchzuführen, um die richtige Ebene zu wählen und die Verbindungseinstellungen zu überprüfen. Weitere Informationen finden Sie unter Leistungstests.

Der Client ist in derselben Region wie der Cache

Platzieren Sie Ihre Cache-Instanz und Ihre Anwendung in der gleichen Region. Eine Verbindung mit einem Cache in einer anderen Region herzustellen, kann zu einer beträchtlichen Latenz führen und die Zuverlässigkeit reduzieren.

Sie können zwar von außerhalb von Azure eine Verbindung herstellen, das ist jedoch nicht empfehlenswert, vor allem bei Verwendung von Redis als Cache. 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 ihrem Cache 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. Hier sind die empfohlenen Formulare für die verschiedenen Ebenen:

Tarif Formular
Basic, Standard und Premium <cachename>.redis.cache.windows.net
Enterprise, Enterprise Flash <DNS name>.<Azure region>.redisenterprise.cache.azure.net.

Auswählen einer geeigneten Redis-Version

Die Standardversion von Redis, die beim Erstellen eines Caches verwendet wird, kann sich im Laufe der Zeit ändern. Azure Cache for Redis kann eine neue Version übernehmen, wenn eine neue Version von Open-Source-Redis veröffentlicht wird. Wenn Sie eine bestimmte Version von Redis für Ihre Anwendung benötigen, empfehlen wir, die Redis-Version explizit auszuwählen, wenn Sie den Cache erstellen.

Spezifische Anleitungen für die Enterprise-Tarife

Da die Enterprise- und Enterprise Flash-Tarife auf Redis Enterprise und nicht auf Open-Source Redis basieren, gibt es einige Unterschiede bei den bewährten Methoden für die Entwicklung. Weitere Informationen finden Sie unter Bewährte Methoden für die Enterprise- und Enterprise Flash-Tarife.

Verwenden der TLS-Verschlüsselung

Azure Cache for Redis erfordert standardmäßig mit TLS verschlüsselte Kommunikationen. Derzeit werden die TLS-Versionen 1.0, 1.1 und 1.2 unterstützt. Die Unterstützung von TLS 1.0 und 1.1 wird jedoch branchenweit eingestellt werden. Verwenden Sie daher nach Möglichkeit TLS 1.2.

Wenn TLS von Ihrer Clientbibliothek oder Ihrem Tool nicht unterstützt wird, kann die Aktivierung unverschlüsselter Verbindungen über das Azure-Portal oder über Verwaltungs-APIs vorgenommen werden. Wenn verschlüsselte Verbindungen nicht möglich sind, empfiehlt es sich, den Cache und die Clientanwendung in ein virtuelles Netzwerk einzubinden. Weitere Informationen zu den im virtuellen Netzwerkcache-Szenario verwendeten Ports finden Sie in dieser Tabelle.

TLS-Zertifikatänderungen für Azure

Microsoft aktualisiert Azure-Dienste für die Verwendung von TLS-Serverzertifikaten aus einer anderen Gruppe von Zertifizierungsstellen (Certificate Authorities, CAs). Diese Änderung wird in Phasen zwischen 13. August 2020 und 26. Oktober 2020 (geschätzt) eingeführt. Diese Änderung wird in Azure vorgenommen, da die aktuellen Zertifikate der Zertifizierungsstellen eine der grundlegenden Anforderungen des Zertifizierungsstellen-/Browserforums nicht erfüllen. Das Problem wurde am 1. Juli 2020 gemeldet und gilt für mehrere beliebte PKI-Anbieter (Public Key-Infrastruktur) weltweit. Die meisten TLS-Zertifikate, die heute von Azure-Diensten verwendet werden, stammen aus der Baltimore CyberTrust Root-PKI. Der Azure Cache for Redis-Dienst wird weiterhin mit Baltimore CyberTrust Root verkettet. Seine TLS-Serverzertifikate werden jedoch ab 12. Oktober 2020 von neuen Zwischenzertifizierungsstellen (Intermediate Certificate Authorities, ICAs) ausgestellt.

Hinweis

Diese Änderung ist auf Dienste in öffentlichen Azure-Regionen beschränkt. Dies schließt unabhängige (z. B. China) oder Government Clouds aus.

Betrifft mich diese Änderung?

Die meisten Kunden von Azure Cache for Redis sind von der Änderung nicht betroffen. Ihre Anwendung kann betroffen sein, wenn darin explizit eine Liste zulässiger Zertifizierungsstellen angegeben wird, ein Verfahren, das als Anheften von Zertifikaten bezeichnet wird. Wenn das Zertifikat anstatt Baltimore CyberTrust Root ein Zwischen- oder Blattzertifikat als Grundlage verwendet, sollten Sie sofort Maßnahmen ergreifen, um die Zertifikatkonfiguration zu ändern.

Azure Cache for Redis unterstützt keine OCSP-Anheftung.

Die folgende Tabelle enthält Informationen zu den Zertifikaten, die umgestellt werden. Je nachdem, welches Zertifikat Ihre Anwendung verwendet, müssen Sie es möglicherweise aktualisieren, um den Verlust der Konnektivität mit Ihrer Azure Cache for Redis-Instanz zu verhindern.

Zertifizierungsstellentyp Aktuell Nach der Umstellung (12. Oktober 2020) Aktion
Root Fingerabdruck: d4de20d05e66fc53fe1a50882c78db2852cae474

Ablauf: Montag, 12. Mai 2025, 17:59:00

Antragstellername:
CN = Baltimore CyberTrust Root
OU = CyberTrust
O = Baltimore
C = IE		 Keine Änderung Keine
Zwischenzertifizierungsstellen Fingerabdrücke:
CN = Microsoft IT TLS CA 1
Fingerabdruck: 417e225037fbfaa4f95761d5ae729e1aea7e3a42

CN = Microsoft IT TLS CA 2
Fingerabdruck: 54d9d20239080c32316ed9ff980a48988f4adf2d

CN = Microsoft IT TLS CA 4
Fingerabdruck: 8a38755d0996823fe8fa3116a277ce446eac4e99

CN = Microsoft IT TLS CA 5
Fingerabdruck: Ad898ac73df333eb60ac1f5fc6c4b2219ddb79b7

Ablauf: Freitag, 20. Mai 2024 17:52:38

Antragstellername:
OU = Microsoft IT
O = Microsoft Corporation
L = Redmond
S = Washington
C = US
 Fingerabdrücke:
CN = Microsoft RSA TLS CA 01
Fingerabdruck: 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a

CN = Microsoft RSA TLS CA 02
Fingerabdruck: b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75

Ablauf: Dienstag, 8. Oktober 2024 12:00:00;

Antragstellername:
O = Microsoft Corporation
C = US
 Erforderlich

Welche Aktionen zieht das für mich nach sich?

Wenn Ihre Anwendung den Zertifikatspeicher des Betriebssystems verwendet oder Baltimore Root angibt, ist keine Aktion erforderlich.

Wenn Ihre Anwendung ein Zwischen- oder Blatt-TLS-Zertifikat angibt, empfiehlt es sich, die folgenden Stämme anzuheften:

Zertifikat Fingerabdruck
Baltimore Root CA d4de20d05e66fc53fe1a50882c78db2852cae474
Microsoft RSA Root Certificate Authority 2017 73a5e64a3bff8316ff0edccc618a906e4eae4d74
Digicert Global Root G2 df3c24f9bfd666761b268073fe06d1cc8d4f82a4

Tipp

Sowohl das Zwischen- als auch das Blattzertifikat wird wahrscheinlich häufig geändert. Es wird empfohlen, keine Abhängigkeit von diesen Zertifikaten zu verwenden. Heften Sie die Anwendung stattdessen an ein Stammzertifikat an, da dieses weniger häufig umgestellt wird.

Um weiterhin Zwischenzertifikate anzuheften, fügen Sie Folgendes der Liste der angehefteten Zwischenzertifikate hinzu, die nur wenige weitere Zertifikate enthält, um zukünftige Änderungen zu minimieren:

Allgemeiner Name der Zertifizierungsstelle Fingerabdruck
Microsoft RSA TLS CA 01 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a
Microsoft RSA TLS CA 02 b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75
Microsoft Azure TLS Issuing CA 01 2f2877c5d778c31e0f29c7e371df5471bd673173
Microsoft Azure TLS Issuing CA 02 e7eea674ca718e3befd90858e09f8372ad0ae2aa
Microsoft Azure TLS Issuing CA 05 6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5
Microsoft Azure TLS Issuing CA 06 30e01761ab97e59a06b41ef20af6f2de7ef4f7b0

Wenn Ihre Anwendung das Zertifikat im Code überprüft, müssen Sie ihn ändern, um die Eigenschaften --- beispielsweise Aussteller, Fingerabdruck --- der neu angehefteten Zertifikate zu erkennen. Diese zusätzliche Überprüfung sollte alle angehefteten Zertifikate abdecken, um für die Zukunft gerüstet zu sein.

Spezifische Anleitungen für die Clientbibliothek

Weitere Informationen finden Sie unter Clientbibliotheken.

Nächste Schritte