Vývoj

  • Článek

odolnost Připojení a zatížení serveru

Při vývoji klientských aplikací nezapomeňte zvážit relevantní osvědčené postupy pro odolnost připojení a správu zatížení serveru.

Zvažte více klíčů a menších hodnot.

Azure Cache for Redis funguje nejlépe s menšími hodnotami. Pokud chcete data rozdělit na více klíčů, zvažte rozdělení větších bloků dat na menší bloky dat. Další informace o ideální velikosti hodnoty najdete v tomto článku.

Velká velikost požadavku nebo odpovědi

Velké požadavky nebo odpovědi můžou způsobit vypršení časových limitů. Předpokládejme například, že hodnota časového limitu nakonfigurovaná v klientovi je 1 sekunda. Vaše aplikace vyžaduje dva klíče (například A a B) najednou (pomocí stejného fyzického síťového připojení). Většinaklientůchm Server odešle odpovědi zpět ve stejném pořadí. Pokud je odpověď "A" velká, může většinu časového limitu pro pozdější požadavky sníst.

V následujícím příkladu se požadavek "A" a "B" rychle odešlou na server. Server začne rychle odesílat odpovědi "A" a "B". Kvůli době přenosu dat musí odpověď B čekat za odpovědí A, i když server rychle odpověděl.

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

Tento požadavek nebo odpověď je obtížné měřit. Klientský kód můžete instrumentovat ke sledování velkých požadavků a odpovědí.

Rozlišení velkých velikostí odpovědí jsou různá, ale zahrnují:

  • Optimalizujte aplikaci pro velký počet malých hodnot, a ne několik velkých hodnot.
  • Zvětšením velikosti virtuálního počítače získáte větší možnosti šířky pásma.
    • Větší šířka pásma na virtuálním počítači klienta nebo serveru může zkrátit dobu přenosu dat pro větší odpovědi.
    • Porovnejte aktuální využití sítě na obou počítačích s omezeními aktuální velikosti virtuálního počítače. Větší šířka pásma jenom na serveru nebo pouze na klientovi nemusí být dostatečná.
  • Zvyšte počet objektů připojení, které vaše aplikace používá.
    • Pomocí kruhového dotazování můžete vytvářet požadavky na různé objekty připojení.

Distribuce klíčů

Pokud plánujete používat clustering Redis, přečtěte si nejprve osvědčené postupy clusteringu Redis s klíči.

Použití pipeliningu

Zkuste zvolit klienta Redis, který podporuje přesměrování kanálu Redis. Pipelining pomáhá efektivně využívat síť a získat nejlepší možnou propustnost.

Vyhněte se nákladným operacím

Některé operace Redis, jako je například příkaz KLÍČE , jsou nákladné a měly by se jim vyhnout. Některé důležité informace o dlouhotrvajících příkazech najdete v tématu Dlouhotrvající příkazy.

Zvolte odpovídající úroveň.

Pro produkční systémy používejte úrovně Standard, Premium, Enterprise nebo Enterprise Flash. Nepoužívejte úroveň Basic v produkčním prostředí. Úroveň Basic je systém s jedním uzlem bez replikace dat a bez smlouvy SLA. Jako mezipaměť použijte aspoň C1. Mezipaměti C0 jsou určeny pouze pro jednoduché scénáře vývoje/testování, protože:

  • sdílejí jádro procesoru.
  • použití malé paměti
  • jsou náchylné k problémům s hlučnou sousedou

Doporučujeme, abyste zvolili správnou úroveň a ověřili nastavení připojení. Další informace najdete v tématu Testování výkonu.

Klient ve stejné oblasti jako mezipaměť

Vyhledejte instanci mezipaměti a aplikaci ve stejné oblasti. Pokud byste se připojovali k mezipaměti v jiné oblasti, výrazně byste tím zvýšili latenci a snížili spolehlivost.

