Opracowywanie zawartości

  • Artykuł
  • Czas czytania: 7 min

Odporność połączenia i obciążenie serwera

Podczas opracowywania aplikacji klienckich należy wziąć pod uwagę odpowiednie najlepsze rozwiązania dotyczące odporności połączenia i zarządzania obciążeniem serwera.

Rozważ więcej kluczy i mniejszych wartości

Azure Cache for Redis działa najlepiej z mniejszymi wartościami. Rozważ podzielenie większych fragmentów danych na mniejsze fragmenty w celu rozłożenia danych na wiele kluczy. Aby uzyskać więcej informacji na temat idealnego rozmiaru wartości, zobacz ten artykuł.

Duży rozmiar żądania lub odpowiedzi

Duże żądanie/odpowiedź mogą powodować przekroczenia limitu czasu. Załóżmy na przykład, że wartość limitu czasu skonfigurowana na kliencie wynosi 1 sekundę. Aplikacja żąda dwóch kluczy (na przykład "A" i "B") jednocześnie (przy użyciu tego samego połączenia sieciowego). Większość klientów obsługuje żądanie "pipelining", gdzie oba żądania "A" i "B" są wysyłane jeden po drugim bez oczekiwania na odpowiedzi. Serwer wysyła odpowiedzi z powrotem w tej samej kolejności. Jeśli odpowiedź "A" jest duża, może jeść większość limitu czasu dla późniejszych żądań.

W poniższym przykładzie żądanie "A" i "B" są wysyłane szybko do serwera. Serwer szybko uruchamia wysyłanie odpowiedzi "A" i "B". Ze względu na czas transferu danych odpowiedź "B" musi czekać za odpowiedzią "A", nawet jeśli serwer szybko zareagował.

|-------- 1 Second Timeout (A)----------|
|-Request A-|
     |-------- 1 Second Timeout (B) ----------|
     |-Request B-|
            |- Read Response A --------|
                                       |- Read Response B-| (**TIMEOUT**)

To żądanie/odpowiedź jest trudne do zmierzenia. Możesz instrumentować kod klienta w celu śledzenia dużych żądań i odpowiedzi.

Rozwiązania dotyczące dużych rozmiarów odpowiedzi są zróżnicowane, ale obejmują:

  • Zoptymalizuj aplikację pod kątem dużej liczby małych wartości, a nie kilku dużych wartości.
  • Zwiększ rozmiar maszyny wirtualnej, aby uzyskać większą przepustowość
    • Większa przepustowość na maszynie wirtualnej klienta lub serwera może zmniejszyć czas transferu danych w przypadku większych odpowiedzi.
    • Porównaj bieżące użycie sieci na obu maszynach z limitami bieżącego rozmiaru maszyny wirtualnej. Większa przepustowość tylko na serwerze lub tylko na kliencie może być niewystarczająca.
  • Zwiększ liczbę obiektów połączenia używanych przez aplikację.
    • Użyj podejścia okrężnego, aby wysyłać żądania w różnych obiektach połączenia.

Dystrybucja kluczy

Jeśli planujesz używać klastrowania Redis, najpierw przeczytaj Artykuł Redis Clustering Best Practices with Keys (Najlepsze rozwiązania dotyczące klastrowania redis z kluczami).

Korzystanie z potokowania

Spróbuj wybrać klienta usługi Redis, który obsługuje potokowanie usługi Redis. Potokowanie pomaga efektywnie korzystać z sieci i uzyskać najlepszą możliwą przepływność.

Unikaj kosztownych operacji

Niektóre operacje usługi Redis, takie jak polecenie KEYS , są kosztowne i należy unikać. Aby zapoznać się z niektórymi zagadnieniami dotyczącymi długotrwałych poleceń, zobacz długotrwałe polecenia.

Wybieranie odpowiedniej warstwy

Użyj warstwy Standardowa lub Premium dla systemów produkcyjnych. Nie używaj warstwy Podstawowa w środowisku produkcyjnym. Warstwa Podstawowa to pojedynczy system węzłów bez replikacji danych i bez umowy SLA. Ponadto można użyć przynajmniej pamięci podręcznej C1. Pamięci podręczne C0 są przeznaczone tylko dla prostych scenariuszy tworzenia i testowania, ponieważ:

  • współużytkują rdzenie procesora CPU
  • użyj małej ilości pamięci
  • są podatne na hałaśliwych problemów z sąsiadami

Zalecamy testowanie wydajności, aby wybrać odpowiednią warstwę i zweryfikować ustawienia połączenia. Aby uzyskać więcej informacji, zobacz Testowanie wydajności.

