Delen via

Ontwikkeling

  • Artikel

Verbinding maken ietolerantie en serverbelasting

Houd bij het ontwikkelen van clienttoepassingen rekening met de relevante aanbevolen procedures voor verbindingstolerantie en het beheren van de serverbelasting.

Overweeg meer sleutels en kleinere waarden

Azure Cache voor Redis werkt het beste met kleinere waarden. Als u de gegevens over meerdere sleutels wilt verdelen, kunt u grotere segmenten van gegevens delen in kleinere segmenten. Zie dit artikel voor meer informatie over de ideale waardegrootte.

Grote aanvraag- of antwoordgrootte

Een grote aanvraag/reactie kan time-outs veroorzaken. Stel dat uw time-outwaarde die op uw client is geconfigureerd, 1 seconde is. Uw toepassing vraagt tegelijkertijd om twee sleutels (bijvoorbeeld A en B) (met dezelfde fysieke netwerkverbinding). De meeste clients ondersteunen pipelining van aanvragen, waarbij beide aanvragen 'A' en 'B' na elkaar worden verzonden zonder te wachten op hun antwoorden. De server verzendt de antwoorden terug in dezelfde volgorde. Als antwoord A groot is, kan het de meeste time-out voor latere aanvragen opeten.

In het volgende voorbeeld worden aanvraag A en B snel naar de server verzonden. De server begint snel antwoorden 'A' en 'B' te verzenden. Vanwege gegevensoverdrachtstijden moet reactie B wachten op een time-out van antwoord A, ook al heeft de server snel gereageerd.

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

Deze aanvraag/reactie is moeilijk te meten. U kunt uw clientcode instrumenteren om grote aanvragen en antwoorden bij te houden.

Oplossingen voor grote responsgrootten zijn gevarieerd, maar zijn onder andere:

  • Optimaliseer uw toepassing voor een groot aantal kleine waarden in plaats van een paar grote waarden.
  • Vergroot de grootte van uw virtuele machine (VM) om meer bandbreedtemogelijkheden te krijgen
    • Meer bandbreedte op uw client- of server-VM kan de gegevensoverdrachtstijden voor grotere antwoorden verminderen.
    • Vergelijk uw huidige netwerkgebruik op beide computers met de limieten van uw huidige VM-grootte. Meer bandbreedte op alleen de server of alleen op de client is mogelijk niet voldoende.
  • Verhoog het aantal verbindingsobjecten dat door uw toepassing wordt gebruikt.
    • Gebruik een round robin-benadering om aanvragen uit te voeren via verschillende verbindingsobjecten.

Sleuteldistributie

Als u van plan bent om Redis-clustering te gebruiken, leest u eerst best practices voor Redis-clustering met sleutels.

Pipelining gebruiken

Probeer een Redis-client te kiezen die ondersteuning biedt voor Redis-pipelining. Pipelining helpt efficiënt gebruik te maken van het netwerk en de best mogelijke doorvoer te krijgen.

Vermijd dure bewerkingen

Sommige Redis-bewerkingen, zoals de opdracht SLEUTELS , zijn duur en moeten worden vermeden. Zie langlopende opdrachten voor enkele overwegingen met betrekking tot langlopende opdrachten.

Een geschikte laag kiezen

Gebruik standard-, Premium-, Enterprise- of Enterprise Flash-lagen voor productiesystemen. Gebruik de Basic-laag niet in productie. De Basic-laag is een systeem met één knooppunt zonder gegevensreplicatie en geen SLA. Gebruik minimaal een C1-cache. C0-caches zijn alleen bedoeld voor eenvoudige ontwikkel-/testscenario's, omdat:

  • ze delen een CPU-kern
  • weinig geheugen gebruiken
  • zijn gevoelig voor problemen met lawaaierige buren

We raden u aan prestatietests uit te voeren om de juiste laag te kiezen en verbindingsinstellingen te valideren. Zie Prestatietests voor meer informatie.

Client in dezelfde regio als cache

Zoek uw cache-exemplaar en uw toepassing in dezelfde regio. Als er verbinding wordt gemaakt met een cache in een andere regio, kan dit leiden tot een aanzienlijk hogere latentie en kan dit ten koste gaan van de betrouwbaarheid.

