Entwicklung
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.
- Die bevorzugte Lösung besteht darin, Ihre Daten in verknüpfte kleinere Werte aufzuteilen.
- Ausführliche Informationen, warum kleinere Werte empfohlen werden, finden Sie im Beitrag What is the ideal value size range for redis? Is 100 KB too large? (Welche Größe ist für Werte bei Redis ideal? Sind 100 KB zu viel?).
- 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.