Klient w tym samym regionie co pamięć podręczna

Znajdź wystąpienie pamięci podręcznej i aplikację w tym samym regionie. Łączenie się z pamięcią podręczną w innym regionie może znacznie zwiększyć opóźnienie i ograniczyć niezawodność.

Chociaż możesz nawiązać połączenie spoza platformy Azure, nie jest to zalecane szczególnie w przypadku korzystania z usługi Redis jako pamięci podręcznej. Jeśli używasz serwera Redis jako magazynu kluczy/wartości, opóźnienie może nie być głównym problemem.

Polegaj na nazwie hosta, która nie ma publicznego adresu IP

Publiczny adres IP przypisany do pamięci podręcznej może ulec zmianie w wyniku operacji skalowania lub poprawy zaplecza. Zalecamy poleganie na nazwie hosta zamiast jawnego publicznego adresu IP. Poniżej przedstawiono zalecane formularze dla różnych warstw:

Warstwa Formularz
Podstawowa, Standardowa, Premium <cachename>.redis.cache.windows.net
Enterprise, Enterprise Flash <DNS name>.<Azure region>.redisenterprise.cache.azure.net.

Wybieranie odpowiedniej wersji usługi Redis

Domyślna wersja usługi Redis używana podczas tworzenia pamięci podręcznej może ulec zmianie w czasie. Azure Cache for Redis może przyjąć nową wersję po wydaniu nowej wersji usługi Redis typu open source. Jeśli potrzebujesz określonej wersji usługi Redis dla aplikacji, zalecamy jawne wybranie wersji usługi Redis podczas tworzenia pamięci podręcznej.

Korzystanie z szyfrowania TLS

Azure Cache for Redis domyślnie wymaga zaszyfrowanej komunikacji TLS. Obecnie obsługiwane są wersje TLS 1.0, 1.1 i 1.2. Jednak protokół TLS 1.0 i 1.1 znajdują się na ścieżce do wycofania całej branży, dlatego należy użyć protokołu TLS 1.2, jeśli jest to możliwe.

Jeśli biblioteka klienta lub narzędzie nie obsługuje protokołu TLS, włączenie niezaszyfrowanych połączeń jest możliwe za pośrednictwem interfejsów APIAzure Portal lub zarządzania. W przypadkach, gdy zaszyfrowane połączenia nie są możliwe, zalecamy umieszczenie pamięci podręcznej i aplikacji klienckiej w sieci wirtualnej. Aby uzyskać więcej informacji na temat portów używanych w scenariuszu pamięci podręcznej sieci wirtualnej, zobacz tę tabelę.

Zmiana certyfikatu TLS platformy Azure

Microsoft aktualizuje usługi platformy Azure w celu używania certyfikatów serwera TLS z innego zestawu urzędów certyfikacji. Ta zmiana jest wdrażana w fazach od 13 sierpnia 2020 r. do 26 października 2020 r. (szacowane). Platforma Azure wprowadza tę zmianę, ponieważ bieżące certyfikaty urzędu certyfikacji nie są jednym z wymagań punktu odniesienia urzędu certyfikacji/przeglądarki. Problem został zgłoszony 1 lipca 2020 r. i dotyczy wielu popularnych dostawców infrastruktury kluczy publicznych (PKI) na całym świecie. Większość certyfikatów TLS używanych obecnie przez usługi platformy Azure pochodzi z głównej infrastruktury kluczy publicznych Baltimore CyberTrust . Usługa Azure Cache for Redis będzie nadal w łańcuchu do Baltimore CyberTrust Root. Certyfikaty serwera TLS zostaną jednak wystawione przez nowe pośrednie urzędy certyfikacji (ICA) począwszy od 12 października 2020 r.

Uwaga

Ta zmiana jest ograniczona do usług w publicznych regionach świadczenia usługi Azure. Wyklucza suwerenne (np. Chiny) lub chmury rządowe.

Czy ta zmiana wpływa na mnie?

Oczekujemy, że większość Azure Cache for Redis klientów nie ma wpływu na zmianę. Może to mieć wpływ na aplikację, jeśli jawnie określa listę akceptowalnych certyfikatów, praktyką znaną jako "przypinanie certyfikatów". Jeśli jest przypięty do certyfikatu pośredniego lub liścia zamiast Baltimore CyberTrust Root, należy podjąć natychmiastowe działania w celu zmiany konfiguracji certyfikatu.

