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.

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 Ihrer 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 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 derzeit über ein Leerlauftimeout von 10 Minuten für Verbindungen, sodass die Einstellung für das Leerlauftimeout in Ihrer Clientanwendung weniger als 10 Minuten betragen sollte. Die meisten gängigen Clientbibliotheken verfügen über eine Konfigurationseinstellung, mit der Clientbibliotheken PING-Befehle von Redis automatisch und in regelmäßigen Abständen an einen Redis-Server senden können. Wenn Sie jedoch Clientbibliotheken ohne diese Art von Einstellung verwenden, sind Kundenanwendungen selbst dafür verantwortlich, die Verbindung aktiv zu halten.

Nächste Schritte