Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Důležité
Služba Azure Cache for Redis oznámila časovou osu vyřazení všech skladových položek. Doporučujeme přesunout stávající instance Azure Cache for Redis do Azure Managed Redis , jakmile budete moct.
Další podrobnosti o ukončení podpory:
Příkazy pro opakování
Nakonfigurujte připojení klienta tak, aby opakovalo příkazy s exponenciální prodlevou. 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í obnovení připojení může dojít v situacích, kdy dojde k přerušení síťového připojení nebo server Redis se přestane fungovat kvůli neplánované údržbě.
Doporučujeme tato nastavení protokolu TCP:
| Setting | Hodnota |
|---|---|
net.ipv4.tcp_retries2 |
5 |
Další informace o scénáři najdete v tématu Připojení se při spuštění v Linuxu znovu nenaváže 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žití ForceReconnect s 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 vyřeší problém. Doporučujeme použít vzor singleton ConnectionMultiplexer a současně umožnit aplikacím pravidelné vynucení opětovného 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.
Uživatelé ConnectionMultiplexer musí zpracovávat všechny chyby ObjectDisposedException, ke kterým může dojít v důsledku likvidace starého.
Zavolejte ForceReconnectAsync() a RedisConnectionExceptionsRedisSocketExceptions . Můžete také volat ForceReconnectAsync() pro 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 místo použití balíčku StackExchange.Redis použít integrovanou implementaci v balíčku Microsoft.Extensions.Caching.StackExchangeRedis. Pokud používáte Microsoft.Extensions.Caching.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é zvážit dvě hodnoty časového limitu: časový limit připojení a časový limit příkazu.
Časový limit 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. Namísto toho, aby pomohly, kratší časové limity zhoršují problém vynucením opětovného spuštění systému a procesu opětovného 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říliš malé, může připojení působit 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.
Vyhněte se š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 připojovacím řetězci false. Doporučujeme nechat ConnectionMultiplexer zajistit opětovné připojení. Další informace naleznete v tématu StackExchange.Redis osvědčené postupy.
Vyhněte se nevyužitý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í, 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 Jak nastavit odolnost 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 připojení, která ztrácejí zdroje, nebo která byla osamocena 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.