Poniższa tabela zawiera informacje o wdrażanych certyfikatach. W zależności od certyfikatu używanego przez aplikację może być konieczne zaktualizowanie go, aby zapobiec utracie łączności z wystąpieniem Azure Cache for Redis.

Typ urzędu certyfikacji Current Post Rolling (12 października 2020 r.) Akcja
Główny Odcisk palca: d4de20d05e66fc53fe1a50882c78db2852cae474

Wygaśnięcie: poniedziałek, 12 maja 2025, 16:59:00

Nazwa podmiotu:
CN = Baltimore CyberTrust Root
Jednostka organizacyjna = CyberTrust
O = Baltimore
C = IE		 Nie zmieniaj Brak
Półproduktów Odciski palca:
CN = Microsoft IT TLS CA 1
Odcisk palca: 417e225037fbfaa4f95761d5ae729e1ae7e3a42

CN = Microsoft IT TLS CA 2
Odcisk palca: 54d9d20239080c32316ed9ff980a4898f4adf2d

CN = Microsoft IT TLS CA 4
Odcisk palca: 8a38755d09996823fe8fa3116a277ce446eac4e99

CN = Microsoft IT TLS CA 5
Odcisk palca: Ad898ac73df333eb60ac1f5fc6c4b2219ddb79b7

Wygaśnięcie: piątek, 20 maja 2024 5:52:38

Nazwa podmiotu:
Jednostka organizacyjna = Microsoft IT
O = Microsoft Corporation
L = Redmond
S = Waszyngton
C = STANY ZJEDNOCZONE
 Odciski palca:
CN = Microsoft RSA TLS CA 01
Odcisk palca: 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a

CN = Microsoft RSA TLS CA 02
Odcisk palca: b0c2d2d13cd56cdaa6ab6e2c0440be4a429c75

Wygaśnięcie: wtorek, 8 października 2024 12:00:00;

Nazwa podmiotu:
O = Microsoft Corporation
C = STANY ZJEDNOCZONE
 Wymagane

Jakie akcje należy wykonać?

Jeśli aplikacja używa magazynu certyfikatów systemu operacyjnego lub przypią do katalogu głównego Baltimore między innymi, nie jest wymagana żadna akcja.

Jeśli aplikacja przypią dowolny pośredni lub liściowy certyfikat TLS, zalecamy przypięcie następujących katalogów głównych:

Certyfikat Odcisk palca
Główny urząd certyfikacji Baltimore d4de20d05e66fc53fe1a50882c78db2852cae474
Microsoft głównego urzędu certyfikacji RSA 2017 73a5e64a3bff8316ff0edccc618a906e4eae4d74
Globalny katalog główny firmy Digicert G2 df3c24f9bfd666761b268073fe06d1cc8d4f82a4

Porada

Oczekuje się, że zarówno certyfikaty pośrednie, jak i liści będą często zmieniane. Zalecamy, aby nie przyjmować zależności od nich. Zamiast tego przypnij aplikację do certyfikatu głównego, ponieważ jest ona mniejsza.

Aby nadal przypiąć certyfikaty pośrednie, dodaj następujące elementy do przypiętej listy certyfikatów pośrednich, która zawiera jeszcze kilka innych, aby zminimalizować przyszłe zmiany:

Nazwa pospolita urzędu certyfikacji Odcisk palca
Microsoft RSA TLS CA 01 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a
Microsoft RSA TLS CA 02 b0c2d2d13cdd56cda6ab6e2c04440be4a429c75
Microsoft urząd wystawiania protokołu TLS na platformie Azure 01 2f2877c5d778c31e0f29c7e371df5471bd673173
Microsoft urzędu wystawiania protokołu TLS na platformie Azure 02 e7eea674ca718e3befd90858e09f8372ad0ae2aa
Microsoft urząd wystawiania protokołu TLS na platformie Azure 05 6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5
Microsoft urząd wystawiania protokołu TLS na platformie Azure 06 30e01761ab97e59a06b41ef20af6f2de7ef4f7b0

Jeśli aplikacja weryfikuje certyfikat w kodzie, należy zmodyfikować go, aby rozpoznawać właściwości --- na przykład Wystawcy, Odcisk palca --- nowo przypiętych certyfikatów. Ta dodatkowa weryfikacja powinna obejmować wszystkie przypięte certyfikaty, aby być bardziej weryfikowane w przyszłości.

Wskazówki dotyczące biblioteki klienta

Aby uzyskać więcej informacji, zobacz Biblioteki klienta.

Następne kroki