Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Von Bedeutung
Azure Cache for Redis hat den Auslaufzeitplan für alle SKUs angekündigt. Es wird empfohlen, Ihren vorhandenen Azure-Cache für Redis-Instanzen in Azure Managed Redis zu verschieben, sobald Möglich.
Weitere Informationen zur Einstellung finden Sie unter:
Wiederholen von Befehlen
Konfigurieren Sie Ihre Clientverbindungen so, dass Befehle mit exponentieller Wartezeit wiederholt werden. Weitere Informationen finden Sie in den Wiederholungsrichtlinien.
Testresilienz
Testen Sie die Resilienz Ihres Systems für Verbindungsunterbrechungen mithilfe eines Neustarts , um einen Patch zu simulieren. Weitere Informationen zum Testen Ihrer Leistung finden Sie unter Leistungstests.
TCP-Einstellungen für von Linux gehostete Clientanwendungen
Die Standard-TCP-Einstellungen in einigen Linux-Versionen können dazu führen, dass Redis-Serververbindungen 13 Minuten oder mehr fehlschlagen. Die Standardeinstellungen können verhindern, dass die Clientanwendung geschlossene Verbindungen erkennt und sie automatisch wiederherstellen, wenn die Verbindung nicht ordnungsgemäß geschlossen wurde.
Das Scheitern der Wiederherstellung einer Verbindung kann auftreten, wenn die Netzwerkverbindung unterbrochen wird oder der Redis-Server aufgrund ungeplanter Wartungsarbeiten offline geht.
Wir empfehlen diese TCP-Einstellungen:
| Setting | Wert |
|---|---|
net.ipv4.tcp_retries2 |
5 |
Weitere Informationen zum Szenario finden Sie unter Die Verbindung wird bei Ausführung unter Linux für 15 Minuten nicht wiederhergestellt. Während es sich bei dieser Diskussion um die StackExchange.Redis-Bibliothek handelt, sind auch andere Clientbibliotheken betroffen, die unter Linux ausgeführt werden. Die Erklärung ist weiterhin nützlich und Sie können auf andere Bibliotheken verallgemeinern.
Verwenden von ForceReconnect mit StackExchange.Redis
In seltenen Fällen kann StackExchange.Redis nach dem Ablegen einer Verbindung nicht erneut verbunden werden. In diesen Fällen wird das Problem behoben, indem Sie den Client neu starten oder einen neuen ConnectionMultiplexer erstellen. Es wird empfohlen, ein Singleton-Muster ConnectionMultiplexer zu verwenden, während Apps eine erneute Verbindung in regelmäßigen Abständen erzwingen können. Sehen Sie sich das Schnellstartbeispielprojekt an, das am besten mit dem Framework und der Plattform übereinstimmt, das Ihre Anwendung verwendet. In unseren Schnellstarts finden Sie ein Beispiel für dieses Codemuster.
Benutzer von ConnectionMultiplexer müssen alle ObjectDisposedException-Fehler behandeln, die möglicherweise aufgrund des Verwerfens des alten Multiplexers auftreten.
Rufen Sie ForceReconnectAsync() für RedisConnectionExceptions und RedisSocketExceptions an. Sie können auch ForceReconnectAsync() für RedisTimeoutExceptions aufrufen, aber nur, wenn Sie großzügige Werte für ReconnectMinInterval und ReconnectErrorThreshold verwenden. Ansonsten kann das Einrichten neuer Verbindungen zu einem Kaskadenfehler auf einem Server führen, der ausfällt, weil er bereits überlastet ist.
In einer ASP.NET Anwendung können Sie die integrierte Implementierung im Paket "Microsoft.Extensions.Caching.StackExchangeRedis " anstelle des StackExchange.Redis-Pakets direkt verwenden. Wenn Sie Microsoft.Extensions.Caching.StackExchangeRedis in einer ASP.NET Anwendung verwenden, anstatt StackExchange.Redis direkt zu verwenden, können Sie die UseForceReconnect Eigenschaft auf "true" festlegen:
Microsoft.AspNetCore.Caching.StackExchangeRedis.UseForceReconnect = true
Geeignete Timeouts konfigurieren
Zwei Timeoutwerte sind für die Verbindungsresilienz wichtig: Verbindungstimeout und Befehlstimeout.
Verbindungstimeout
connect timeout ist die Zeitspanne, die ein Client wartet, bis er eine Verbindung mit dem Redis-Server herstellt. Konfigurieren Sie Ihre Clientbibliothek so, dass sie eine connect timeout von fünf Sekunden verwendet, sodass das System ausreichend Zeit für die Verbindung selbst unter höheren CPU-Bedingungen hat.
Ein kleiner connection timeout Wert garantiert nicht, dass eine Verbindung in diesem Zeitrahmen hergestellt wird. Wenn ein Fehler auftritt (hohe Client-CPU, hohe Server-CPU usw.), führt ein kurzer connection timeout Wert dazu, dass der Verbindungsversuch fehlschlägt. Dieses Verhalten macht oft eine schlechte Situation schlimmer. Anstatt zu helfen, verschlimmern kürzere Timeouts das Problem, indem sie das System zwingen, den Prozess des erneuten Verbindungsversuchs neu zu starten, was zu einer Verbindung -> Fehler -> Wiederholungsschleife führen kann.
Befehlstimeout
Die meisten Clientbibliotheken verfügen über eine weitere Timeoutkonfiguration für command timeouts, bei der der Client auf eine Antwort vom Redis-Server wartet. Obwohl wir eine Anfängliche Einstellung von weniger als fünf Sekunden empfehlen, sollten Sie je nach Szenario und den Größen der Werte, die in Ihrem Cache gespeichert sind, den höheren oder niedrigeren Wert festlegen command timeout .
Wenn die command timeout Verbindung zu klein ist, kann die Verbindung instabil aussehen. Wenn der command timeout-Wert jedoch zu groß ist, muss Ihre Anwendung möglicherweise lange warten, um herauszufinden, ob der Befehl einen Timeout verursacht.
Vermeiden von Spitzen bei Clientverbindungen
Vermeiden Sie das gleichzeitige Erstellen vieler Verbindungen, wenn die Verbindung nach einem Verbindungsverlust erneut hergestellt wird. Ähnlich wie kurze Verbindungstimeouts zu längeren Ausfällen führen können, kann das gleichzeitige Starten vieler wiederholter Verbindungsversuche auch die Serverlast erhöhen und die Dauer, bis alle Clients erfolgreich wiederverbunden sind, verlängern.
Wenn Sie viele Clientinstanzen erneut verbinden, sollten Sie erwägen, die neuen Verbindungen gestaffelt herzustellen, um einen steilen Anstieg der Anzahl verbundener Clients zu vermeiden.
Hinweis
Wenn Sie die StackExchange.Redis-Clientbibliothek verwenden, setzen Sie abortConnect auf false in Ihrer Verbindungszeichenfolge. Wir empfehlen, ConnectionMultiplexer die Neuverbindung zu überlassen. Weitere Informationen finden Sie unter "StackExchange.Redis Best Practices".
Vermeidung von restlichen Verbindungen
Caches haben Grenzwerte für die Anzahl der Clientverbindungen pro Cacheebene. Stellen Sie sicher, dass Ihre Clientanwendung beim Neuerstellen von Verbindungen die alten Verbindungen schließt und entfernt.
Vorherige Wartungsbenachrichtigung
Verwenden Sie Benachrichtigungen, um sich über bevorstehende Wartungen zu informieren. Weitere Informationen finden Sie unter Kann ich im Voraus über eine geplante Wartung benachrichtigt werden.
Wartungsfenster planen
Passen Sie Ihre Cacheeinstellungen an, um die Wartung zu berücksichtigen. Weitere Informationen zum Erstellen eines Wartungsfensters, um negative Auswirkungen auf Den Cache zu verringern, finden Sie unter "Updatekanal" und "Planen von Updates".
Weitere Entwurfsmuster für Resilienz
Entwurfsmuster für Resilienz anwenden. Weitere Informationen finden Sie unter How do I make my application resilient.
Leerlauftimeout
Azure Cache für Redis verfügt über ein Timeout von 10 Minuten für Leerlaufverbindungen. Das 10-Minuten-Timeout ermöglicht es dem Server, undichte oder durch eine Clientanwendung verwaiste Verbindungen automatisch zu bereinigen. Die meisten Redis-Clientbibliotheken verfügen über eine integrierte Funktion zum Regelmäßigen Senden heartbeat oder Senden von keepalive Befehlen, um zu verhindern, dass Verbindungen geschlossen werden, auch wenn keine Anforderungen von der Clientanwendung vorhanden sind.
Wenn das Risiko besteht, dass Ihre Verbindungen 10 Minuten im Leerlauf sind, konfigurieren Sie das keepalive Intervall auf einen Wert, der kleiner als 10 Minuten ist. Wenn Ihre Anwendung eine Clientbibliothek verwendet, die keine systemeigene Unterstützung für keepalive Die Funktionalität bietet, können Sie sie in Ihrer Anwendung implementieren, indem Sie regelmäßig einen PING Befehl senden.