Odolnost připojení
Příkazy opakování
Nakonfigurujte připojení klientů k opakovaným příkazům pomocí exponenciální omezení rychlosti. Další informace najdete v tématu pokyny pro opakování.
Odolnost testu
Otestujte odolnost svého systému na přerušení připojení pomocí restartování , aby se mohla simulovat oprava. Další informace o testování výkonu najdete v tématu testování výkonu.
Nastavení TCP pro klientské aplikace hostované na platformě Linux
Některé verze systému Linux standardně používají optimistická nastavení protokolu TCP. Nastavení protokolu TCP může vytvořit situaci, kdy se připojení klienta k mezipaměti nemůže znovu vytvořit po dlouhou dobu, než server Redis přestane reagovat před řádným ukončením připojení. Pokud primární uzel vaší mezipaměti Azure pro Redis nebude k dispozici, například pro neplánovanou údržbu, může dojít k selhání opětovného navázání připojení.
Doporučujeme tato nastavení TCP:
| Nastavení | Hodnota |
|---|---|
| net.ipv4.tcp_retries2 | 5 |
Další informace o tomto scénáři najdete v tématu připojení není znovu navázáno na 15 minut při spuštění v systému Linux. I když je tato diskuze o knihovně StackExchange. Redis, ovlivní taky další klientské knihovny, které jsou spuštěné v systému Linux. Vysvětlení je stále užitečné a můžete zobecnit 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í nepovede znovu připojit. V těchto případech restartujte klienta nebo vytvořte nové ConnectionMultiplexer řešení problému. Doporučujeme použít vzor singleton a ConnectionMultiplexer Povolit aplikacím tak, aby bylo opakované připojení pravidelně vynutilo. Podívejte se na vzorový projekt rychlý Start, který nejlépe odpovídá rozhraní a platformě, kterou vaše aplikace používá. Příklady tohoto vzoru kódu si můžete prohlédnout v našich rychlých startech.
Uživatelé ConnectionMultiplexer musí ObjectDisposedException považovat všechny chyby, které mohou nastat v důsledku likvidace staré z nich.
Volání ForceReconnectAsync() RedisConnectionExceptions a RedisSocketExceptions . Můžete také volat ForceReconnectAsync() pro RedisTimeoutExceptions , ale pouze v případě, že používáte velkorysá ReconnectMinInterval a ReconnectErrorThreshold . V opačném případě může vytvoření nových připojení způsobit selhání kaskády na serveru, který je v čase, protože je již přetížený.
Konfigurace vhodných časových limitů
Dvě hodnoty časového limitu je důležité zvážit v odolnost připojení: časový limit připojení a časový limit příkazu.
časový limit Připojení
connect timeoutJe čas, kdy klient čeká na navázání připojení k serveru Redis. Nakonfigurujte klientskou knihovnu tak, aby používala connect timeout pět sekund, a systém poskytne dostatek času na připojení i v rámci vyšších procesorových podmínek.
Malá connection timeout hodnota nezaručuje, že se v daném časovém rámci vytvoří připojení. Pokud dojde k nějakému problému (vysoký procesor procesoru, vysoký procesor serveru atd.), pak krátká connection timeout hodnota způsobí selhání pokusu o připojení. Toto chování často způsobuje horší špatnou situaci. Namísto zvýšení časových limitů tím, že se postará o problém, vynutí systém restartování procesu pokusu o opětovné připojení, což může vést k selhání > typu Connect-> .
Časový limit příkazu
Většina klientských knihoven má další konfiguraci časového limitu pro command timeouts , což je čas, kdy klient čeká na odpověď ze serveru Redis. I když doporučujeme počáteční nastavení méně 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.
Pokud command timeout je příliš malý, může připojení vypadat nestabilní. Je-li však command timeout příliš velký, může aplikace čekat na dlouhou dobu, aby zjistili, zda je příkaz vyprší nebo ne.
Vyhněte se špičkám připojení klientů
Vyhněte se vytváření řady připojení současně při opětovném připojení po ztrátě připojení. Podobně jako u krátkých časových limitů připojení může docházet k delším výpadkům, přičemž se může také zvýšit zatížení serveru a prodloužit dobu potřebnou k úspěšnému opětovnému připojení všech klientů.
Pokud znovu připojujete mnoho instancí klienta, zvažte nové připojení, abyste se vyhnuli strmé špičkě v počtu připojených klientů.
Poznámka
Když použijete StackExchange.Redis knihovnu klienta, nastavte abortConnect na false připojovací řetězec. Doporučujeme, abyste umožnili ConnectionMultiplexer opětovné připojení popisovače. Další informace najdete v tématu osvědčené postupy pro stackexchange. Redis.
Vyhněte se připojením zbylé
Mezipaměti mají omezení počtu připojení klientů na úrovni mezipaměti. Ujistěte se, že když klientská aplikace znovu vytvoří připojení, která zavírá, a odebere stará připojení.
Oznámení o údržbě předem
Využijte oznámení a Naučte se s nadcházející údržbou. Další informace najdete v tématu o tom, jak se mám informovat předem o plánované údržbě.
Naplánovat časový interval pro správu a údržbu
Upravte nastavení mezipaměti tak, aby vyhovovalo údržbě. Další informace o vytvoření časového období údržby pro snížení negativních účinků do mezipaměti najdete v tématu Plánování aktualizací.
Další vzory návrhu pro odolnost
Použijte vzory návrhu pro odolnost proti chybám. Další informace najdete v tématu návody zajištění odolnosti aplikace.
Časový limit nečinnosti
Mezipaměť Azure pro Redis má v současnosti časový limit nečinnosti pro připojení 10 minut, takže nastavení časový limit nečinnosti v klientské aplikaci by měl být kratší než 10 minut. Většina běžných klientských knihoven má konfigurační nastavení, které umožňuje klientským knihovnám odesílat PING příkazy Redis na server Redis automaticky a pravidelně. Pokud ale použijete klientské knihovny bez tohoto typu nastavení, zodpovídají za udržování připojení aktivní aplikace zákazníka.