Anslutningsresiliens

Försök igen kommandon

Konfigurera klientanslutningarna för att försöka köra kommandon igen med exponentiell backoff. Mer information finns i riktlinjer för återförsök.

Testa återhämtning

Testa systemets återhämtning till anslutningsavbrott med hjälp av en omstart för att simulera en korrigering. Mer information om hur du testar dina prestanda finns i Prestandatestning.

TCP-inställningar för klientprogram som körs på Linux

Standardinställningarna för TCP i vissa Linux-versioner kan göra att Redis-serveranslutningarna misslyckas i 13 minuter eller mer. Standardinställningarna kan förhindra att klientprogrammet identifierar stängda anslutningar och återställer dem automatiskt om anslutningen inte stängdes korrekt.

Det går inte att återupprätta en anslutning i situationer där nätverksanslutningen avbryts eller Redis-servern kopplas från för oplanerat underhåll.

Vi rekommenderar dessa TCP-inställningar:

Mer information om scenariot finns i Anslutningen återupprättas inte på 15 minuter när den körs på Linux. Även om den här diskussionen handlar om StackExchange.Redis-biblioteket påverkas även andra klientbibliotek som körs på Linux. Förklaringen är fortfarande användbar och du kan generalisera till andra bibliotek.

Använda ForceReconnect med StackExchange.Redis

I sällsynta fall kan StackExchange.Redis inte återansluta efter att en anslutning har släppts. I dessa fall åtgärdar du problemet genom att starta om klienten eller skapa en ny ConnectionMultiplexer . Vi rekommenderar att du använder ett singleton-mönster ConnectionMultiplexer samtidigt som appar kan tvinga fram en återanslutning med jämna mellanrum. Ta en titt på det snabbstartsexempelprojekt som bäst matchar ramverket och plattformen som ditt program använder. Du kan se ett exempel på det här kodmönstret i våra snabbstarter.

Användare av ConnectionMultiplexer måste hantera alla ObjectDisposedException-fel som kan uppstå till följd av att de gör sig av med den gamla.

Ring för att få och . Du kan också anropa ForceReconnectAsync() för RedisTimeoutExceptions, men bara om du använder generös ReconnectMinInterval och ReconnectErrorThreshold. Annars kan etablering av nya anslutningar orsaka ett kaskadfel på en server som har tidsgränsen ute eftersom den redan är överbelastad.

I ett ASP.NET program kan du använda integrerad implementering i paketet Microsoft.Extensions.Caching.StackExchangeRedis i stället för att använda StackExchange.Redis-paketet direkt. Om du använder Microsoft.Extensions.Caching.StackExchangeRedis i ett ASP.NET-program i stället för att använda StackExchange.Redis direkt kan du ställa in UseForceReconnect egenskapen på true:

Microsoft.AspNetCore.Caching.StackExchangeRedis.UseForceReconnect = true

Konfigurera lämpliga tidsgränser

Två timeout-värden är viktiga att tänka på vid anslutningsåterhämtning: tidsgräns för anslutning och tidsgräns för kommandon.

Tidsgräns för anslutning

Det connect timeout är den tid då klienten väntar på att upprätta en anslutning till Redis-servern. Konfigurera klientbiblioteket så att det använder fem connect timeout sekunder, vilket ger systemet tillräckligt med tid för att ansluta även under högre CPU-förhållanden.

Ett litet connection timeout värde garanterar inte att en anslutning upprättas inom den tidsramen. Om något går fel (hög klient-CPU, hög server-CPU och så vidare) gör ett kort connection timeout värde att anslutningsförsöket misslyckas. Detta beteende gör ofta en dålig situation värre. I stället för att hjälpa till förvärrar kortare tidsgränser problemet genom att tvinga systemet att starta om processen för att försöka återansluta, vilket kan leda till en loop för att ansluta -> misslyckas -> igen .

Tidsgräns för kommando

De flesta klientbibliotek har en annan timeout-konfiguration för command timeouts, vilket är den tid då klienten väntar på ett svar från Redis-servern. Även om vi rekommenderar en inledande inställning på mindre än fem sekunder bör du överväga att ange högre command timeout eller lägre beroende på ditt scenario och storleken på de värden som lagras i cacheminnet.

Om anslutningen command timeout är för liten kan den se instabil ut. Men om det command timeout är för stort kan programmet behöva vänta länge för att se om kommandot kommer att nå tidsgränsen eller inte.

Undvik toppar i klientanslutningen

Undvik att skapa många anslutningar samtidigt när du återansluter efter en anslutningsförlust. På samma sätt som korta tidsgränser för anslutningar kan leda till längre avbrott kan start av många återanslutningsförsök samtidigt också öka serverbelastningen och förlänga hur lång tid det tar för alla klienter att återansluta.

Om du återansluter många klientinstanser bör du överväga att sprida de nya anslutningarna för att undvika en kraftig ökning av antalet anslutna klienter.

Undvik överblivna anslutningar

Cacheminnen har gränser för antalet klientanslutningar per cachenivå. Se till att klientprogrammet stänger och tar bort de gamla anslutningarna när det återskapar anslutningar.

Meddelande om förhandsunderhåll

Använd aviseringar för att lära dig mer om kommande underhåll. Mer information finns i Kan jag meddelas i förväg om ett planerat underhåll.

Schemalägg underhållsperiod

Justera cacheinställningarna för att hantera underhåll. Mer information om hur du skapar ett underhållsfönster för att minska eventuella negativa effekter på cacheminnet finns i Uppdatera kanal och Schemalägg uppdateringar.

Fler designmönster för motståndskraft

Använd designmönster för återhämtning. Mer information finns i Hur gör jag mitt program motståndskraftigt.

Tidsgräns för inaktivitet

Azure Cache for Redis har en tidsgräns på 10 minuter för inaktiva anslutningar. Med tidsgränsen på 10 minuter kan servern automatiskt rensa läckande anslutningar eller anslutningar som är överblivna av ett klientprogram. De flesta Redis-klientbibliotek har en inbyggd funktion för att skicka heartbeat eller keepalive kommandon regelbundet för att förhindra att anslutningar stängs även om det inte finns några begäranden från klientprogrammet.

Om det finns risk för att anslutningarna är inaktiva i 10 minuter konfigurerar du keepalive intervallet till ett värde som är mindre än 10 minuter. Om ditt program använder ett klientbibliotek som inte har inbyggt stöd för keepalive funktioner kan du implementera det i ditt program genom att regelbundet skicka ett PING kommando.

Relaterat innehåll

• Metodtips för utveckling
• Vanliga frågor och svar om Azure Cache for Redis-utveckling
• Redundans och korrigering