Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Belangrijk
Azure Cache voor Redis heeft de tijdlijn voor buitengebruikstelling aangekondigd voor alle SKU's. We raden je aan om je Azure Cache voor Redis-instances zo snel mogelijk te verplaatsen naar Azure Managed Redis.
Voor meer informatie over de buitengebruikstelling:
Opnieuw proberen-opdrachten
Configureer uw clientverbindingen om opdrachten opnieuw uit te voeren met exponentieel uitstel. Zie richtlijnen voor opnieuw proberen voor meer informatie.
Veerkracht testen
Test de tolerantie van uw systeem voor verbindingsonderbrekingen 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
De standaard TCP-instellingen in sommige Linux-versies kunnen ertoe leiden dat Redis-serververbindingen 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 ongepland onderhoud.
We raden deze TCP-instellingen aan:
| Configuratie | Waarde |
|---|---|
net.ipv4.tcp_retries2 |
5 |
Zie Verbinding wordt gedurende 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 op Linux 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 niet opnieuw verbinding maken nadat een verbinding is verbroken. In deze gevallen lost het herstarten van de client of het aanmaken van een nieuwe ConnectionMultiplexer het probleem op. U wordt aangeraden een singleton-patroon ConnectionMultiplexer te gebruiken, terwijl apps periodiek opnieuw verbinding kunnen maken. Bekijk het quickstart-voorbeeldproject dat het beste overeenkomt met het framework en het platform dat uw toepassing gebruikt. In onze quickstarts ziet u een voorbeeld van dit codepatroon.
Gebruikers van de ConnectionMultiplexer moeten eventuele ObjectDisposedException fouten opvangen die kunnen optreden als gevolg van het verwijderen van de oude.
Bel ForceReconnectAsync() voor RedisConnectionExceptions en RedisSocketExceptions. Je kunt ook ForceReconnectAsync() bellen voor RedisTimeoutExceptions, maar alleen als je genereus gebruikmaakt van ReconnectMinInterval en ReconnectErrorThreshold. Indien niet, kan het tot stand brengen van nieuwe verbindingen een trapsgewijze fout veroorzaken op een server die in een time-out gaat omdat deze al overbelast is.
In een ASP.NET-toepassing kunt u geïntegreerde implementatie gebruiken in het pakket Microsoft.Extensions.Caching.StackExchangeRedis in plaats van het StackExchange.Redis-pakket rechtstreeks te gebruiken. Als u Microsoft.Extensions.Caching.StackExchangeRedis gebruikt in een ASP.NET toepassing in plaats van StackExchange.Redis rechtstreeks te gebruiken, kunt u de UseForceReconnect eigenschap instellen op true:
Microsoft.AspNetCore.Caching.StackExchangeRedis.UseForceReconnect = true
De juiste time-outs configureren
Twee time-outwaarden zijn belangrijk om rekening mee te houden bij verbindingsbetrouwbaarheid: verbindtime-out en opdracht-time-out.
Time-out voor verbinding maken
Dit connect timeout is het tijdstip waarop uw client wacht om verbinding te maken met redis-server. Configureer uw clientbibliotheek voor het gebruik van een connect timeout periode van vijf seconden, waardoor 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 wordt gebracht. Als er iets misgaat (een hoog CPU-clientgebruik, een hoog CPU-gebruik van de server, enzovoort), zorgt een korte connection timeout waarde ervoor dat de verbindingspoging mislukt. Dit gedrag maakt vaak een slechte situatie erger. In plaats van te helpen, verergeren kortere time-outs het probleem door het systeem te dwingen het proces van opnieuw verbinding te starten, wat kan leiden tot een verbinding -> mislukt - lus voor> opnieuw proberen .
Opdracht time-out
De meeste clientbibliotheken hebben een andere time-outconfiguratie. command timeoutsDit is het tijdstip 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 grootten van de waarden die zijn opgeslagen in uw cache.
Als de command timeout verbinding 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 de opdracht een time-out krijgt.
Vermijd pieken in klantverbindingen
Vermijd het maken van veel verbindingen tegelijk wanneer u opnieuw verbinding maakt na verlies van een verbinding. Net als bij de manier waarop korte verbindingstime-outs kunnen leiden tot langere storingen, kan het starten van veel nieuwe verbindingspogingen tegelijkertijd ook de serverbelasting verhogen en uitbreiden hoe lang het duurt voordat alle clients opnieuw verbinding kunnen maken.
Als u veel clientinstanties opnieuw aansluit, kunt u overwegen de nieuwe verbindingen te spreiden om een steile piek in het aantal verbonden clients te voorkomen.
Opmerking
Wanneer u de StackExchange.Redis-clientbibliotheek gebruikt, stelt u abortConnect in op false in uw verbindingsreeks. We raden aan om de ConnectionMultiplexer de verbinding te laten herstellen. Zie de best practices voor StackExchange.Redis voor meer informatie.
Overblijvende verbindingen voorkomen
Caches hebben limieten voor het aantal clientverbindingen per cachelaag. Zorg ervoor dat wanneer uw clienttoepassing opnieuw verbindingen maakt, het oude verbindingen sluit en verwijdert.
Melding van vooraf onderhoud
Gebruik meldingen om meer te weten te komen over gepland onderhoud. Zie Kan ik vooraf op de hoogte worden gesteld van een gepland onderhoud voor meer informatie.
Onderhoudsvenster plannen
Pas de cache-instellingen aan om onderhoud mogelijk te maken. Zie Updatekanaal en Planningsupdates voor meer informatie over het maken van een onderhoudsvenster om negatieve gevolgen voor uw cache te verminderen.
Meer ontwerppatronen voor tolerantie
Ontwerppatronen toepassen voor veerkracht. 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. De time-out van 10 minuten stelt de server in staat om lekke verbindingen of door een cliëntapplicatie achtergelaten verbindingen automatisch op te schonen. De meeste Redis-clientbibliotheken hebben een ingebouwde mogelijkheid om periodiek te verzenden heartbeat of keepalive opdrachten uit te voeren om te voorkomen dat verbindingen worden gesloten, zelfs als er geen aanvragen van de clienttoepassing zijn.
Als er enige kans is dat je verbindingen 10 minuten inactief zijn, configureer je 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 in uw toepassing implementeren door periodiek een PING opdracht te verzenden.