Verbindings resilience
Opdrachten voor opnieuw proberen
Configureer uw clientverbindingen om opdrachten opnieuw uit te voeren met exponentieel terugkijken. Zie richtlijnen voor opnieuw proberen voor meer informatie.
Tolerantie testen
Test de tolerantie van uw systeem voor verbindingsbreaks met behulp van opnieuw opstarten om een patch te simuleren. Zie Prestatietests voor meer informatie over het testen van uw prestaties.
TCP-instellingen voor door Linux gehoste clienttoepassingen
Sommige Linux-versies gebruiken standaard optimistische TCP-instellingen. De TCP-instellingen kunnen leiden tot een situatie waarin een clientverbinding met een cache lange tijd niet opnieuw kan worden tot stand gebracht wanneer een Redis-server niet meer reageert voordat de verbinding probleemloos wordt gesloten. Het niet opnieuw tot stand brengen van een verbinding kan gebeuren als het primaire knooppunt van uw Azure Cache voor Redis niet meer beschikbaar is, bijvoorbeeld bij niet-gepland onderhoud.
We raden deze TCP-instellingen aan:
| Instelling | Waarde |
|---|---|
| net.ipv4.tcp_retries2 | 5 |
Zie Connection does not re-establish for 15 minutes when running on Linux(Verbinding wordt 15 minuten niet opnieuw tot stand brengen 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 worden uitgevoerd op Linux beïnvloed. De uitleg is nog steeds nuttig en u kunt deze generaliseren naar andere bibliotheken.
ForceReconnect gebruiken met StackExchange.Redis
In zeldzame gevallen kan StackExchange.Redis geen verbinding meer maken nadat een verbinding is gemaakt. In dergelijke gevallen wordt het probleem opgelost door de client opnieuw op te starten of ConnectionMultiplexer een nieuwe te maken. We raden u aan een singleton-patroon te gebruiken terwijl apps periodiek opnieuw ConnectionMultiplexer verbinding kunnen maken. Bekijk het quickstart-voorbeeldproject dat het beste overeenkomt met het framework en platform dat uw toepassing gebruikt. In onze quickstarts ziet u een voorbeeld van dit codepatroon.
Gebruikers van de moeten eventuele fouten afhandelen die kunnen optreden als ConnectionMultiplexer ObjectDisposedException gevolg van het blootstellen van de oude.
Roep ForceReconnectAsync() aan voor en RedisConnectionExceptions RedisSocketExceptions . U kunt ook ForceReconnectAsync() aanroepen RedisTimeoutExceptions voor , maar alleen als u gebruik maakt van haar en ReconnectMinInterval ReconnectErrorThreshold . Anders kan het tot stand brengen van nieuwe verbindingen een trapsgevatte fout veroorzaken op een server die een time-out heeft omdat deze al overbelast is.
De juiste time-outs configureren
Twee time-outwaarden zijn belangrijk om rekening mee te houden bij verbindings resiliency: verbindings time-out en time-out van opdracht.
Verbinding maken time-out
De connect timeout is de tijd dat uw client wacht om verbinding te maken met de Redis-server. Configureer uw clientbibliotheek voor het gebruik van een van vijf seconden, zodat het systeem voldoende tijd heeft om zelfs onder connect timeout hogere CPU-omstandigheden verbinding te maken.
Een kleine waarde garandeert niet dat er in dat tijdsbestek connection timeout een verbinding tot stand wordt gebracht. Als er iets misgaat (hoge client-CPU, hoge server-CPU, bijvoorbeeld), mislukt de verbindingspoging met een korte connection timeout waarde. Dit gedrag maakt een slechte situatie vaak erger. In plaats van te helpen, kunnen kortere time-outs het probleem oplossen door het systeem af te dwingen opnieuw verbinding te maken, wat kan leiden tot een verbindingslus -> fail -> opnieuw proberen.
Time-out van opdracht
De meeste clientbibliotheken hebben een andere time-outconfiguratie voor . Dit is de tijd waarop de client wacht op een command timeouts reactie van de Redis-server. Hoewel we een initiële instelling van minder dan vijf seconden aanraden, kunt u overwegen om het hoger of lager in te stellen, afhankelijk van uw scenario en de grootte van de waarden die zijn opgeslagen command timeout in uw cache.
Als de command timeout te klein is, kan de verbinding instabiel lijken. Als de echter te groot is, moet uw toepassing mogelijk lang wachten om erachter te komen of er al dan niet command timeout een time-out voor de opdracht wordt gegeven.
Pieken in clientverbindingen voorkomen
Vermijd het maken van veel verbindingen tegelijk wanneer u opnieuw verbinding maakt na een verbindingsverlies. Vergelijkbaar met de manier waarop korte verbindings-time-outs kunnen leiden tot langere uitval, kunnen veel pogingen om opnieuw verbinding te maken op hetzelfde moment ook de serverbelasting verhogen en verlengen hoe lang het duurt voordat alle clients weer verbinding kunnen maken.
Als u veel client-exemplaren opnieuw verbindt, kunt u overwegen om de nieuwe verbindingen te verdreed om een enorme piek in het aantal verbonden clients te voorkomen.
Notitie
Wanneer u de StackExchange.Redis clientbibliotheek gebruikt, stelt u abortConnect in uw false connection string. We raden u aan om de ConnectionMultiplexer handle opnieuw verbinding te laten maken. Zie Best practices voor StackExchange.Redis voor meer informatie.
Overblijfte verbindingen voorkomen
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 voor vooraf onderhoud
Gebruik meldingen om meer te weten te komen over aanstaand onderhoud. Zie Kan ik van tevoren op de hoogte worden gesteld van gepland onderhoud voor meer informatie.
Onderhoudsvenster plannen
Pas de cache-instellingen aan voor onderhoud. Zie Updates plannen voor meer informatie over het maken van een onderhoudsvenster om negatieve gevolgen voor uw cache te beperken.
Meer ontwerppatronen voor tolerantie
Ontwerppatronen toepassen voor tolerantie. Zie voor meer informatie Hoe kan ik mijn toepassing flexibel te maken.
Time-out voor inactieve
Azure Cache voor Redis momenteel een time-out voor inactieve verbindingen van 10 minuten heeft, moet de time-outinstelling voor inactieve gegevens in uw clienttoepassing minder dan 10 minuten zijn. De meeste clientbibliotheken hebben een configuratie-instelling waarmee clientbibliotheken automatisch en periodiek Redis-opdrachten naar een PING Redis-server kunnen verzenden. Wanneer u echter clientbibliotheken gebruikt zonder dit type instelling, zijn klanttoepassingen zelf verantwoordelijk voor het behouden van de verbinding.