Verbindingstolerantie

Opdrachten opnieuw proberen

Configureer uw clientverbindingen om opdrachten opnieuw te proberen met exponentieel uitstel. Zie Richtlijnen voor opnieuw proberen voor meer informatie.

Tolerantie testen

Test de tolerantie van uw systeem voor verbindingsonderbrekingen door opnieuw op te starten om een patch te simuleren. Zie Prestatietests voor meer informatie over het testen van uw prestaties.

TCP-instellingen voor door Linux gehoste clienttoepassingen

De standaard TCP-instellingen in sommige Linux-versies kunnen ertoe leiden dat Redis-serververbindingen gedurende 13 minuten of langer mislukken. De standaardinstellingen kunnen voorkomen dat de clienttoepassing gesloten verbindingen detecteert en deze automatisch herstelt als de verbinding niet correct is gesloten.

De fout bij het herstellen van een verbinding kan optreden in situaties waarin de netwerkverbinding wordt onderbroken of de Redis-server offline gaat voor niet-gepland onderhoud.

We raden deze TCP-instellingen aan:

Instelling Waarde
net.ipv4.tcp_retries2 5

Zie Verbinding wordt 15 minuten niet opnieuw tot stand gebracht wanneer deze wordt uitgevoerd op Linux voor meer informatie over het scenario. Hoewel deze discussie gaat over de StackExchange.Redis-bibliotheek, worden ook andere clientbibliotheken die op Linux worden uitgevoerd, beïnvloed. De uitleg is nog steeds nuttig en u kunt generaliseren naar andere bibliotheken.

ForceReconnect gebruiken met StackExchange.Redis

In zeldzame gevallen kan StackExchange.Redis geen verbinding meer maken nadat een verbinding is verbroken. In dergelijke gevallen wordt het probleem opgelost door de client opnieuw op te starten of een nieuwe ConnectionMultiplexer te maken. We raden u aan een singleton-patroon ConnectionMultiplexer te gebruiken terwijl apps periodiek opnieuw verbinding kunnen maken. Bekijk het voorbeeldproject van de quickstart dat het beste overeenkomt met het framework en het platform dat uw toepassing gebruikt. U ziet een voorbeeld van dit codepatroon in onze quickstarts.

Gebruikers van de ConnectionMultiplexer moeten eventuele ObjectDisposedException fouten verwerken die kunnen optreden als gevolg van het verwijderen van de oude.

Roep ForceReconnectAsync() aan voor RedisConnectionExceptions en RedisSocketExceptions. U kunt ook bellen ForceReconnectAsync() voor RedisTimeoutExceptions, maar alleen als u royale ReconnectMinInterval en ReconnectErrorThresholdgebruikt. Anders kan het tot stand brengen van nieuwe verbindingen leiden tot een trapsgewijze fout op een server waarvoor een time-out optreedt omdat deze al overbelast is.

De juiste time-outs configureren

Twee time-outwaarden zijn belangrijk om rekening mee te houden bij de verbindingstolerantie: time-out voor verbinding en time-out voor opdrachten.

Time-out voor verbinding

Dit connect timeout is de tijd waarop uw client wacht om verbinding te maken met redis-server. Configureer uw clientbibliotheek om vijf seconden te gebruiken connect timeout , zodat het systeem voldoende tijd heeft om verbinding te maken, zelfs onder hogere CPU-omstandigheden.

Een kleine connection timeout waarde garandeert niet dat er in dat tijdsbestek een verbinding tot stand is gebracht. Als er iets misgaat (hoog client-CPU, hoog cpu-gebruik van de server, enzovoort), zorgt een korte connection timeout waarde ervoor dat de verbindingspoging mislukt. Dit gedrag maakt een slechte situatie vaak erger. In plaats van te helpen, verergeren kortere time-outs het probleem door het systeem te dwingen om het proces van opnieuw verbinding te maken opnieuw te starten, wat kan leiden tot een lus voor opnieuw verbinden -> mislukken -> opnieuw proberen .

Time-out van opdracht

De meeste clientbibliotheken hebben een andere time-outconfiguratie voor command timeouts. Dit is de tijd waarop de client wacht op een reactie van de Redis-server. Hoewel we een eerste instelling van minder dan vijf seconden aanbevelen, kunt u overwegen om de command timeout hogere of lagere instelling in te stellen, afhankelijk van uw scenario en de grootte van de waarden die zijn opgeslagen in uw cache.

Als de command timeout te klein is, kan de verbinding er instabiel uitzien. Als de command timeout echter te groot is, moet uw toepassing mogelijk lang wachten om erachter te komen of er een time-out optreedt voor de opdracht of niet.

Pieken in clientverbindingen voorkomen

Vermijd het maken van veel verbindingen tegelijk wanneer u opnieuw verbinding maakt na een verbroken verbinding. Vergelijkbaar met de manier waarop korte verbindingstime-outs kunnen leiden tot langere storingen, kan het starten van veel pogingen om opnieuw verbinding te maken op hetzelfde moment ook de serverbelasting verhogen en verlengen hoe lang het duurt voordat alle clients opnieuw verbinding maken.

Als u opnieuw verbinding maakt met veel clientexemplaren, kunt u overwegen om de nieuwe verbindingen te sluizen om een steile piek in het aantal verbonden clients te voorkomen.

Notitie

Wanneer u de StackExchange.Redis clientbibliotheek gebruikt, stelt abortConnectfalse u in op in uw connection string. U wordt aangeraden de ConnectionMultiplexer greep opnieuw verbinding te laten maken. Zie Best practices voor StackExchange.Redis voor meer informatie.

Overblijvende verbindingen vermijden

Caches hebben limieten voor het aantal clientverbindingen per cachelaag. Zorg ervoor dat wanneer uw clienttoepassing verbindingen opnieuw maakt, de oude verbindingen worden gesloten en verwijderd.

Melding van vooraf onderhoud

Gebruik meldingen om meer te weten te komen over aanstaand onderhoud. Zie Kan ik vooraf op de hoogte worden gesteld van gepland onderhoud voor meer informatie.

Onderhoudsvenster plannen

Pas de cache-instellingen aan om onderhoud mogelijk te maken. Zie Kanaal bijwerken en Updates plannen voor meer informatie over het maken van een onderhoudsvenster om eventuele negatieve gevolgen voor uw cache te verminderen.

Meer ontwerppatronen voor tolerantie

Ontwerppatronen toepassen voor tolerantie. Zie Hoe kan ik mijn toepassing tolerant maken voor meer informatie.

Time-out voor inactiviteit

Azure Cache voor Redis heeft een time-out van 10 minuten voor niet-actieve verbindingen. Met de time-out van 10 minuten kan de server automatisch lekkende verbindingen of zwevende verbindingen opschonen die door een clienttoepassing worden gebruikt. De meeste Redis-clientbibliotheken hebben een ingebouwde mogelijkheid om periodiek opdrachten of keepalive te verzenden heartbeat om te voorkomen dat verbindingen worden gesloten, zelfs als er geen aanvragen van de clienttoepassing zijn.

Als er een risico bestaat dat uw verbindingen gedurende 10 minuten inactief zijn, configureert u het keepalive interval op een waarde van minder dan 10 minuten. Als uw toepassing gebruikmaakt van een clientbibliotheek die geen systeemeigen ondersteuning voor keepalive functionaliteit heeft, kunt u deze implementeren in uw toepassing door periodiek een PING opdracht te verzenden.