Kapcsolat rugalmassága
Újrapróbálkozás parancsai
Konfigurálja az ügyfélkapcsolatokat, hogy exponenciális visszalépéssel próbálkozzon újra a parancsokkal. További információkért lásd az újrapróbálkozáshoz szükséges irányelveket.
A rugalmasság tesztelése
Tesztelje a rendszer kapcsolattörésekkel szembeni rugalmasságát újraindítással egy javítás szimulálásához. A teljesítmény teszteléséről további információt a Teljesítménytesztelés című témakörben talál.
TCP-beállítások Linux által üzemeltetett ügyfélalkalmazásokhoz
Egyes Linux-verziók alapértelmezett TCP-beállításai miatt a Redis-kiszolgálókapcsolatok 13 percig vagy tovább meghiúsulhatnak. Az alapértelmezett beállítások megakadályozhatják, hogy az ügyfélalkalmazás észlelje a lezárt kapcsolatokat, és automatikusan visszaállítsa őket, ha a kapcsolat nem volt zökkenőmentesen lezárva.
A kapcsolat újbóli létesítése meghiúsulhat olyan esetekben, amikor a hálózati kapcsolat megszakad, vagy a Redis-kiszolgáló offline állapotba kerül a nem tervezett karbantartás miatt.
Az alábbi TCP-beállításokat javasoljuk:
| Beállítás | Érték |
|---|---|
net.ipv4.tcp_retries2 |
5 |
A forgatókönyvről további információt a Csatlakozás ion nem hoz létre újra 15 percig, amikor Linuxon fut. Bár ez a vita a StackExchange.Redis kódtárról szól, a Linuxon futó többi ügyfélkódtár is érintett. A magyarázat továbbra is hasznos, és általánosíthat más kódtárakra.
ForceReconnect használata StackExchange.Redis ügyfélkódtárral
Ritkán a StackExchange.Redis nem tud újracsatlakozni a kapcsolat megszakadása után. Ezekben az esetekben az ügyfél újraindítása vagy egy új ConnectionMultiplexer létrehozása megoldja a problémát. Azt javasoljuk, hogy használjon egy szimpla ConnectionMultiplexer mintát, miközben lehetővé teszi az alkalmazások számára, hogy rendszeresen kényszerítse az újracsatlakozást. Tekintse meg a rövid útmutató mintaprojektet, amely a legjobban megfelel az alkalmazás által használt keretrendszernek és platformnak. A rövid útmutatókban egy példa látható erre a kódmintára.
A felhasználóknak kezelniük kell azokat ObjectDisposedException a ConnectionMultiplexer hibákat, amelyek a régi eltitkolásakor fordulhatnak elő.
Hívás ForceReconnectAsync() és RedisConnectionExceptions RedisSocketExceptions. Hívhat is ForceReconnectAsync() RedisTimeoutExceptions, de csak akkor, ha nagyvonalú ReconnectMinInterval és ReconnectErrorThreshold. Ellenkező esetben az új kapcsolatok létrehozása kaszkádolt hibát okozhat egy olyan kiszolgálón, amely túllépi az időkorlátot, mert már túlterhelt.
Egy ASP.NET alkalmazásban a StackExchange.Redis csomag közvetlen használata helyett a Microsoft.Extensions.Caching.StackExchangeRedis csomag integrált implementációját használhatja. Ha a StackExchange.Redis közvetlen használata helyett a Microsoft.Extensions.Caching.StackExchangeRedist használja egy ASP.NET alkalmazásban, a UseForceReconnect tulajdonságot igaz értékre állíthatja:
Microsoft.AspNetCore.Caching.StackExchangeRedis.UseForceReconnect = true
Megfelelő időtúllépések konfigurálása
A kapcsolat rugalmasságában két időtúllépési értéket kell figyelembe venni: a kapcsolódási időtúllépést és a parancs időtúllépését.
Csatlakozás időtúllépés
Ez connect timeout az az idő, amikor az ügyfél megvárja, hogy kapcsolatot létesítsen a Redis-kiszolgálóval. Konfigurálja az ügyfélkódtárat connect timeout úgy, hogy öt másodpercet használjon, így a rendszer számára elegendő idő áll rendelkezésre a csatlakozásra még magasabb CPU-feltételek mellett is.
Egy kis connection timeout érték nem garantálja, hogy az adott időkeretben létrejön a kapcsolat. Ha valami hiba történik (magas ügyfél cpu, magas kiszolgálói PROCESSZOR stb.), akkor egy rövid connection timeout érték miatt a kapcsolat sikertelen lesz. Ez a viselkedés gyakran rosszabbá teszi a rossz helyzetet. A segítség helyett a rövidebb időtúllépések súlyosbítják a problémát azáltal, hogy arra kényszerítik a rendszert, hogy újraindítsa az újracsatlakozás folyamatát, ami egy kapcsolódáshoz –> sikertelen –> újrapróbálkozási ciklushoz vezethet.
Parancs időtúllépése
A legtöbb ügyfélkódtár más időtúllépési konfigurációval command timeoutsrendelkezik, ez az az idő, amelyre az ügyfél a Redis-kiszolgálótól érkező választ várja. Bár öt másodpercnél rövidebb kezdeti beállítást ajánlunk, érdemes lehet a command timeout magasabb vagy alacsonyabb értéket beállítani a forgatókönyvtől és a gyorsítótárban tárolt értékek méretétől függően.
Ha a command timeout kapcsolat túl kicsi, a kapcsolat instabilnak tűnhet. Ha azonban a command timeout parancs túl nagy, előfordulhat, hogy az alkalmazásnak hosszú ideig kell várnia, hogy megtudja, hogy a parancs időtúllépést fog-e végrehajtani.
Ügyfélkapcsolati csúcsok elkerülése
Ne hozzon létre egyszerre több kapcsolatot, amikor újracsatlakozik egy kapcsolat megszakadása után. Hasonlóan ahhoz, ahogyan a rövid kapcsolódási időtúllépések hosszabb kimaradást eredményezhetnek, számos újracsatlakozási kísérlet egyidejű indítása növelheti a kiszolgáló terhelését, és meghosszabbíthatja, hogy az összes ügyfél sikeresen újracsatlakozjon.
Ha több ügyfélpéldányt csatlakoztat újra, fontolja meg az új kapcsolatok átmeneti beállítását, hogy elkerülje a csatlakoztatott ügyfelek számának meredek megugrását.
Feljegyzés
Amikor a StackExchange.Redis ügyfélkódtárat használja, állítsa be abortConnect false a kapcsolati sztring. Javasoljuk, hogy hagyja újracsatlakozni a ConnectionMultiplexer fogópontot. További információ: StackExchange.Redis – ajánlott eljárások.
A hátrahagyott kapcsolatok elkerülése
A gyorsítótárakban korlátozva van az ügyfélkapcsolatok száma gyorsítótárszintenként. Győződjön meg arról, hogy amikor az ügyfélalkalmazás újra létrehozza a bezárt kapcsolatokat, és eltávolítja a régi kapcsolatokat.
Előzetes karbantartási értesítés
Az értesítések segítségével megismerheti a közelgő karbantartást. További információ: Értesítést kaphatok-e a tervezett karbantartás előtt.
Karbantartási időszak ütemezése
Módosítsa a gyorsítótár beállításait a karbantartáshoz. A gyorsítótárra gyakorolt negatív hatások csökkentésére szolgáló karbantartási időszak létrehozásáról további információt a Frissítési csatorna és a Frissítések ütemezése című témakörben talál.
További tervezési minták a rugalmasság érdekében
Tervezési minták alkalmazása a rugalmasság érdekében. További információ: Hogyan az alkalmazás rugalmassá tétele.
Üresjárat időkorlátja
Az Azure Cache for Redis 10 perces időtúllépést biztosít az inaktív kapcsolatokhoz. A 10 perces időtúllépés lehetővé teszi, hogy a kiszolgáló automatikusan megtisztítsa az ügyfélalkalmazás által árvaként kiszivárgott kapcsolatokat vagy kapcsolatokat. A Redis-ügyfélkódtárak többsége beépített képességgel rendelkezik arra, hogy rendszeres időközönként küldjön heartbeat vagy keepalive parancsokat a kapcsolatok bezárásának megakadályozása érdekében, még akkor is, ha nincsenek kérések az ügyfélalkalmazástól.
Ha fennáll a veszélye annak, hogy a kapcsolatok 10 percig tétlenek, konfigurálja az keepalive időközt 10 percnél rövidebb értékre. Ha az alkalmazás olyan ügyféloldali kódtárat használ, amely nem támogatja natív módon a funkcionalitást keepalive , akkor a parancs rendszeres elküldésével PING implementálható az alkalmazásban.