Hoewel u buiten Azure verbinding kunt maken, wordt dit niet aanbevolen, met name wanneer u Redis als cache gebruikt. Als u Redis-server gebruikt als alleen een sleutel-/waardearchief, is latentie mogelijk niet het belangrijkste probleem.

Vertrouwen op hostnaam niet openbaar IP-adres

Het openbare IP-adres dat aan uw cache is toegewezen, kan worden gewijzigd als gevolg van een schaalbewerking of verbetering van de back-end. We raden u aan om te vertrouwen op de hostnaam in plaats van een expliciet openbaar IP-adres. Hier volgen de aanbevolen formulieren voor de verschillende lagen:

Laag Formulier
Basic, Standard en Premium <cachename>.redis.cache.windows.net
Enterprise, Enterprise Flash <DNS name>.<Azure region>.redisenterprise.cache.azure.net.

Een geschikte Redis-versie kiezen

De standaardversie van Redis die wordt gebruikt bij het maken van een cache, kan na verloop van tijd worden gewijzigd. Azure Cache voor Redis kan een nieuwe versie gebruiken wanneer er een nieuwe versie van opensource Redis wordt uitgebracht. Als u een specifieke versie van Redis voor uw toepassing nodig hebt, raden we u aan om de Redis-versie expliciet te kiezen wanneer u de cache maakt.

Specifieke richtlijnen voor de Enterprise-lagen

Omdat de Enterprise- en Enterprise Flash-lagen zijn gebouwd op Redis Enterprise in plaats van opensource Redis, zijn er enkele verschillen in aanbevolen procedures voor ontwikkeling. Zie Aanbevolen procedures voor de Enterprise- en Enterprise Flash-lagen voor meer informatie.

TLS-versleuteling gebruiken

Azure Cache voor Redis vereist standaard versleutelde TLS-communicatie. TLS-versies 1.0, 1.1 en 1.2 worden momenteel ondersteund. TLS 1.0 en 1.1 bevinden zich echter op een pad naar afschaffing in de hele branche, dus gebruik TLS 1.2 indien mogelijk.

Als uw clientbibliotheek of hulpprogramma geen ondersteuning biedt voor TLS, is het inschakelen van niet-versleutelde verbindingen mogelijk via de Azure-portal of beheer-API's. In gevallen waarin versleutelde verbindingen niet mogelijk zijn, raden we u aan uw cache en clienttoepassing in een virtueel netwerk te plaatsen. Zie deze tabel voor meer informatie over welke poorten worden gebruikt in het cachescenario van het virtuele netwerk.

Wijziging van Azure TLS-certificaat

Microsoft werkt Azure-services bij voor het gebruik van TLS-servercertificaten van een andere set certificeringsinstanties (CA's). Deze wijziging wordt in fasen geïmplementeerd van 13 augustus 2020 tot 26 oktober 2020 (geschat). Azure brengt deze wijziging aan omdat de huidige CA-certificaten niet voldoen aan de basislijnvereisten voor ca/browserforums. Het probleem is gemeld op 1 juli 2020 en is van toepassing op meerdere populaire PKI-providers (Public Key Infrastructure) wereldwijd. De meeste TLS-certificaten die tegenwoordig door Azure-services worden gebruikt, zijn afkomstig van de Baltimore CyberTrust Root PKI. De Azure Cache voor Redis service blijft gekoppeld aan de Baltimore CyberTrust Root. De TLS-servercertificaten worden echter uitgegeven door nieuwe tussenliggende certificeringsinstanties (ICA's) vanaf 12 oktober 2020.

Notitie

Deze wijziging is beperkt tot services in openbare Azure-regio's. Het sluit onafhankelijke clouds (bijvoorbeeld China) of overheidsclouds uit.

Heeft deze wijziging gevolgen voor mij?

De meeste Azure Cache voor Redis klanten worden niet beïnvloed door de wijziging. Uw toepassing kan worden beïnvloed als er expliciet een lijst met acceptabele certificaten wordt opgegeven, een praktijk die bekend staat als certificaatpinning. Als het is vastgemaakt aan een tussenliggend of bladcertificaat in plaats van de Baltimore CyberTrust Root, moet u onmiddellijk acties ondernemen om de certificaatconfiguratie te wijzigen.

Azure Cache voor Redis biedt geen ondersteuning OCSP nieten.

