Odporność połączeń za pomocą usługi Azure Managed Redis (wersja zapoznawcza)
Ponów próbę poleceń
Skonfiguruj połączenia klienta, aby ponowić próby za pomocą wycofywania wykładniczego. Aby uzyskać więcej informacji, zobacz wskazówki dotyczące ponawiania prób.
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:
| Ustawienie | 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 uogólnić inne biblioteki.
Używanie funkcji 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ązania problemu. Zalecamy używanie pojedynczego ConnectionMultiplexer wzorca, umożliwiając aplikacjom okresowe wymuszenie 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 przewodnikach Szybki start.
Użytkownicy programu ConnectionMultiplexer muszą obsługiwać wszelkie ObjectDisposedException błędy, które mogą wystąpić w wyniku rozdysponowania starego.
Wywołaj metodę ForceReconnectAsync() 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średnio używać pakietu StackExchange.Redis . Jeśli używasz biblioteki Microsoft.Extensions.Caching.StackExchangeRedis w aplikacji ASP.NET zamiast bezpośrednio używać biblioteki StackExchange.Redis , możesz ustawić UseForceReconnect właściwość na 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, zapewniając systemowi wystarczający czas, aby nawiązać połączenie nawet w wyższych warunkach procesora CPU.
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 polecenia
Większość bibliotek klienckich ma inną konfigurację limitu czasu dla command timeoutsprogramu , czyli 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. Jeśli command timeout jednak aplikacja jest zbyt duża, może być konieczne odczekanie długiego czasu, aby dowiedzieć się, czy polecenie ma upłynął limit czasu, czy nie.
Unikanie skokowych wzrostów liczby połączeń klientów
Unikaj tworzenia wielu połączeń jednocześnie podczas ponownego nawiązywania połączenia po utracie połączenia, ponieważ nowe tworzenie połączeń jest ograniczone. 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ń klienta, rozważ rozsyłanie nowych połączeń, aby uniknąć ograniczania nowych połączeń.
Uwaga
W przypadku korzystania z biblioteki klienta StackExchange.Redis ustaw wartość false abortConnect na w parametry połączenia. Zalecamy umożliwienie ponownego nawiązania połączenia z dojściem ConnectionMultiplexer . 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 utworzy połączenia, które zamknie i usunie stare połączenia.
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 Jak mogę uczynić moją aplikację odporną.
Limit czasu bezczynności
Usługa Azure Managed Redis (wersja zapoznawcza) ma 10-minutowy limit czasu dla bezczynnych połączeń. 10-minutowy limit czasu umożliwia serwerowi automatyczne czyszczenie nieszczelnych połączeń lub połączeń oddzielonych przez aplikację kliencką. Większość bibliotek klienckich usługi Redis ma wbudowaną funkcję heartbeat wysyłania poleceń lub keepalive okresowo, aby zapobiec zamykaniu połączeń, nawet jeśli nie ma żadnych żądań z aplikacji klienckiej.
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.