Odporność połączenia
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.
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:
| Ustawienie | Wartość |
|---|---|
net.ipv4.tcp_retries2 |
5 |
Aby uzyskać więcej informacji na temat scenariusza, zobacz Połączenie ion nie ustanawia się ponownie 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 pliku Microsoft.Extensions.Buforowanie. Pakiet StackExchangeRedis zamiast bezpośrednio używać pakietu StackExchange.Redis. Jeśli używasz pliku Microsoft.Extensions.Buforowanie. StackExchangeRedis w aplikacji ASP.NET zamiast bezpośrednio używać stackExchange.Redis, można 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łączenie
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. 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ż rozsyłanie nowych połączeń, aby uniknąć gwałtownego wzrostu liczby połączonych klientów.
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.
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 Jak mogę uczynić moją aplikację odporną.
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 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.