Anslutningsåter återhämtning
Kommandon för återförsök
Konfigurera klientanslutningarna för att försöka igen med exponentiell backoff. Mer information finns i riktlinjer för återförsök.
Testa återhämtning
Testa systemets motståndskraft mot anslutningsavbrott med hjälp av en omstart för att simulera en korrigering. Mer information om hur du testar prestanda finns i Prestandatestning.
TCP-inställningar för Linux-värdbaserade klientprogram
Vissa Linux-versioner använder optimistiska TCP-inställningar som standard. TCP-inställningarna kan skapa en situation där en klientanslutning till en cache inte kan återupprättas under en längre tid när en Redis-server slutar svara innan anslutningen stängs på ett smidigt sätt. Det går inte att återupprätta en anslutning om den primära noden i Azure Cache For Redis blir otillgänglig, till exempel för oplanerat underhåll.
Vi rekommenderar följande TCP-inställningar:
| Inställning | Värde |
|---|---|
| net.ipv4.tcp_retries2 | 5 |
Mer information om scenariot finns i Connection does not re-establish for 15 minutes when running on Linux(Anslutningen upprättas inte igen på 15 minuter när den körs på Linux). Den här diskussionen handlar om StackExchange.Redis-biblioteket, men även andra klientbibliotek som körs på Linux påverkas. 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 när en anslutning har tagits bort. I dessa fall åtgärdar du problemet genom att starta om klienten ConnectionMultiplexer eller skapa en ny. Vi rekommenderar att du använder ett ConnectionMultiplexer singleton-mönster samtidigt som du tillåter att appar framt tvingar fram en återanslutning med jämna mellanrum. Ta en titt på det snabbstartsexempelprojekt som bäst matchar det ramverk och den plattform som programmet 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 fel som kan uppstå till följd av att den gamla tas ObjectDisposedException bort.
Anropa ForceReconnectAsync() för RedisConnectionExceptions och RedisSocketExceptions . Du kan också anropa ForceReconnectAsync() för , men bara om du använder and RedisTimeoutExceptions ReconnectMinInterval ReconnectErrorThreshold . I annat fall kan etablering av nya anslutningar orsaka ett kaskadfel på en server som har en feltidsinställning eftersom den redan är överbelastad.
Konfigurera lämpliga tidsgränser
Två timeout-värden är viktiga att tänka på när det gäller anslutningsåteråtertagande: tidsgräns för anslutning och tidsgräns för kommando.
Anslut tidsgräns
connect timeoutär den tid som klienten väntar på att upprätta en anslutning till Redis-servern. Konfigurera klientbiblioteket så att det använder connect timeout fem 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 värde att connection timeout anslutningsförsöket misslyckas. Det här beteendet gör ofta en dålig situation sämre. I stället för att hjälpa till kan kortare tidsgränser lösa problemet genom att tvinga systemet att starta om processen med att försöka återansluta, vilket kan leda till att en anslutnings-> misslyckas -> återförsöksloop.
Tidsgräns för kommando
De flesta klientbibliotek har en annan timeout-konfiguration för , vilket är den tid som klienten command timeouts 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 eller lägre beroende på ditt scenario och storleken på de värden som command timeout lagras i cacheminnet.
Om är command timeout för liten kan anslutningen se instabil ut. Men om är för stort kan programmet behöva vänta länge för att ta reda på om kommandot kommer att ta time command timeout out 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 anslutning kan resultera i längre avbrott, kan start av många återanslutningsförsök samtidigt också öka serverbelastningen och utöka hur lång tid det tar för alla klienter att återansluta.
Om du ansluter många klientinstanser bör du överväga att sprida de nya anslutningarna för att undvika en plötslig topp i antalet anslutna klienter.
Anteckning
När du använder StackExchange.Redis klientbiblioteket anger du abortConnect till i false anslutningssträngen. Vi rekommenderar att du ConnectionMultiplexer låter referensen återansluta. Mer information finns i Bästa praxis för StackExchange.Redis.
Undvik övergående anslutningar
Cacheminnen har begränsningar 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ör avancerat underhåll
Använd meddelanden för att lära dig om kommande underhåll. Mer information finns i Kan jag meddelas i förväg om ett planerat underhåll.
Schemalägg underhållsfönstret
Justera dina cacheinställningar för att hantera underhåll. Mer information om hur du skapar en underhållsfönstret för att minska eventuella negativa effekter på cacheminnet finns i Schemalägg uppdateringar.
Fler designmönster för återhämtning
Tillämpa designmönster för återhämtning. Mer information finns i Hur gör jag för att gör mitt program motståndskraftigt.
Timeout för inaktivitet
Azure Cache for Redis har för närvarande en tidsgräns på 10 minuter för inaktivitet för anslutningar, så tidsgränsen för inaktivitet i klientprogrammet bör vara mindre än 10 minuter. De vanligaste klientbiblioteken har en konfigurationsinställning som gör att klientbibliotek kan skicka PING Redis-kommandon till en Redis-server automatiskt och regelbundet. Men när du använder klientbibliotek utan den här typen av inställning ansvarar själva kundprogrammen för att hålla anslutningen vid liv.