Utveckling

  • Artikel

Anslut ionsresiliens och serverbelastning

När du utvecklar klientprogram bör du överväga relevanta metodtips för anslutningsresiliens och hantering av serverbelastning.

Överväg fler nycklar och mindre värden

Azure Cache for Redis fungerar bäst med mindre värden. Om du vill sprida data över flera nycklar kan du överväga att dela upp större datasegment i mindre segment. Mer information om idealvärdesstorlek finns i den här artikeln.

Stor storlek på begäran eller svar

En stor begäran/ett stort svar kan orsaka timeouter. Anta till exempel att ditt timeout-värde som konfigurerats på klienten är 1 sekund. Programmet begär två nycklar (till exempel "A" och "B") samtidigt (med samma fysiska nätverksanslutning). De flesta klienter stöder pipelining av begäranden, där både begäranden "A" och "B" skickas en efter en utan att vänta på deras svar. Servern skickar tillbaka svaren i samma ordning. Om svaret "A" är stort kan det äta upp det mesta av tidsgränsen för senare begäranden.

I följande exempel skickas begäran "A" och "B" snabbt till servern. Servern börjar skicka svar "A" och "B" snabbt. På grund av dataöverföringstider måste svaret "B" vänta bakom svar "A" tidsgränsen även om servern svarade snabbt.

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

Den här begäran/det här svaret är svår att mäta. Du kan instrumentera klientkoden för att spåra stora begäranden och svar.

Lösningar för stora svarsstorlekar varierar, men omfattar:

  • Optimera programmet för ett stort antal små värden i stället för några få stora värden.
  • Öka storleken på den virtuella datorn (VM) för att få högre bandbreddsfunktioner
    • Mer bandbredd på den virtuella klient- eller serverdatorn kan minska dataöverföringstiderna för större svar.
    • Jämför din aktuella nätverksanvändning på båda datorerna med gränserna för din aktuella VM-storlek. Mer bandbredd på bara servern eller bara på klienten kanske inte räcker.
  • Öka antalet anslutningsobjekt som programmet använder.
    • Använd en resursallokeringsmetod för att göra begäranden över olika anslutningsobjekt.

Nyckeldistribution

Om du planerar att använda Redis-klustring läser du först Metodtips för Redis-klustring med nycklar.

Använda pipelining

Försök att välja en Redis-klient som stöder Redis-pipelining. Pipelining hjälper till att effektivt använda nätverket och få bästa möjliga dataflöde.

Undvik dyra åtgärder

Vissa Redis-åtgärder, till exempel KOMMANDOT NYCKLAR , är dyra och bör undvikas. Några saker att tänka på kring tidskrävande kommandon finns i tidskrävande kommandon.

Välj en lämplig nivå

Använd Standard-, Premium-, Enterprise- eller Enterprise Flash-nivåer för produktionssystem. Använd inte basic-nivån i produktion. Basic-nivån är ett system med en enda nod utan datareplikering och inget serviceavtal. Använd också minst ett C1-cacheminne. C0-cacheminnen är bara avsedda för enkla utvecklings-/testscenarier eftersom:

  • de delar en CPU-kärna
  • använd lite minne
  • är utsatta för problem med bullriga grannar

Vi rekommenderar prestandatestning för att välja rätt nivå och verifiera anslutningsinställningar. Mer information finns i Prestandatestning.

Klient i samma region som cachelagringen

Leta upp din cacheinstans och ditt program i samma region. Om du ansluter till en cache i en annan region kan latensen öka och tillförlitligheten minska avsevärt.

Även om du kan ansluta utanför Azure rekommenderas det inte, särskilt inte när du använder Redis som cacheminne. Om du använder Redis-servern som ett nyckel-/värdearkiv kanske svarstiden inte är det primära problemet.

Förlita dig på värdnamn, inte offentlig IP-adress

Den offentliga IP-adress som tilldelats cacheminnet kan ändras till följd av en skalningsåtgärd eller serverdelsförbättring. Vi rekommenderar att du förlitar dig på värdnamnet i stället för en explicit offentlig IP-adress. Här är de rekommenderade formulären för de olika nivåerna:

Nivå Formulär
Basic, Standard, Premium <cachename>.redis.cache.windows.net
Enterprise, Enterprise Flash <DNS name>.<Azure region>.redisenterprise.cache.azure.net.

Välj en lämplig Redis-version

Standardversionen av Redis som används när du skapar en cache kan ändras över tid. Azure Cache for Redis kan anta en ny version när en ny version av Redis med öppen källkod släpps. Om du behöver en specifik version av Redis för ditt program rekommenderar vi att du uttryckligen väljer Redis-versionen när du skapar cacheminnet.

Specifik vägledning för Enterprise-nivåerna

Eftersom Enterprise- och Enterprise Flash-nivåerna bygger på Redis Enterprise i stället för Redis med öppen källkod finns det vissa skillnader i metodtips för utveckling. Mer information finns i Metodtips för Enterprise- och Enterprise Flash-nivåerna.

Använda TLS-kryptering

Azure Cache for Redis kräver TLS-krypterad kommunikation som standard. TLS-versionerna 1.0, 1.1 och 1.2 stöds för närvarande. TLS 1.0 och 1.1 är dock på väg att fasa ut hela branschen, så använd TLS 1.2 om det är möjligt.

Om klientbiblioteket eller verktyget inte stöder TLS är det möjligt att aktivera okrypterade anslutningar via Azure-portalen eller hanterings-API:er. I de fall där krypterade anslutningar inte är möjliga rekommenderar vi att du placerar ditt cache- och klientprogram i ett virtuellt nätverk. Mer information om vilka portar som används i cachescenariot för virtuella nätverk finns i den här tabellen.

