Ontwikkeling met Azure Managed Redis

  • Van toepassing op: ✅ Azure Managed Redis

In dit artikel wordt beschreven hoe u code ontwikkelt voor Azure Managed Redis.

Verbindingstolerantie 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 Managed Redis werkt het beste met kleinere waarden. Als u de gegevens over meerdere sleutels wilt verdelen, kunt u grotere segmenten van gegevens verdelen in kleinere segmenten. Zie dit artikel voor meer informatie over de ideale waardegrootte.

Grote aanvraag- of antwoordgrootte

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

In het volgende voorbeeld worden de aanvragen A en B snel naar de server verzonden. De server begint antwoorden A te verzenden en B snel. Door de tijd die nodig is voor gegevensoverdracht moet reactie B wachten totdat reactie A een time-out krijgt, ook al reageerde de server snel.

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

Dit aanvraag- en antwoordpatroon is moeilijk te meten. U kunt uw clientcode instrumenteren om grote aanvragen en antwoorden bij te houden.

Oplossingen voor grote responsgrootten variëren, 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 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.

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 u moet ze vermijden. Zie voor enkele overwegingen met betrekking tot langlopende opdrachten, langlopende opdrachten.

Een geschikte laag kiezen

Azure Managed Redis biedt de lagen Geoptimaliseerd voor geheugen, Balans, Geoptimaliseerd voor rekenkracht en Flash. Zie Schalen voor meer informatie over het kiezen van een laag. Test de prestaties om de juiste laag te kiezen en verbindingsinstellingen te valideren. Zie Prestatietests voor meer informatie.

Een geschikte beschikbaarheidsmodus kiezen

Azure Managed Redis biedt de mogelijkheid om configuratie met hoge beschikbaarheid in of uit te schakelen. Wanneer u de modus voor hoge beschikbaarheid uitschakelt, worden de gegevens in uw AMR-exemplaar niet gerepliceerd en is uw Redis-exemplaar niet beschikbaar tijdens onderhoud. Alle gegevens in het AMR-exemplaar gaan verloren tijdens gepland of ongepland onderhoud. Schakel hoge beschikbaarheid alleen uit voor uw ontwikkel- of testworkloads. De prestaties van Redis-exemplaren met hoge beschikbaarheid kunnen ook lager zijn vanwege het ontbreken van gegevensreplicatie, wat cruciaal is voor het verdelen van de belasting tussen primaire en replicagegevensshard.

Client in dezelfde regio als Redis-exemplaar

Zoek uw Redis-exemplaar en uw toepassing in dezelfde regio. Als u verbinding maakt met een Redis in een andere regio, kan de latentie aanzienlijk toenemen en de betrouwbaarheid verminderen.

Hoewel u buiten Azure verbinding kunt maken, wordt dit niet aanbevolen, met name wanneer u Redis gebruikt om de prestaties van uw toepassing of database te versnellen. 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 IP-adres dat aan uw cache is toegewezen, kan worden gewijzigd als gevolg van een schaalbewerking of verbetering van de back-end. Vertrouw op de hostnaam in plaats van een expliciet openbaar of privé IP-adres. Het geconfigureerde statische IP-adres voor een cache in een virtueel netwerk is geen onveranderbare garantie en kan tijdens bepaalde bewerkingen veranderen, hoewel wijzigingen zeldzaam zijn.

Hostnamen in Azure Managed Redis zien er als volgt uit: <DNS name>.<Azure region>.redis.azure.net

TLS-versleuteling gebruiken

Azure Managed Redis vereist standaard versleutelde TLS-communicatie. TLS-versies 1.2 en 1.3 worden momenteel ondersteund. Als uw clientbibliotheek of hulpprogramma tls niet ondersteunt, is het inschakelen van niet-versleutelde verbindingen mogelijk.

Geheugengebruik, metrische gegevens over CPU-gebruik, clientverbindingen en netwerkbandbreedte bewaken

Wanneer u Azure beheerd Redis-exemplaar in productie gebruikt, stelt u waarschuwingen in voor metrische gegevens Used Memory Percentage, CPU en Connected Clients. Als deze metrische gegevens consistent hoger zijn dan 75%, kunt u overwegen om uw exemplaar te schalen naar een groter geheugen of een betere doorvoerlaag. Zie wanneer u de schaal wilt aanpassen voor meer informatie. Zie geheugenbeheer voor meer informatie over hoe geheugen wordt gerapporteerd en hoe u capaciteit plant.

Overweeg om gegevenspersistentie of gegevensback-up in te schakelen

Redis is standaard ontworpen voor tijdelijke gegevens, wat betekent dat uw gegevens in zeldzame gevallen verloren kunnen gaan vanwege verschillende omstandigheden, zoals onderhoud of storingen. Als uw toepassing gevoelig is voor gegevensverlies, schakelt u gegevenspersistentie of periodieke gegevensback-up in met behulp van de gegevensexportbewerking.

De functie voor gegevenspersistentie biedt automatisch een snel herstelpunt voor gegevens wanneer een cache uitvalt. Het snelle herstel is mogelijk omdat de functie het RDB- of AOF-bestand opslaat op een beheerde schijf die wordt gekoppeld aan het cache-exemplaar. Gebruikers hebben geen toegang tot persistentiebestanden op de schijf en geen ander WMV-exemplaar kan ze gebruiken.

Veel klanten willen persistentie gebruiken om periodieke back-ups van de gegevens in hun cache te maken. Gebruik hiervoor geen gegevenspersistentie. Gebruik in plaats daarvan de functie importeren/exporteren . U kunt kopieën van gegevens in RDB-indeling rechtstreeks exporteren naar uw gekozen opslagaccount en de gegevensexport zo vaak activeren als u nodig hebt. U kunt exporteren activeren vanuit de portal of met behulp van de CLI-, PowerShell- of SDK-hulpprogramma's.

Specifieke richtlijnen voor de client-bibliotheek

Zie Azure Managed Redis-clientbibliotheken voor meer informatie.

Verwante inhoud

  • Last updated on