Odolnost připojení
Příkazy pro opakování
Nakonfigurujte připojení klienta k opakování příkazů s exponenciálním zpochybováním. Další informace najdete v pokynech pro opakování.
Odolnost proti testům
Otestujte odolnost systému vůči přerušením připojení pomocí restartování k simulaci opravy. Další informace o testování výkonu najdete v tématu Testování výkonu.
Nastavení protokolu TCP pro klientské aplikace hostované v Linuxu
Výchozí nastavení PROTOKOLU TCP v některých verzích Linuxu může způsobit selhání připojení k serveru Redis po dobu 13 minut nebo více. Výchozí nastavení může klientské aplikaci zabránit v detekci uzavřených připojení a jejich automatickému obnovení, pokud připojení nebylo řádně uzavřeno.
K selhání opětovného publikování připojení může dojít v situacích, kdy dojde k přerušení síťového připojení nebo server Redis přejde do režimu offline kvůli neplánované údržbě.
Doporučujeme tato nastavení protokolu TCP:
| Nastavení | Hodnota |
|---|---|
net.ipv4.tcp_retries2 |
5 |
Další informace o scénáři najdete v tématu Připojení ion při spuštění v Linuxu po dobu 15 minut. I když je tato diskuze o knihovně StackExchange.Redis , ovlivní to i ostatní klientské knihovny spuštěné v Linuxu. Vysvětlení je stále užitečné a můžete generalizovat do jiných knihoven.
Používání metody ForceReconnect s klientem StackExchange.Redis
Ve výjimečných případech se StackExchange.Redis po vyřazení připojení znovu nepřipojí. V těchto případech restartování klienta nebo vytvoření nové ConnectionMultiplexer opravy problému. Doporučujeme použít jeden ConnectionMultiplexer vzor a současně umožnit aplikacím pravidelné opětovné připojení. Podívejte se na ukázkový projekt rychlého startu, který nejlépe odpovídá rozhraní a platformě, kterou vaše aplikace používá. Příklad tohoto vzoru kódu si můžete prohlédnout v našich rychlých startech.
ConnectionMultiplexer Uživatelé musí zpracovávat všechny ObjectDisposedException chyby, ke kterým může dojít v důsledku odstranění starého.
Zavolejte ForceReconnectAsync() a RedisSocketExceptionsRedisConnectionExceptions . Můžete také volat ForceReconnectAsync()RedisTimeoutExceptions, ale pouze pokud používáte velkorysé ReconnectMinInterval a ReconnectErrorThreshold. V opačném případě může navazování nových připojení způsobit kaskádové selhání na serveru, který vypršel časový limit, protože je již přetížen.
V ASP.NET aplikaci můžete použít integrovanou implementaci v microsoft.Extensions.Ukládání do mezipaměti. Balíček StackExchangeRedis místo použití balíčku StackExchange.Redis přímo. Pokud používáte Microsoft.Extensions.Ukládání do mezipaměti. StackExchangeRedis v aplikaci ASP.NET místo použití StackExchange.Redis přímo, můžete vlastnost nastavit UseForceReconnect na true:
Microsoft.AspNetCore.Caching.StackExchangeRedis.UseForceReconnect = true
Konfigurace vhodných časových limitů
Při odolnosti připojení je důležité vzít v úvahu dvě hodnoty časového limitu časového limitu připojení a vypršení časového limitu příkazu.
vypršení časového limitu Připojení
Doba connect timeout , kdy klient čeká na navázání připojení k serveru Redis. Nakonfigurujte klientskou knihovnu tak, aby používala pět connect timeout sekund, což systému dává dostatek času na připojení i za vyšších podmínek procesoru.
Malá connection timeout hodnota nezaručuje vytvoření připojení v daném časovém rámci. Pokud se něco nepovede (vysoké využití procesoru klienta, vysoké využití procesoru serveru atd.), pak krátká connection timeout hodnota způsobí selhání pokusu o připojení. Toto chování často zhoršuje špatnou situaci. Místo pomoci, kratší vypršení časového limitu zhoršuje problém vynucením restartování systému restartováním procesu pokusu o opětovné připojení, což může vést k připojení -> selhání -> opakování smyčky.
Časový limit příkazu
Většina klientských knihoven má jinou konfiguraci command timeoutsčasového limitu , což je čas, kdy klient čeká na odpověď ze serveru Redis. I když doporučujeme počáteční nastavení kratší než pět sekund, zvažte nastavení command timeout vyšší nebo nižší v závislosti na vašem scénáři a velikosti hodnot uložených v mezipaměti.
command timeout Pokud je připojení příliš malé, může vypadat nestabilní. Pokud je ale command timeout příliš velký, vaše aplikace možná bude muset dlouho počkat, abyste zjistili, jestli příkaz vyprší nebo ne.
Zabránění špičkám připojení klientů
Vyhněte se vytváření mnoha připojení současně při opětovném připojení po ztrátě připojení. Podobně jako krátké vypršení časových limitů připojení může vést k delším výpadkům. Spuštěním mnoha opakovaných pokusů o připojení současně se také může zvýšit zatížení serveru a prodloužit dobu, po kterou se všichni klienti úspěšně připojí.
Pokud znovu připojujete mnoho klientských instancí, zvažte rozsažení nových připojení, abyste se vyhnuli strmému nárůstu počtu připojených klientů.
Poznámka:
Pokud používáte klientskou knihovnu StackExchange.Redis, nastavte abortConnect v false připojovací řetězec. Doporučujeme nechat popisovač ConnectionMultiplexer znovu připojit. Další informace naleznete v tématu StackExchange.Redis osvědčené postupy.
Vyhněte se levým připojením
Mezipaměti mají omezení počtu klientských připojení na úroveň mezipaměti. Ujistěte se, že když klientská aplikace znovu vytvoří připojení, která zavře a odebere stará připojení.
Oznámení o předběžné údržbě
Pomocí oznámení se dozvíte o nadcházející údržbě. Další informace naleznete v tématu Mohu být informován předem o plánované údržbě.
Naplánovat časové období údržby
Upravte nastavení mezipaměti tak, aby vyhovovala údržbě. Další informace o vytvoření časového období údržby, abyste snížili negativní dopady na mezipaměť, najdete v tématu Aktualizace kanálu a plánování aktualizací.
Další vzory návrhu pro odolnost
Použití vzorů návrhu pro odolnost Další informace najdete v tématu Návody zajištění odolnosti aplikace.
Časový limit nečinnosti
Azure Cache for Redis má 10minutový časový limit pro nečinná připojení. 10minutový časový limit umožňuje serveru automaticky vyčistit nevracená připojení nebo osamocené klientskou aplikací. Většina klientských knihoven Redis má integrovanou funkci pravidelného odesílání heartbeat nebo keepalive příkazů, aby se zabránilo zavření připojení, i když klientská aplikace neobsahuje žádné požadavky.
Pokud existuje riziko nečinnosti připojení po dobu 10 minut, nakonfigurujte keepalive interval na hodnotu menší než 10 minut. Pokud vaše aplikace používá klientskou knihovnu, která nemá nativní podporu funkcí keepalive , můžete ji v aplikaci implementovat pravidelným odesláním PING příkazu.