Ändring av Azure TLS-certifikat

Microsoft uppdaterar Azure-tjänster för att använda TLS-servercertifikat från en annan uppsättning certifikatutfärdare (CA). Den här ändringen lanseras i faser från 13 augusti 2020 till 26 oktober 2020 (uppskattad). Azure gör den här ändringen eftersom de aktuella CA-certifikaten inte är något av kraven för CA/Browser-forumets baslinje. Problemet rapporterades den 1 juli 2020 och gäller för flera populära PKI-leverantörer (Public Key Infrastructure) över hela världen. De flesta TLS-certifikat som används av Azure-tjänster i dag kommer från Baltimore CyberTrust Root PKI. Azure Cache for Redis-tjänsten fortsätter att vara länkad till Baltimore CyberTrust Root. Dess TLS-servercertifikat kommer dock att utfärdas av nya mellanliggande certifikatutfärdare (ICAs) från och med den 12 oktober 2020.

Kommentar

Den här ändringen är begränsad till tjänster i offentliga Azure-regioner. Det exkluderar suveräna (t.ex. Kina) eller regeringsmoln.

Påverkar den här ändringen mig?

De flesta Azure Cache for Redis-kunder påverkas inte av ändringen. Ditt program kan påverkas om det uttryckligen anger en lista över godtagbara certifikat, en metod som kallas för att fästa certifikat. Om det fästs på ett mellanliggande certifikat eller lövcertifikat i stället för Baltimore CyberTrust Root bör du vidta omedelbara åtgärder för att ändra certifikatkonfigurationen.

Azure Cache for Redis stöder inte OCSP-häftning.

Följande tabell innehåller information om de certifikat som håller på att distribueras. Beroende på vilket certifikat programmet använder kan du behöva uppdatera det för att förhindra att anslutningen till Din Azure Cache for Redis-instans går förlorad.

CA-typ Befintliga Post Rolling (12 okt 2020) Åtgärd
Rot Tumavtryck: d4de20d05e66fc53fe1a5082c78db2852cae474

Förfallodatum: måndag 12 maj 2025, 16:59:00

Ämnesnamn:
CN = Baltimore CyberTrust Root
OU = CyberTrust
O = Baltimore
C = IE		 Ändras inte Ingen
Intermediärer Tumavtryck:
CN = Microsoft IT TLS CA 1
Tumavtryck: 417e225037fbfaa4f95761d5ae729e1aea7e3a42

CN = Microsoft IT TLS CA 2
Tumavtryck: 54d9d20239080c32316ed9ff980a4898f4adf2d

CN = Microsoft IT TLS CA 4
Tumavtryck: 8a38755d0996823fe8fa3116a277ce446eac4e99

CN = Microsoft IT TLS CA 5
Tumavtryck: Ad898ac73df333eb60ac1f5fc6c4b2219ddb79b7

Förfallodatum: fredag 20 maj 2024 05:52:38

Ämnesnamn:
OU = Microsoft IT
O = Microsoft Corporation
L = Redmond
S = Washington
C = USA
 Tumavtryck:
CN = Microsoft RSA TLS CA 01
Tumavtryck: 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a

CN = Microsoft RSA TLS CA 02
Tumavtryck: b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75

Förfallodatum: Tisdag 8 oktober 2024 12:00:00;

Ämnesnamn:
O = Microsoft Corporation
C = USA
 Obligatoriskt

Vad behöver jag göra?

Om ditt program använder certifikatarkivet för operativsystemet eller fäster Baltimore-roten bland annat behövs ingen åtgärd.

Om ditt program fäster något mellanliggande eller löv-TLS-certifikat rekommenderar vi att du fäster följande rötter:

Certifikat Tumavtryck
Baltimore Root CA d4de20d05e66fc53fe1a50882c78db2852cae474
Microsoft RSA Root Certificate Authority 2017 73a5e64a3bff8316ff0edccc618a906e4eae4d74
Digicert Global Root G2 df3c24f9bfd666761b268073fe06d1cc8d4f82a4

Dricks

Både mellanliggande certifikat och lövcertifikat förväntas ändras ofta. Vi rekommenderar att du inte är beroende av dem. Fäst i stället programmet på ett rotcertifikat eftersom det rullar mindre ofta.

Om du vill fortsätta att fästa mellanliggande certifikat lägger du till följande i listan över fästa mellanliggande certifikat, som innehåller några fler för att minimera framtida ändringar:

Certifikatmottagarens gemensamma namn Tumavtryck
Microsoft RSA TLS CA 01 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a
Microsoft RSA TLS CA 02 b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75
Microsoft Azure TLS Utfärdar CA 01 2f2877c5d778c31e0f29c7e371df5471bd673173
Microsoft Azure TLS Utfärdar CA 02 e7eea674ca718e3befd90858e09f8372ad0ae2aa
Microsoft Azure TLS Utfärdar CA 05 6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5
Microsoft Azure TLS utfärdar CA 06 30e01761ab97e59a06b41ef20af6f2de7ef4f7b0

Om ditt program validerar certifikatet i kod måste du ändra det för att identifiera egenskaperna --- till exempel Utfärdare, Tumavtryck --- för de nyligen fästa certifikaten. Den här extra verifieringen bör omfatta alla fästa certifikat för att vara mer framtidssäkrade.

Klientbiblioteksspecifik vägledning

Mer information finns i Klientbibliotek.

Nästa steg