Odporność połączenia
Polecenia ponawiania prób
Skonfiguruj połączenia klienta, aby ponowić próbę poleceń przy użyciu wycofywania wykładniczego. Aby uzyskać więcej informacji, zobacz wskazówki dotyczące ponawiania prób.
Odporność na testowanie
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 TCP w niektórych wersjach systemu Linux mogą spowodować niepowodzenie połączeń serwera Redis przez 13 minut lub dłużej. Ustawienia domyślne mogą uniemożliwić aplikacji klienckiej wykrywanie zamkniętych połączeń i ich automatyczne przywracanie, 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 zostało zakłócone lub serwer Redis przechodzi w tryb offline w celu nieplanowanej konserwacji.
Zalecamy następujące ustawienia 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 przywracane 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 nie można ponownie nawiązać połączenia z usługą StackExchange.Redis po usunięciu połączenia. W takich przypadkach ponowne uruchomienie klienta lub utworzenie nowego ConnectionMultiplexer rozwiązania problemu. Zalecamy używanie pojedynczego ConnectionMultiplexer wzorca, zezwalając aplikacjom na okresowe wymuszenie ponownego nawiązywania połą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 polecenie ForceReconnectAsync() i RedisConnectionExceptionsRedisSocketExceptions. 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.
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ą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 niepowodzenie połączenia. 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 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 jednak command timeout plik jest zbyt duży, aplikacja może czekać przez długi czas, aby dowiedzieć się, czy polecenie będzie mieć 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 krótkich limitów czasu połączenia , może to spowodować dłuższe przestoje, uruchomienie wielu ponownych prób ponownego nawiązania połączenia w tym samym czasie może również zwiększyć obciążenie serwera i wydłużyć czas pomyślnego nawiązania połączenia przez wszystkich klientów.
Jeśli ponownie łączysz wiele wystąpień klienta, rozważ rozłożenie nowych połączeń, aby uniknąć gwałtownego wzrostu liczby połączonych klientów.
Uwaga
W przypadku korzystania z StackExchange.Redis biblioteki klienta ustaw wartość abortConnect na false w parametrach połączenia. Zalecamy zezwolenie na ponowne nawiązanie 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 pozostałych połączeń
Pamięci podręczne mają limity liczby połączeń klienckich 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ę zostać powiadomiony przed planowaną konserwacją.
Okno obsługi 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
Azure Cache for Redis ma 10-minutowy limit czasu dla bezczynnych połączeń. 10-minutowy limit czasu umożliwia serwerowi automatyczne czyszczenie nieszczelności połączeń lub połączeń oddzielonych przez aplikację kliencką. Większość bibliotek klienckich usługi Redis ma wbudowaną funkcję wysyłania heartbeat poleceń lub keepalive okresowo, aby zapobiec zamykaniu połączeń, nawet jeśli nie ma żadnych żądań z aplikacji klienckiej.
Jeśli istnieje 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 zaimplementować ją w aplikacji, okresowo wysyłając PING polecenie.