Ontwikkeling met Azure Managed Redis (preview)
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 (preview) 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.
- De voorkeursoplossing is het opsplitsen van uw gegevens in gerelateerde kleinere waarden.
- Zie het bericht Wat is het ideale waardegroottebereik voor redis? Is 100 kB te groot? voor meer informatie over waarom kleinere waarden worden aanbevolen.
- 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.
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
Azure Managed Redis biedt lagen geoptimaliseerd voor geheugen, evenwichtig, geoptimaliseerd voor rekenkracht en flash. Zie hier meer informatie over het kiezen van een laag. We raden u aan prestatietests uit te voeren 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 de modus voor hoge beschikbaarheid is uitgeschakeld, worden de gegevens van uw AMR-exemplaar niet gerepliceerd en is uw Redis-exemplaar dus niet beschikbaar tijdens onderhoud. Alle gegevens in het AMR-exemplaar gaan ook verloren in geval van gepland of ongepland onderhoud. Het is raadzaam om de hoge beschikbaarheid alleen uit te schakelen voor uw ontwikkel- of testworkloads. De prestaties van Redis-exemplaren met hoge beschikbaarheid kunnen ook lager zijn vanwege het ontbreken van gegevensreplicatie. Dit is van cruciaal belang 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 openbare IP-adres dat aan uw AMR-exemplaar 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.
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 Managed Redis-exemplaar in productie gebruikt, raden we u aan waarschuwingen in te stellen voor metrische gegevens 'Gebruikt geheugenpercentage', 'CPU', 'Verbonden 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. Bekijk wanneer u schaalt voor meer informatie.
Overweeg 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, raden we u aan om gegevenspersistentie of periodieke back-up van gegevens in te schakelen met behulp van gegevensexportbewerking.
De functie voor gegevenspersistentie is ontworpen om automatisch een snel herstelpunt voor gegevens te bieden wanneer een cache uitvalt. Het snelle herstel wordt mogelijk gemaakt door het RDB- of AOF-bestand op te slaan op een beheerde schijf die is gekoppeld aan het cache-exemplaar. Persistentiebestanden op de schijf zijn niet toegankelijk voor gebruikers of kunnen niet worden gebruikt door een ander WMV-exemplaar.
Veel klanten willen persistentie gebruiken om periodieke back-ups van de gegevens in hun cache te maken. We raden u niet aan om gegevenspersistentie op deze manier te gebruiken. 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. Deze geëxporteerde gegevens kunnen vervolgens worden geïmporteerd in een Redis-exemplaar. Exporteren kan worden geactiveerd vanuit de portal of met behulp van de CLI-, PowerShell- of SDK-hulpprogramma's.
Richtlijnen voor clientbibliotheek
Zie Azure Managed Redis-clientbibliotheken voor meer informatie