Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Ważne
Usługa Azure Cache for Redis ogłosiła harmonogram wycofania wszystkich SKU. Zalecamy przeniesienie istniejących wystąpień usługi Azure Cache for Redis do usługi Azure Managed Redis tak szybko, jak to możliwe.
Aby uzyskać więcej informacji na temat przejścia na emeryturę:
Ponowne uruchomienie poleceń
Skonfiguruj połączenia klienta, aby ponawiać polecenia z wykorzystaniem strategii wykładniczego opóźnienia. Aby uzyskać więcej informacji, zobacz wskazówki dotyczące ponawiania prób.
Odporność testowa
Przetestuj odporność systemu na przerwy połączeń przy użyciu ponownego uruchomienia w celu symulowania poprawki. Aby uzyskać więcej informacji na temat testowania wydajności, zobacz Testowanie wydajności.
Ustawienia PROTOKOŁU TCP dla aplikacji klienckich hostowanych w systemie Linux
Domyślne ustawienia protokołu TCP w niektórych wersjach systemu Linux mogą powodować niepowodzenie połączeń serwera Redis przez 13 minut lub więcej. Ustawienia domyślne mogą uniemożliwić aplikacji klienckiej wykrywanie zamkniętych połączeń i przywracanie ich automatycznie, jeśli połączenie nie zostało bezpiecznie zamknięte.
Niepowodzenie ponownego utworzenia połączenia może wystąpić w sytuacjach, w których połączenie sieciowe jest zakłócane lub serwer Redis przechodzi w tryb offline w celu nieplanowanej konserwacji.
Zalecamy następujące ustawienia PROTOKOŁU TCP:
| Setting | Wartość |
|---|---|
net.ipv4.tcp_retries2 |
5 |
Aby uzyskać więcej informacji na temat scenariusza, zobacz Connection does not re-establish for 15 minutes when running on Linux (Połączenie nie jest ponownie ustanawiane przez 15 minut podczas uruchamiania w systemie Linux). Chociaż ta dyskusja dotyczy biblioteki StackExchange.Redis , inne biblioteki klienckie działające w systemie Linux również mają wpływ. Wyjaśnienie jest nadal przydatne i można je uogólnić dla innych bibliotek.
Używanie programu ForceReconnect z usługą StackExchange.Redis
W rzadkich przypadkach usługa StackExchange.Redis nie może ponownie nawiązać połączenia po usunięciu połączenia. W takich przypadkach ponowne uruchomienie klienta lub utworzenie nowego ConnectionMultiplexer rozwiązuje problem. Zalecamy używanie wzorca singleton ConnectionMultiplexer, dając aplikacjom możliwość okresowego wymuszenia ponownego łączenia. Zapoznaj się z przykładowym projektem szybkiego startu, który najlepiej pasuje do struktury i platformy używanej przez aplikację. Przykład tego wzorca kodu można zobaczyć w naszych samouczkach.
Użytkownicy programu ConnectionMultiplexer muszą obsługiwać wszelkie ObjectDisposedException błędy, które mogą wystąpić w wyniku utylizacji starego elementu.
Wywołaj ForceReconnectAsync() dla RedisConnectionExceptions i RedisSocketExceptions. Możesz również wezwać ForceReconnectAsync() do RedisTimeoutExceptions, ale tylko wtedy, gdy używasz hojnych ReconnectMinInterval i ReconnectErrorThreshold. W przeciwnym razie ustanowienie nowych połączeń może spowodować awarię kaskadową na serwerze, który przekracza limit czasu, ponieważ jest już przeciążony.
W aplikacji ASP.NET można użyć zintegrowanej implementacji w pakiecie Microsoft.Extensions.Caching.StackExchangeRedis zamiast bezpośredniego używania pakietu StackExchange.Redis . Jeśli w aplikacji ASP.NET używasz Microsoft.Extensions.Caching.StackExchangeRedis zamiast bezpośrednio używać StackExchange.Redis, możesz ustawić właściwość na wartość true:
Microsoft.AspNetCore.Caching.StackExchangeRedis.UseForceReconnect = true
Konfigurowanie odpowiednich limitów czasu
Dwie wartości limitu czasu są ważne, aby wziąć pod uwagę odporność połączenia: limit czasu połączenia i limit czasu polecenia.
Limit czasu połączenia
Jest connect timeout to czas oczekiwania klienta na nawiązanie połączenia z serwerem Redis. Skonfiguruj bibliotekę klienta tak, aby korzystała z connect timeout pięciu sekund, dając systemowi wystarczająco dużo czasu na nawiązanie połączenia nawet przy wyższym obciążeniu procesora.
Niewielka connection timeout wartość nie gwarantuje ustanowienia połączenia w tym przedziale czasu. Jeśli coś pójdzie nie tak (wysokie użycie procesora CPU klienta, wysokie użycie procesora CPU serwera itd.), krótka connection timeout wartość powoduje, że próba nawiązania połączenia zakończy się niepowodzeniem. To zachowanie często pogarsza złą sytuację. Zamiast pomagać, krótsze przekroczenia limitu czasu pogarszają problem, zmuszając system do ponownego uruchomienia procesu próby ponownego nawiązania połączenia, co może prowadzić do nawiązania połączenia —> niepowodzenie —> pętla ponawiania prób .
Limit czasu wykonania polecenia
Większość bibliotek klienckich ma inną konfigurację limitu czasu dla command timeouts, co oznacza czas oczekiwania klienta na odpowiedź z serwera Redis. Mimo że zalecamy wstępne ustawienie mniejsze niż pięć sekund, rozważ ustawienie command timeout wyższego lub niższego w zależności od scenariusza i rozmiarów wartości przechowywanych w pamięci podręcznej.
Jeśli parametr command timeout jest za mały, połączenie może wyglądać niestabilnie. Jednak, jeśli command timeout jest zbyt duże, Twoja aplikacja może być zmuszona poczekać długo, aby dowiedzieć się, czy polecenie przekroczy limit czasu, czy nie.
Unikaj nagłych wzrostów liczby połączeń klientów
Unikaj tworzenia wielu połączeń jednocześnie podczas ponownego nawiązywania połączenia po utracie połączenia. Podobnie jak w przypadku, gdy krótkie przekroczenia limitu czasu połączenia mogą powodować dłuższe przerwy w działaniu, uruchomienie wielu ponownych prób nawiązania połączenia w tym samym czasie może również zwiększyć obciążenie serwera i wydłużyć czas potrzebny wszystkim klientom na pomyślne ponowne nawiązanie połączenia.
Jeśli ponownie łączysz wiele wystąpień klientów, rozważ stopniowe nawiązywanie nowych połączeń, aby uniknąć gwałtownego wzrostu liczby połączeń.
Uwaga / Notatka
W przypadku korzystania z biblioteki klienta StackExchange.Redis ustaw wartość abortConnect na false w parametrach połączenia. Zalecamy pozwolić ConnectionMultiplexer na obsługę ponownego połączenia. Aby uzyskać więcej informacji, zobacz StackExchange.Redis best practices (Najlepsze rozwiązania dotyczące usługi StackExchange.Redis).
Unikaj połączeń pozostałych
Pamięci podręczne mają limity liczby połączeń klientów na warstwę pamięci podręcznej. Upewnij się, że gdy aplikacja kliencka ponownie tworzy połączenia, zamyka i usuwa stare połączenia.
Powiadomienie o konserwacji z wyprzedzeniem
Użyj powiadomień, aby dowiedzieć się więcej o nadchodzącej konserwacji. Aby uzyskać więcej informacji, zobacz Czy mogę otrzymywać powiadomienia z wyprzedzeniem o planowanej konserwacji.
Okno konserwacji harmonogramu
Dostosuj ustawienia pamięci podręcznej, aby uwzględnić konserwację. Aby uzyskać więcej informacji na temat tworzenia okna obsługi w celu zmniejszenia negatywnych skutków dla pamięci podręcznej, zobacz Aktualizowanie kanału i Planowanie aktualizacji.
Więcej wzorców projektowych pod kątem odporności
Stosowanie wzorców projektowych w celu zapewnienia odporności. Aby uzyskać więcej informacji, zobacz How do I make my application resilient (Jak mogę zapewnić odporność aplikacji).
Limit czasu bezczynności
Usługa Azure Cache for Redis ma 10-minutowy limit czasu dla bezczynnych połączeń. 10-minutowy limit czasu umożliwia serwerowi automatyczne czyszczenie przeciekających połączeń lub połączeń osieroconych przez aplikację kliencką. Większość bibliotek klienckich usługi Redis ma wbudowaną funkcję do okresowego wysyłania poleceń heartbeat lub keepalive, aby zapobiec zamykaniu połączeń, nawet jeśli aplikacja kliencka nie wysyła żadnych żądań.
Jeśli istnieje jakiekolwiek ryzyko bezczynności połączeń przez 10 minut, skonfiguruj keepalive interwał na wartość mniejszą niż 10 minut. Jeśli aplikacja korzysta z biblioteki klienta, która nie ma natywnej obsługi keepalive funkcji, możesz ją zaimplementować w aplikacji, okresowo wysyłając PING polecenie.