I když se můžete připojit z prostředí mimo Azure, nedoporučuje se, zejména pokud používáte Redis jako mezipaměť. Pokud používáte server Redis jako úložiště klíč/hodnota, latence nemusí být primárním problémem.

Spoléhat se na název hostitele, ne na veřejnou IP adresu

Veřejná IP adresa přiřazená k vaší mezipaměti se může změnit v důsledku zlepšení operace škálování nebo back-endu. Místo explicitní veřejné IP adresy doporučujeme spoléhat na název hostitele. Tady jsou doporučené formuláře pro různé úrovně:

Úroveň Formulář
Basic, Standard a Premium <cachename>.redis.cache.windows.net
Enterprise, Enterprise Flash <DNS name>.<Azure region>.redisenterprise.cache.azure.net.

Volba vhodné verze Redis

Výchozí verze Redis, která se používá při vytváření mezipaměti, se může v průběhu času měnit. Azure Cache for Redis může při vydání nové verze Open Source Redis přijmout novou verzi. Pokud potřebujete pro vaši aplikaci konkrétní verzi Redis, doporučujeme při vytváření mezipaměti explicitně zvolit verzi Redis.

Konkrétní pokyny pro úrovně Enterprise

Vzhledem k tomu, že úrovně Enterprise a Enterprise Flash jsou založené na Redis Enterprise místo opensourcového Redisu, existují některé rozdíly v osvědčených postupech vývoje. Další informace najdete v tématu Osvědčené postupy pro úrovně Enterprise a Enterprise Flash.

Použití šifrování TLS

Azure Cache for Redis ve výchozím nastavení vyžaduje šifrovanou komunikaci TLS. Aktuálně se podporují protokoly TLS verze 1.0, 1.1 a 1.2. Protokoly TLS 1.0 a 1.1 jsou však na cestě k vyřazení z celého oboru, takže pokud je to možné, použijte protokol TLS 1.2.

Pokud vaše klientská knihovna nebo nástroj nepodporuje protokol TLS, je možné povolit nešifrovaná připojení prostřednictvím webu Azure Portal nebo rozhraní API pro správu. V případech, kdy šifrovaná připojení nejsou možná, doporučujeme umístit mezipaměť a klientskou aplikaci do virtuální sítě. Další informace o tom, které porty se používají ve scénáři mezipaměti virtuální sítě, najdete v této tabulce.

Změna certifikátu Azure TLS

Microsoft aktualizuje služby Azure tak, aby používaly certifikáty serveru TLS z jiné sady certifikačních autorit (CA). Tato změna se zavádí ve fázích od 13. srpna 2020 do 26. října 2020 (odhadované). Azure tuto změnu provádí, protože aktuální certifikáty certifikační autority nemají jeden z požadavků na standardní hodnoty pro ca/Browser Forum. Problém byl nahlášen 1. července 2020 a vztahuje se na několik oblíbených poskytovatelů infrastruktury veřejných klíčů (PKI) po celém světě. Většina certifikátů TLS používaných službami Azure dnes pochází z pkI Baltimore CyberTrust Root . Služba Azure Cache for Redis je stále zřetězený s rootem Baltimore CyberTrust. Od 12. října 2020 budou certifikáty serveru TLS vydávat nové zprostředkující certifikační autority (ICA).

Poznámka:

Tato změna je omezená na služby ve veřejných oblastech Azure. Vyloučí suverénní cloudy (např. Čína) nebo cloudy státní správy.

Ovlivní mě tato změna?

Na většinu zákazníků Azure Cache for Redis tato změna nemá vliv. Aplikace může být ovlivněná, pokud explicitně určuje seznam přijatelných certifikátů, které se označují jako připnutí certifikátu. Pokud je místo kořenového certifikátu Baltimore CyberTrust Připnutá na zprostředkující nebo listový certifikát, měli byste provést okamžité kroky ke změně konfigurace certifikátu.

Azure Cache for Redis nepodporuje sešívání OCSP.

