Verbindungsresilienz
Wiederholungsbefehle
Konfigurieren Ihrer Clientverbindungen für Wiederholungsbefehle mit exponentiellem Backoff Weitere Informationen finden Sie in den Wiederholungsrichtlinien.
Testresilienz
Testen Sie die Resilienz Ihres Systems bei Verbindungsunterbrechungen mithilfe eines Neustarts, um einen Patch zu simulieren. Weitere Informationen zum Testen der Leistung finden Sie unter Leistungstests.
TCP-Einstellungen für unter Linux gehostete Clientanwendungen
Die TCP-Standardeinstellungen bei einigen Linux-Versionen können dazu führen, dass Redis-Serververbindungen nach 13 Minuten oder mehr fehlschlagen. Die Standardeinstellungen können verhindern, dass die Clientanwendung geschlossene Verbindungen erkennt und diese automatisch wiederherstellt, wenn die Verbindung nicht ordnungsgemäß geschlossen wurde.
Der Fehler beim Wiederherstellen einer Verbindung kann in Situationen auftreten, in denen die Netzwerkverbindung unterbrochen oder der Redis-Server für eine nicht geplante Wartung offline geschaltet wird.
Es werden die folgenden TCP-Einstellungen empfohlen:
| Einstellung | Wert |
|---|---|
net.ipv4.tcp_retries2 |
5 |
Weitere Informationen zu dem Szenario finden Sie unter Verbindung wird bei der Ausführung unter Linux für 15 Minuten nicht wiederhergestellt. Während sich diese Diskussion auf die StackExchange.Redis-Bibliothek bezieht, sind auch andere Clientbibliotheken betroffen, die unter Linux ausgeführt werden. Die Erläuterung ist immer noch nützlich, und Sie können sie hinsichtlich anderer Bibliotheken verallgemeinern.
Verwenden von ForceReconnect mit StackExchange.Redis
In seltenen Fällen kann StackExchange.Redis nach einer Verbindungsunterbrechung die Verbindung nicht mehr wiederherstellen. In diesen Fällen wird das Problem behoben, indem Sie den Client neu starten oder einen neuen ConnectionMultiplexer erstellen. Es wird empfohlen, ein ConnectionMultiplexer-Singletonmuster zu verwenden, wenn Sie Apps gestatten, eine erneute Verbindung in regelmäßigen Abständen zu erzwingen. Sehen Sie sich das Schnellstart-Beispielprojekt an, das am besten zu dem Framework und der Plattform passt, die Ihre Anwendung verwendet. Ein Beispiel für dieses Codemuster finden Sie in unseren Schnellstartanleitungen.
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 auf. Sie können auch ForceReconnectAsync() für RedisTimeoutExceptions aufrufen, aber nur, wenn Sie großzügige Werte für ReconnectMinInterval und ReconnectErrorThreshold verwenden. Andernfalls kann das Herstellen neuer Verbindungen zu einem kaskadierten Fehler auf einem Server führen, bei dem ein Timeout auftritt, weil er bereits überlastet ist.
In einer ASP.NET-Anwendung können Sie die integrierte Implementierung im Microsoft.Extensions.Caching.StackExchangeRedis -Paket verwenden, anstatt das StackExchange.Redis-Paket direkt zu 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
Konfigurieren von entsprechenden Timeouts
Zwei Timeoutwerte sind bei der Verbindungsresilienz wichtig: Connect timeout (Verbindungstimeout) und command timeout (Befehlstimeout).
Connect timeout
Das connect timeout ist die Zeit, die ein Client wartet, bis er eine Verbindung mit dem Redis-Server herstellt. Konfigurieren Sie Ihre Clientbibliothek so, dass sie ein connect timeout von fünf Sekunden verwendet, damit das System auch bei hoher CPU-Auslastung genügend Zeit hat, eine Verbindung herzustellen.
Bei einem niedrigeren connection timeout ist nicht sichergestellt, dass die Verbindung in diesem Zeitraum hergestellt werden kann. Bei Beeinträchtigungen (hohe Client- oder Server-CPU-Auslastung usw.) hat ein kurzer connection timeout-Wert zur Folge, dass bei dem Verbindungsversuch ein Fehler auftritt. Dieses Verhalten macht eine schlechte Situation häufig noch schlimmer. Statt zu helfen, verschlimmern kürzere Timeouts das Problem, weil sie einen Neustarten der Verbindungswiederherstellung erzwingen und damit zu einer Schleife Verbinden -> Fehler -> Wiederholen führen können.
Befehlstimeout
Die meisten Clientbibliotheken verfügen über eine weitere Timeoutkonfiguration für command timeouts. Dies ist die Zeitspanne, die der Client auf eine Antwort vom Redis-Server wartet. Wir empfehlen zwar eine anfängliche Einstellung von weniger als fünf Sekunden, aber sie sollten je nach Szenario und der Größe der Werte, die in Ihrem Cache gespeichert sind, den höheren oder niedrigeren command timeout festlegen.
Ist das command timeout zu kurz, kann die Verbindung instabil wirken. 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 es, viele Verbindungen gleichzeitig zu erstellen, wenn sie nach einem Verbindungsverlust erneut hergestellt werden. Ähnlich wie kurze Verbindungstimeouts zu längeren Ausfällen führen können, kann das gleichzeitige Starten vieler Verbindungsversuche auch die Serverauslastung erhöhen und die Dauer der erfolgreichen Verbindungsherstellung für alle Clients verlängern.
Wenn Sie viele Clientinstanzen erneut verbinden, sollten Sie erwägen, die neuen Verbindungen zu staffeln, um eine starke Spitze bei der Anzahl verbundener Clients zu vermeiden.
Hinweis
Wenn Sie die Clientbibliothek StackExchange.Redis verwenden, legen Sie abortConnect in der Verbindungszeichenfolge auf false fest. Wir empfehlen, ConnectionMultiplexer die Neuverbindung zu überlassen. Weitere Informationen finden Sie unter Bewährte Methoden für StackExchange.Redis.
Vermeiden Sie übrig bleibende Verbindungen
Caches weisen Grenzwerte für die Anzahl von Clientverbindungen pro Cacheebene auf. Stellen Sie sicher, dass die Clientanwendung Verbindungen, die sie schließt, neu erstellt und die alten Verbindungen entfernt.
Benachrichtigungen zu erweiterten Wartungen
Verwenden Sie Benachrichtigungen, um mehr über bevorstehende Wartungen zu erfahren. Weitere Informationen finden Sie unter Kann ich im Voraus über eine geplante Wartung informiert werden.
Zeitplan für Wartungsfenster
Passen Sie Ihre Cacheeinstellungen an die Wartung an. Weitere Informationen zum Erstellen eines Wartungsfensters, um negative Auswirkungen auf Ihren Cache zu reduzieren, finden Sie unter Updatekanal und Planen von Updates.
Weitere Entwurfsmuster für Resilienz
Wenden Sie Entwurfsmuster für Resilienz an. Weitere Informationen finden Sie unter Wie mache ich meine Anwendung resilient.
Leerlauftimeout
Azure Cache for Redis verfügt über ein Timeout von 10 Minuten für Verbindungen im Leerlauf. Das Timeout von 10 Minuten ermöglicht es dem Server, fehlerhafte Verbindungen oder verwaiste Verbindungen einer Clientanwendung automatisch zu bereinigen. Die meisten Redis-Clientbibliotheken verfügen über eine integrierte Funktion zum regelmäßigen Senden von heartbeat- oder keepalive-Befehlen, um zu verhindern, dass Verbindungen geschlossen werden, auch wenn keine Anforderungen von der Clientanwendung vorliegen.
Wenn das Risiko besteht, dass Ihre Verbindungen 10 Minuten im Leerlauf verbleiben, konfigurieren Sie das keepalive-Intervall auf einen Wert von unter 10 Minuten. Wenn Ihre Anwendung eine Clientbibliothek verwendet, die keine native Unterstützung für keepalive-Funktionen bietet, können Sie diese in Ihrer Anwendung implementieren, indem Sie regelmäßig einen PING-Befehl senden.