Udostępnij za pośrednictwem

Opracowywanie zawartości

  • Artykuł

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

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

Rozważ więcej kluczy i mniejszych wartości

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

Duży rozmiar żądania lub odpowiedzi

Duże żądanie lub odpowiedź może spowodować przekroczenie 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 potokowanie żądań, 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" przekracza limit czasu, mimo że 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 skrócić 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 nie być wystarczająca.
  • Zwiększ liczbę obiektów połączenia używanych przez aplikację.
    • Użyj podejścia okrężnego, aby wysyłać żądania do różnych obiektów 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 usługi Redis z kluczami).

Korzystanie z potokowania

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

Unikanie 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

W przypadku systemów produkcyjnych należy używać warstw Standardowa, Premium, Enterprise lub Enterprise Flash. Nie używaj warstwy Podstawowa w środowisku produkcyjnym. Warstwa Podstawowa to system z jednym węzłem 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ą rdzeń procesora CPU
  • użyj małej ilości pamięci
  • są podatne na hałaśliwe problemy z sąsiadami

Zalecamy testowanie wydajnościowe, 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, zwłaszcza 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 jest publicznym adresem 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 i 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. Usługa 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

Usługa Azure Cache for Redis domyślnie wymaga szyfrowanej komunikacji TLS. Obecnie obsługiwane są wersje TLS 1.0, 1.1 i 1.2. Jednak protokoły 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 witryny Azure Portal lub interfejsów API zarządzania. W przypadkach, gdy połączenia szyfrowane 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

Firma 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 dla urzędu certyfikacji/forum 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 nadal jest w łańcuchu do Baltimore CyberTrust Root. Certyfikaty serwera TLS zostaną jednak wydane 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 ma wpływ na mnie?

Większość klientów usługi Azure Cache for Redis nie ma wpływu na zmianę. Może to mieć wpływ na aplikację, jeśli jawnie określa listę akceptowalnych certyfikatów, czyli 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.

Usługa Azure Cache for Redis nie obsługuje zszywania OCSP.

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 usługi Azure Cache for Redis.

Typ urzędu certyfikacji Bieżąca Post Rolling (12 października 2020 r.) Akcja
Element 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 r. 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: 703d7a8f0ebf55aaaa59f98eaf4a206004eb2516a

CN = Microsoft RSA TLS CA 02
Odcisk palca: b0c2d2d13cdd56cda6ab6e2c04440be4a429c75

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

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

Jakie akcje należy wykonać?

Jeśli aplikacja używa magazynu certyfikatów systemu operacyjnego lub przypią katalog główny Baltimore, nie jest wymagana żadna akcja.

Jeśli aplikacja przypina 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
Główny urząd certyfikacji MICROSOFT RSA 2017 73a5e64a3bff8316ff0edccc618a906e4eee4d74
Globalny katalog główny G2 firmy Digicert df3c24f9bfd666761b268073fe06d1cc8d4f82a4

Napiwek

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

Aby kontynuować przypinanie certyfikatów pośrednich, dodaj następujące elementy do przypiętej listy certyfikatów pośrednich, która zawiera jeszcze kilka, 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 Azure TLS wystawiający urząd certyfikacji 01 2f2877c5d778c31e0f29c7e371df5471bd673173
Microsoft Azure TLS wystawiający urząd certyfikacji 02 e7eea674ca718e3befd90858e09f8372ad0ae2aa
Microsoft Azure TLS wystawiający urząd certyfikacji 05 6c3af02e7f269a73afd0eff2a88a4a1f04ed1e5
Microsoft Azure TLS wystawiający urząd certyfikacji 06 30e01761ab97e59a06b41ef20af6f2de7ef4f7b0

Jeśli aplikacja weryfikuje certyfikat w kodzie, należy zmodyfikować go, aby rozpoznać 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ły bardziej odporne na przyszłość.

Wskazówki dotyczące biblioteki klienta

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

Następne kroki