Následující tabulka obsahuje informace o certifikátech, které se zahrnou. V závislosti na tom, který certifikát vaše aplikace používá, ji možná budete muset aktualizovat, abyste zabránili ztrátě připojení k instanci Azure Cache for Redis.

Typ certifikační autority Aktuální Po válcování (12. října 2020) Akce
Root Kryptografický otisk: d4de20d05e66fc53fe1a50882c78db2852cae474

Vypršení platnosti: pondělí, 12. května 2025, 4:59:00

Název subjektu:
CN = Baltimore CyberTrust Root
OU = CyberTrust
O = Baltimore
C = IE		 Nemění se Nic
Meziprodukty Kryptografické otisky:
CN = Microsoft IT TLS CA 1
Kryptografický otisk: 417e225037fbfaa4f95761d5ae729e1ae7e3a42

CN = Microsoft IT TLS CA 2
Kryptografický otisk: 54d9d20239080c32316ed9ff980a48988f4adf2d

CN = Microsoft IT TLS CA 4
Kryptografický otisk: 8a38755d096823fe8fa3116a277ce446eac4e99

CN = Microsoft IT TLS CA 5
Kryptografický otisk: Ad898ac73df333eb60ac1f5fc6c4b2219ddb79b7

Vypršení platnosti: pátek, 20. května 2024 5:52:38

Název subjektu:
Organizační jednotky = Microsoft IT
O = Microsoft Corporation
L = Redmond
S = Washington
C = US
 Kryptografické otisky:
CN = Microsoft RSA TLS CA 01
Kryptografický otisk: 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a

CN = Microsoft RSA TLS CA 02
Kryptografický otisk: b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75

Konec platnosti: úterý, 8. října 2024 12:00:00;

Název subjektu:
O = Microsoft Corporation
C = US
 Požaduje se

Co všechno mám udělat?

Pokud vaše aplikace používá úložiště certifikátů operačního systému nebo mimo jiné připne kořenový adresář Baltimore, není potřeba žádná akce.

Pokud vaše aplikace připne některý zprostředkující nebo listový certifikát TLS, doporučujeme připnout následující kořeny:

Certifikát Kryptografický otisk
Kořenová certifikační autorita Baltimore d4de20d05e66fc53fe1a50882c78db2852cae474
Microsoft RSA Root Certificate Authority 2017 73a5e64a3bff8316ff0edccc618a906e4eae4d74
Digicert Global Root G2 df3c24f9bfd666761b268073fe06d1cc8d4f82a4

Tip

U zprostředkujících i listových certifikátů se očekává, že se často mění. Doporučujeme, abyste na nich nezávisli. Místo toho připněte aplikaci na kořenový certifikát, protože se méně často zahrne.

Pokud chcete dál připnout zprostředkující certifikáty, přidejte do seznamu připnutých zprostředkujících certifikátů následující:

Běžný název certifikační autority Kryptografický otisk
Microsoft RSA TLS CA 01 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a
Microsoft RSA TLS CA 02 b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75
Microsoft Azure TLS vydávající CA 01 2f2877c5d778c31e0f29c7e371df5471bd673173
Microsoft Azure TLS vydávající CA 02 e7eea674ca718e3befd90858e09f8372ad0ae2aa
Microsoft Azure TLS vydávající CA 05 6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5
Microsoft Azure TLS vydávající CA 06 30e01761ab97e59a06b41ef20af6f2de7ef4f7b0

Pokud vaše aplikace ověří certifikát v kódu, musíte ho upravit tak, aby rozpoznala vlastnosti, --- například vystavitele, kryptografický otisk --- nově připnutých certifikátů. Toto dodatečné ověření by mělo zahrnovat všechny připnuté certifikáty, aby byly více důkazem o budoucnosti.

Doprovodné materiály specifické pro klientskou knihovnu

Další informace naleznete v tématu Klientské knihovny.

Další kroky