De volgende tabel bevat informatie over de certificaten die worden samengerold. Afhankelijk van welk certificaat uw toepassing gebruikt, moet u het mogelijk bijwerken om verlies van connectiviteit met uw Azure Cache voor Redis exemplaar te voorkomen.

CA-type Huidig Post Rolling (12 oktober 2020) Actie
Hoofdniveau Vingerafdruk: d4de20d05e66fc53fe1a50882c78db2852cae474

Vervaldatum: maandag 12 mei 2025, 14:59:00 uur

Onderwerpnaam:
CN = Baltimore CyberTrust Root
OU = CyberTrust
O = Baltimore
C = IE		 Niet wijzigen Geen
Tussenproducten Vingerafdruk:
CN = Microsoft IT TLS CA 1
Vingerafdruk: 417e225037fbfaa4f95761d5ae729e1aea7e3a42

CN = Microsoft IT TLS CA 2
Vingerafdruk: 54d9d20239080c32316ed9ff980a4898f4adf2d

CN = Microsoft IT TLS CA 4
Vingerafdruk: 8a38755d0996823fe8fa3116a277ce446eac4e99

CN = Microsoft IT TLS CA 5
Vingerafdruk: Ad898ac73df333eb60ac1f5fc6c4b2219ddb79b7

Vervaldatum: vrijdag 20 mei 2024 5:52:38 uur

Onderwerpnaam:
OE = Microsoft IT
O = Microsoft Corporation
L = Redmond
S = Washington
C = US
 Vingerafdruk:
CN = Microsoft RSA TLS CA 01
Vingerafdruk: 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a

CN = Microsoft RSA TLS CA 02
Vingerafdruk: b0c2d2d13cd56cdaa6ab6e2c04440be4a429c75

Vervaldatum: dinsdag 8 oktober 2024 12:00:00 uur;

Onderwerpnaam:
O = Microsoft Corporation
C = US
 Vereist

Welke acties moet ik ondernemen?

Als uw toepassing het certificaatarchief van het besturingssysteem gebruikt of de Baltimore-basis vaststelt, is er geen actie nodig.

Als uw toepassing een tussenliggend of blad-TLS-certificaat vastzet, raden we u aan de volgende hoofdmappen vast te maken:

Certificaat Vingerafdruk
Baltimore Root CA d4de20d05e66fc53fe1a50882c78db2852cae474
Microsoft RSA Root Certificate Authority 2017 73a5e64a3bff8316ff0edccc618a906e4eae4d74
Digicert Global Root G2 df3c24f9bfd666761b268073fe06d1cc8d4f82a4

Tip

Zowel de tussenliggende als de leaf-certificaten worden naar verwachting regelmatig gewijzigd. U wordt aangeraden geen afhankelijkheid ervan te nemen. Maak uw toepassing in plaats daarvan vast aan een basiscertificaat, omdat deze minder vaak wordt meegedraaid.

Als u tussenliggende certificaten wilt blijven vastmaken, voegt u het volgende toe aan de lijst met vastgemaakte tussenliggende certificaten, waaronder nog enkele om toekomstige wijzigingen te minimaliseren:

Algemene naam van de CA Vingerafdruk
Microsoft RSA TLS CA 01 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a
Microsoft RSA TLS CA 02 b0c2d2d13cd56cdaa6ab6e2c04440be4a429c75
Microsoft Azure TLS-verlenende CA 01 2f2877c5d778c31e0f29c7e371df5471bd673173
Microsoft Azure TLS-verlenende CA 02 e7eea674ca718e3befd90858e09f8372ad0ae2aa
Microsoft Azure TLS-verlenende CA 05 6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5
Microsoft Azure TLS-uitgifte-CA 06 30e01761ab97e59a06b41ef20af6f2de7ef4f7b0

Als uw toepassing het certificaat in code valideert, moet u het wijzigen om de eigenschappen te herkennen --- bijvoorbeeld Verleners, Vingerafdruk --- van de zojuist vastgemaakte certificaten. Deze extra verificatie moet betrekking hebben op alle vastgemaakte certificaten om toekomstbestendiger te zijn.

Richtlijnen voor clientbibliotheek

Zie Clientbibliotheken voor meer informatie.

Volgende stappen