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 Linux-värdbaserade klientprogram
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:
| Inställning | Värde |
|---|---|
net.ipv4.tcp_retries2 |
5 |
Mer information om scenariot finns i Anslut ion inte återupprättas 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 eventuella ObjectDisposedException fel som kan uppstå till följd av att de exponerar den gamla.
Ring efter ForceReconnectAsync()RedisConnectionExceptions och RedisSocketExceptions. Du kan också anropa ForceReconnectAsync() för , men bara om du använder generös och ReconnectMinIntervalReconnectErrorThreshold.RedisTimeoutExceptions 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 Microsoft.Extensions.Cachelagring. StackExchangeRedis-paketet i stället för att använda StackExchange.Redis-paketet direkt. Om du använder Microsoft.Extensions.Cachelagring. 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å sant:
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.
Anslut tidsgräns
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 ta reda på om kommandot kommer att överskrida tidsgränsen eller inte.
Undvika toppar i klientanslutningar
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 häpnadsväckande de nya anslutningarna för att undvika en kraftig ökning av antalet anslutna klienter.
Kommentar
När du använder StackExchange.Redis-klientbiblioteket anger du abortConnect till false i din anslutningssträng. Vi rekommenderar att du låter ConnectionMultiplexer handtaget återansluta. Mer information finns i Metodtips för StackExchange.Redis.
Undvik överblivna anslutningar
Cacheminnen har gränser för antalet klientanslutningar per cachenivå. Se till att när klientprogrammet återskapar anslutningar som stängs och tar bort de gamla anslutningarna.
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 för att göra mitt program motståndskraftigt.
Timeout vid 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.