Vývoj

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.
  • Upřednostňovaným řešením je rozdělit data do souvisejících menších hodnot.
  • Podívejte se na příspěvek Co je ideální rozsah velikostí hodnoty pro Redis? Je 100 kB příliš velký? podrobnosti o tom, proč se doporučují menší hodnoty.
• 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ě:

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).

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.

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:

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í:

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

• Testování výkonu
• Převzetí služeb při selhání a opravy služby Azure Cache for Redis